Subject: Re: [Int-area] Intdir early review of draft-ietf-intarea-gue-06

From: Charlie Perkins <[email-masked]>
Date: Thu, 28 Feb 2019 19:07:43 -0800

Hello folks,

Attached, please find a file containing more specific editorial 
suggestions and observations, along with a rfcdiff-generated file that 
highlights the differences from the current version of 
draft-ietf-intarea-gue.

I am not expert in some areas that are important for this draft, and I 
did not read the companion documents that were cited.  I will appreciate 
any further discussion to help my understanding on those points, and 
will be happy to have further interaction on any of the suggestions that 
I have made.

Regards,
Charlie P.

On 2/28/2019 7:00 PM, Charles Perkins wrote:
> Reviewer: Charles Perkins
> Review result: Almost Ready
>
> This document needs an applicability statement which includes the assumptions
> and the reasons it might be useful.  Deliverability needs to be expanded.
> Reasons why middleboxes would be unlikely inspect GUE fields might be included.
>
> For instance, the discussion in second paragraph of 5.11.1 belongs in the
> applicability statement.
>
> It should also be explained why arbitrary GUE extensions are less likely to be
> filtered out compared to IPv6 destination options.
> ============================================== The document assumes close
> familiarity with deployment scenarios that seem to be characterized by acronyms
> such as RSS, aRFS, TSO, LRO, etc.  While I am pretty familiar with a lot of
> encapsulation techniques, I had to study the meaning of these acronyms.  If it
> is intended to effectively restrict the intended audience, that is O.K., but
> otherwise more background is needed along with relevant citations.
> ============================================== [GUEEXTENS] is cited in a way
> that places a normative dependency on [GUEEXTENS].  So, [GUEEXTENS] belongs in
> the Normative References. ============================================== I have
> a large number of specific comments which I will post shortly in the form of a
> rfcdiff-generated file.
>
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 5 Mar 2019 11:50:16 -0800

Hi Charlie, thanks for the review!

> and the reasons it might be useful.  Deliverability needs to be expanded.

I will add an applicability statement.

> Reasons why middleboxes would be unlikely inspect GUE fields might be included.
See comment below.

> For instance, the discussion in second paragraph of 5.11.1 belongs in the
Okay

> filtered out compared to IPv6 destination options.

I'll clarify the requirements about middle boxes parsing and
processing GUE headers and make it clear MUST NOT to do this and a
SHOULD NOT for inspecting GUE header. However, as long as GUE is in
plaintext and sent to a well-known port number there's nothing we
could do to prevent middlebox inspection or this sort or filtering if
someone really wants to do it. In fact the draft assumes inspection
will happen and sets requirements for it. Authentication of the GUE
header would at least be a way to detect if middelboxes modify the
header.

> otherwise more background is needed along with relevant citations.

I'll add some referecences, however note that this is in the appendix
(although Appendix A doesn't have the blurb about just being
informative so I'll add that).

> that places a normative dependency on [GUEEXTENS].  So, [GUEEXTENS] belongs in

Okay.

> a large number of specific comments which I will post shortly in the form of a

Tom