[Int-area] Document shepherd comments on 'draft-ietf-intarea-gue-05'

["Templin (US), Fred L" <[e-mail]>]

Hello,

As document shepherd, I am required to perform a review. Please see below
for initial comments, and respond on the list.

Fred

---

Overall:

The document is well written and clear. The only thing I wonder is whether this
document needs to be progressed in conjunction with GUEEXTEN or whether it
can go forward independently. In particular, this draft defines a flags registry
under IANA Considerations but with no initial assignments. Instead, initial
assignments are assumed to be requested in GUEEXTEN. TBD is whether the
two documents can be progressed together.

Section by Section comments:

Section 3.2.1:
Final paragraph beginning: "IP protocol number 59 ("No next header") can be set
to indicate that the GUE payload does not begin with the header of an IP protocol."
The example given was GUE fragmentation, but would that not represent a
departure from the way things are done for IP fragmentation? I believe in
IP fragmentation the protocol field contains the same value for both initial
and non-initial fragments. Is there a reason for the departure here?

Section 3.2.2:
Final sentence: "This document does not specify any standard control message
types other than type 0." If this document defines type 0, then the format and
use of that message type should be specified here. Also, IANA considerations
simply says: "Need Further Interpretation" - I think that interpretation should
appear in this document.

Section 3.3:
The use of "flags" and "paired flags" is discussed but with no actual flags
assignments appearing in this document. Instead, it quotes from "GUEEXTEN".
Is that OK?

Section 4:
Misspelled "varinant". Check rest of document for spelling.

Section 5:
Final sentence of first paragraph, suggest changing: "Packet flow in the reverse
direction need not be symmetric; GUE encapsulation is not required in the
reverse path." to: "Packet flow in the reverse direction need not be symmetric;
for example, the reverse path might not use GUE and/or any other form of
encapsulation."

Section 5.4:
The sentence "No error message is returned back to the encapsulator." Suggest
removing this sentence and remain silent. Reason is that future variants may
well indicate the use of some form of error messaging.

Section 5.4.1:
Second paragraph, "set 94 for IPIP", I was under the impression that the common
values for IPIP encapsulation are '4' for IPv4 and '41' for IPv6. I have not seen '94'
appear elsewhere. Is this a common use? If not, would it be better to use '4' or '41'?

Section 5.5:
The sentence including: "there are no provisions to automatically GUE copy flags"
appears to have a wording issue that I could not parse.

Section 5.11:
Is "flow entropy" mandatory or optional? For example, shouldn't it be OK for the 
encapsulator to set the UDP source port to anything of its own choosing if it does
not want to get involved with flow entropy determination?

Section 6.2:
"Generic UDP Encapsulation for IP Tunneling (GRE over UDP)" - the correct title
of this RFC is "GRE-in-UDP Encapsulation".

Section 6.2:
"Generic UDP tunneling [GUT]" expired in 2010. Can we either drop this or refer
to it in the past tense?

Section 8.3:
Control type 0 defined as: "Need further interpretation". I think this document
should say what type 0 is instead of just requesting a "placeholder".

Section 8.4:
It seems unusual that this document requests a registry with no initial assignments.