Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4
draft-ietf-mip4-gre-key-extension-05

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.

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
  >    [RFC3344]
  >
  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] .

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 them).

"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."

Well understated.

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.