Document: draft-ietf-netlmm-grekey-option-06.txt Reviewer: Spencer Dawkins Review Date: 21 April 2009 IESG Telechat date: 23 April 2009 Summary: This draft is almost ready for publication as a Proposed Standard. I did have some questions about 2119 SHOULD/SHOULD NOT usage in the document. Major issues: None. Minor issues: See below. Nits/editorial comments: I agree with Ralph's note about using acronyms consistently (MAG being the example I noticed first). Is "vanilla" a clearly-understood term of art? :-) --------------------- 4.2. Operational Summary o If the mobile access gateway includes the GRE Key option in the Proxy Binding Update for a specific mobile node and the local mobility anchor accepts the Proxy Binding Update by sending a Proxy Binding Acknowledgement with a success status code (less than 128) other than , but without the GRE Key option, then the mobile access gateway MUST consider that the local mobility anchor does not support GRE Key option as per this specification. The mobile access gateway SHOULD NOT include the GRE Key option in any subsequent Proxy Binding Update message that is sent to that LMA. Spencer (minor): Why is this a SHOULD NOT (and not a MUST NOT)? o If the mobile access gateway sent a Proxy Binding Update message without the GRE Key option, but the received Proxy Binding Acknowledgement has the Status Code , indicating that the GRE encapsulation and GRE key is required, the mobile access gateway SHOULD resend the Proxy Binding Update message with the GRE Key option. If the MAG does not support the Spencer (minor): Why is this a SHOULD (and not a MUST)? GRE Key option, the MAG MAY log the event and possibly raise an alarm to indicate a possible misconfiguration. o If the MAG has successfully negotiated GRE encapsulation and exchanged the GRE keys with the LMA for a specific mobility session, the MAG SHOULD NOT include the GRE Key option in the de- registration Proxy Binding Update. Spencer (minor): Why is this a SHOULD NOT (and not a MUST NOT)? 7.2. TLV-header Tunneling Negotiation The mobile access gateway negotiates the format for tunneling payload traffic during Proxy Mobile IPv6 registration procedure. If the mobile access gateway is required to use the TLV-header UDP encapsulation format, the mobile access gateway MUST set the TLV- header Format (T) flag in the Proxy Binding Update message sent to the local mobility anchor. If the local mobility anchor supports the TLV-header UDP tunneling format, the LMA SHOULD set the TLV-header Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the TLV-header Format (T) flag is cleared. The setting of the TLV-header Format (T) flag in the Proxy Binding Acknowledgement indicates to the mobile access gateway that it MUST use the TLV-header UDP encapsulation format for all packets tunneled to the LMA for the entire duration the mobile node is attached to the mobile access gateway. The TLV-header UDP tunneling format SHOULD NOT change during a Binding Lifetime Extension Proxy Binding Update (re- registration) from the same mobile access gateway. Spencer (minor): Why is this a SHOULD NOT (and not a MUST NOT)? 7.4. Local Mobility Anchor Operation When the local mobility anchor receives a Proxy Binding Update encapsulated in UDP and containing the IPv4 home address option, it needs to follow all the steps in [RFC5213] and [ID-PMIP6-IPv4]. In addition, if the TLV-header Format (T) flag is set in the Proxy Binding Update, the local mobility anchor needs to determine whether it can accept the TLV-header UDP based encapsulation format. If it does, it SHOULD set the TLV-header Format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the LMA MUST NOT set the TLV- Spencer (minor): Why is this a SHOULD (and not a MUST)? header Format (T) flag in the Proxy Binding Acknowledgement.