Note: This ballot was opened for revision 04 and is now closed.
Summary: Has enough positions to pass.
I have no objection to the publication of this documen, but there are a few
small points that might be addressed to improve it.
I don't think you need RFC 2119 notation in the Abstract.
A number of acronyms are used without expansion
Sections 4.1, 4.2, and 4.3 seem a bit confused on the use of RFC 2119
language and the cases where behavior is already defined in other
specifications. Could you spend a little time to clear this up and make
clear what new behavior this document is defining.
1) Nits points out:
- ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944)
2) If you end up doing another revision, please:
a) expand GRE on 1st use in Abstract and Introduction.
b) add a period to the end of the 1st paragraph in Section 7.
Otherwise, please consider these during AUTH48 (if the RFC editor doesn't catch
"In the absence of this key identifier, the data streams cannot be
distinguished from each other, a significant
drawback when using IP-in-IP tunneling."
FA, HA, RRP, MN, RRQ, RRP used without first expansion.
It would be useful to the reader if the 'G' bit was called by it's proper name
(GRE Encapsulation) on first used, same for the 'D' bit.
'The FA may include a GRE key of value zero in the GRE Key Extension to signal
that the HA assign GRE keys in both directions.' - Minor grammar problem.
'Encapsulati on Unavailable' - - Minor grammar problem.
It would be nice to expand "GRE" on first use to "Generic Routing
Encapsulation" and also provide a reference to RFC 2784.
Something is wrong here:
> 4.2. Home Agent Requirements for GRE Tunneling Support
The reference is misplaced. I think it belongs in the first
sentence of the section.
Please remove the extra spaces:
> GRE encapsulation, it MUST send an RRP with code 'Requested
> Encapsulati on Unavailable (139)' [RFC3024] .