Generic Notification Message for Mobile IPv4
draft-ietf-mip4-generic-notification-message-16

[Ballot comment]
Please consider adding text discussing how you envision:
* Changing the requirements of a payload when it is revised. Are you anticipating
  abandoning the codepoint and using another, or will there be a way to talk about
  versions inside a payload.
* negotiating what is preferred when more than one message type might be appropriate for solving a problem.
* indicating that a payload is mandatory to understand (or is it the intent that there will never be a payload that
  is mandatory to understand?)

Without this guidance, I expect the next attempt to add a message type will force revision of this document
and you will be tightly constrained to what implementations already do when answering those questions.

[Ballot discuss]
The new versions considerably improved the quality of the specification and I thank the authors for the effort to address the IESG comments, including mine. The changes in the last versions allow me to strike out the first two items on my DISCUSS, however I did not find anything that addresses the third. If I missed something please point me to the text changes or to the relevant discussion

The remaining open issue: The specification is completely mute about the management aspects of the notifications capability. At a minimum I would expect that nodes and agennts expose a list of the supported notifications be accessible to operators via some management interface, that there would be switches to enable / disable notifications, and the capability to tune timers of retransmission.

[Ballot comment]
1) In Section 4.1 of the description of "A":

Set to "1" to indicate that acknowledgement is required.

Set to "0" to indicate that acknowledgement is optional.

Should they be REQUIRED and OPTIONAL?

2) In the final paragraph of 4.1: there are a lot of statements about this is required and this is optional.  Shouldn't these use 2119 language?

3) In section 4.2 (identification and extensions):  there are a lot of statements about this is required, this is mandatory, and this is optional.  Shouldn't these use 2119 language?

[Ballot comment]
1) In Section 4.1 of the description of "A":

Set to "1" to indicate that acknowledgement is required.

Set to "0" to indicate that acknowledgement is optional.

Should they be REQUIRED and OPTIONAL?

2) In the final paragraph of 4.1: there are a lot of statements about this is required and this is optional.  Shouldn't these use 2119 language?

3) In section 4.2 (identification and extensions):  there are a lot of statements about this is required, this is mandatory, and this is optional.  Shouldn't these use 2119 language?

4) Section 7.1 has the following statement:

Two methods are described in this section: timestamps (mandatory) and "nonces" (optional).

Should these use 2119 language?

[Ballot comment]
1) In Section 4.1 of the description of "A":

Set to "1" to indicate that acknowledgement is required.

Set to "0" to indicate that acknowledgement is optional.

Should they be REQUIRED and OPTIONAL?

2) In the final paragraph of 4.1: there are a lot of statements about this is required and this is optional.  Shouldn't these use 2119 language?

3) In section 4.2 (identification and extensions):  there are a lot of statements about this is required, this is mandatory, and this is optional.  Shouldn't these use 2119 language?

4)

Waiting for Henrik to organize a chat with the discussing ADs to explain the plan in the new draft and ask for feedback. There are some possible variations of the plan, and discussion is needed to ensure that we do what is necessary to clear the discusses, but do not take it too far.

I have looked at the new draft and the discussions we had. The draft and changes since the IESG review are visible here:

http://tools.ietf.org/html/draft-ietf-mip4-generic-notification-message-14
http://www.arkko.com/ietf/mip4/draft-ietf-mip4-generic-notification-message-14-from-1.diff.html

I have a number of comments, however, and they need to be resolved before moving forward. In short we're on the right path but not done yet:

> The messages defined in this
> document are capable of carrying the same extensions that have been
> defined for the existing Mobile IPv4 messages.  However, this
> document requires for now that only the following extensions be
> present in the new messages defined herein:
>
>  - MN-HA Authentication Extension
>
>  - MN-FA Authentication Extension
>
>  - FA-HA Authentication Extension
>
>  - Generic String Extension

This seems a bit special. I would simply say: "Only the following extensions can be present in these new messages: ..." The discussion about capable vs. for now is confusing.

> For now, the semantics of receiving a generic notification message
> are null; i.e., it has no effect on the state of a mobile node's
> existing registration.
> In some case, the HA or FA needs to notify the MN about service
> termination due to the end of prepaid time, or service interruption
> due to system maintenance.  This information could be defined based
> on a string [RFC4917] which is easily recognized by the MN.  An
> example would be "Maintenance Downtime", "Prepaid Expiration".  On
> the other hand, the MN may need to notify the network about events
> related to a service such as a location change event, or a usage-
> preference change event.  This information could be defined based on
> a string [RFC4917].  An example would be "Location Change" or
> "Service Event".  These strings MUST be strictly defined so they
> could be easily understood by all of the network entities, and a
> suitable GNM Subtype number would have to be allocated.  All such
> definitions are left for future specifications.

But there is no such subtype anymore.

More importantly, RFC 4917 allows free format strings, and I don't know how to define "easily recognized" strings without a danger of collisions, at least not without implementing some kind of IANA registry of subtypes or a reserved prefix for special RFC 4917 strings.

> (RFC 4917) Text:
>
>      The Text field is one or more octets, and its contents are
>      implementation dependent.  It is intended to be human readable,
>      and MUST NOT affect the operation of the protocol.

Proposed usage in generic-notification-message seems to go against the MUST NOT. At the very least generic-notification-message should explain the situation and have an "Updates: RFC 4917" header at the top.

> For now, none of these above future semantics are supported except
> that the Generic String Extension is supported for informational
> purposes.  There should be minimum requirements given here for adding
> additional extension types to the allowed set and defining their
> semantics.

OK. Where are such minimum requirements?

> There are several applications that could use this GNM.  For example,
> during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP
> resource on the CDMA side has to be removed on the FA (PDSN) to avoid
> over-charging subscribers, anyway existing Registration Revocation
> RFC [RFC3543] is a one way to do this.
Not a very convincing use case! Rewrite to say directly that for registration revocation this new generic model is needed.

> Other applications such as HA
> switch over(before HA decide to go offline it would like to notify
> the MNs to register with another candidate HA), NEMO prefix
> changes(MN is notified by HA about NEMO prefix changes and service or
> billing related events, which is an operational requirement), Load
> balancing(HA wants to move some of the registered MNs to other HAs),
> Service Termination(due to end of prepaid time), and Service
> Interruption(due to system maintenance).
Something wrong with the sentence (editorial).

> There are several applications that could use this GNM.  For example,
> during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP
> resource on the CDMA side has to be removed on the FA (PDSN) to avoid
> over-charging subscribers, anyway existing Registration Revocation
> RFC [RFC3543] is a one way to do this.  Other applications such as HA
> switch over(before HA decide to go offline it would like to notify
> the MNs to register with another candidate HA), NEMO prefix
> changes(MN is notified by HA about NEMO prefix changes and service or
> billing related events, which is an operational requirement), Load
> balancing(HA wants to move some of the registered MNs to other HAs),
> Service Termination(due to end of prepaid time), and Service
> Interruption(due to system maintenance).

I do not understand why we have this text in Section 5 when there is Section 3 that is supposed to describe the use cases. But FWIW, I found the above explanation far more useful than Section 3... maybe it should go away.

[Ballot comment]
I am on the edge of Abstaining on this document, due to its readability.

The document is hard to read. Also it contains lots of duplicated text, so it is hard to verify if various sections of it consistent.


5.  Future Extensibility


This section needs to be edited for readability.


6.  IANA Considerations

  This document describes two new messages, the GNM in section 4.1 and
  the GNAM in section 4.2.  These two messages SHOULD be allocated from
  the same address space used by the Registration Request and
  Registration Reply messages in [RFC3344].  The subtype of these two
  messages indicate what kind of information is carried and will be
  under assigned by IANA namespace.

The last sentence doesn't read well.

[Ballot comment]
The document is hard to read.
It contains lots of duplicated text, so it is hard to verify if various sections of it consistent.


5.  Future Extensibility


This section needs to be edited for readability.


6.  IANA Considerations

  This document describes two new messages, the GNM in section 4.1 and
  the GNAM in section 4.2.  These two messages SHOULD be allocated from
  the same address space used by the Registration Request and
  Registration Reply messages in [RFC3344].  The subtype of these two
  messages indicate what kind of information is carried and will be
  under assigned by IANA namespace.

The last sentence doesn't read well.

[Ballot comment]
5.  Future Extensibility


This section needs to be edited for readability.


6.  IANA Considerations

  This document describes two new messages, the GNM in section 4.1 and
  the GNAM in section 4.2.  These two messages SHOULD be allocated from
  the same address space used by the Registration Request and
  Registration Reply messages in [RFC3344].  The subtype of these two
  messages indicate what kind of information is carried and will be
  under assigned by IANA namespace.

The last sentence doesn't read well.

[Ballot discuss]
[Revised to delete discuss issues (1) and (3), which have been resolved.  Thanks!]

(2) Section 8.1, second paragraph:

  The style of replay protection in effect between any two peer nodes
  among MN, FA and HA.  A sending node and its receiving node MUST
  agree on which method of replay protection will be used. 

Is there a negotiation mechanism or is this an out-of-band agreement?

[Ballot discuss]
[Revised to delete discuss issue (1), which has been resolved.  Thanks!]

(2) Section 8.1, second paragraph:

  The style of replay protection in effect between any two peer nodes
  among MN, FA and HA.  A sending node and its receiving node MUST
  agree on which method of replay protection will be used. 

Is there a negotiation mechanism or is this an out-of-band agreement?

(3) A number of issues were raised in the secdir review, and the authors have graciously
agreed to resolve them.  (Thanks!)  Since text was not proposed, this part of my discuss is
just a placeholder for a review of -12 when it appears.

We need to talk about what to do with this draft. There are some detailed technical issues, IANA concerns, etc. These are easy to handle and I think many if not all of them already have been taken care of. Thanks for that.

But I am more worried about high level feedback we got in the IESG review. Here's a sample of the comments:

  /"There are plenty of usage scenarios listed in Section 3. But the
  document is very short of examples of what the notification might be
  used for (just a little in Seciton 5). I don't see any I-Ds in the
  working group proposing uses of this extension, and there is nothing
  referenced from this I-D. Are you sure that you haven't invented a
  protocol mechanism without any specific requirements? Will you be
  cluttering the protocol implementations with support for messages
  that will never be used? I note that the protocol write-up does not
  mention any implementations or plans for implementaiton."

  "This is turning MIP into a reliable signaling protocol, which I
  think is a bad idea. I also don't understand how RFC3115 and RFC4917
  aren't sufficient already."

  "I'd like to see more motivation for the notification message and
  more fleshed out examples so we can judge the utility of the
  messages as well as the efficacy and correctness of the protocol."

  "This protocol defines a semantic free messaging protocol. The
  problem with this is the semantics are derived from the payloads
  that it caries. This will result in several issues. 1) Lack of
  Interoperability: Different vendors will do different things. There
  is way for one vendor to find out what other vendors extensions or
  how they work as there is no requirement to register them in a
  standardized way.  2) Inappropriateness: Many of the things vendors
  do will not be and appropriate use of mip4. 3) Incorrectness: Many
  of the extensions will suffer from errors, security problems, race
  conditions, and other problems. This happens due to lack of review
  of payloads and constrains implied by the transport."

  "The also wonder what the motivation for this generic mechanism is.
  Especially why does it need to be generic? "/


We could debate each individual comment, but it is obvious that we have not done a very good job of convincing others that we have a need that has to be fulfilled. To move forward, the draft needs to have no Discusses and have the majority of the IESG feeling like its useful work that should or at least can move forward. We're not there at the moment!

I would suggest that we bring the fate of this draft up in the meeting in Hiroshima as a separate agenda item. As a minimum to move forward I would like to see the working group respond and deal with the above concerns. But I also want to see that there's true demand for this work in the group. Alternatively, we could decide that maybe this wasn't such a good idea after all and decide to do something else or abandon this work. I am inviting some of the ADs who made these comments to joint the discussion as well (but as always, that may not be possible due to scheduling).

[Ballot comment]
The v6 Mobile IP work seems to be taking a very different approach to this kind of problem. Please look to see if there's an opportunity for some alignment here?

[Ballot discuss]
I have many of the same reservations and concerns expressed in Cullen and Lars' comments and support Dan's discuss.

Some additional treatment either adding mechanics for agreeing on semantics, the creation  of a very limited scope
for those semantics that would make those mechanics unnecessary, and/or additional motivation and discussion of
architectural impact is needed.

[Ballot comment]
6.  IANA Considerations

  This document describes two new messages, the GNM in section 4.1 and
  the GNAM in section 4.2.  These two messages SHOULD be allocated from
  the same address space used by the Registration Request and
  Registration Reply messages in [RFC3344].  The subtype of these two
  messages indicate what kind of information is carried and will be
  under assigned by IANA namespace.

This sentence doesn't read well.

[Ballot discuss]
Updated as per revision -11:

1).
4.3.1.  Receiving Generic Notification Messages

  When the MN is using FA-CoA and receives a Notification message, if
  the "MD" value is 0, it means that the notification message came from
  the HA.  If the "MD" value is 4, the notification came from the FA.

  If this notification message came from a FA and the MN accepts the
  FA's GNM, it will process the notification extension according to the
  specific rules for that extension.

  After that, the MN MAY reply GNAM back to the FA.  If the "A" flag is
  set in the GNM, then the MN MUST send the acknowledgement.

  The MN MUST check for the presence of an authorization-enabling
  extension, and perform the indicated authentication.  Exactly one
  authorization-enabling extension MUST be present in the GNM, if this
  message came from a FA, MN-FA AE MUST be present, If no MN-FA AE is
  found, or if more than one MN-FA AE is found, or if the Authenticator
  is invalid, the MN MUST reject the GNM and MAY send a GNAM to the FA
  with Code 195, including an Identification field computed in
  accordance with the rules specified in Section 7.1.1.  The MN MUST do
  no further processing with such a notification, though it SHOULD log
  the error as a security exception.

  The MN MUST check that the Identification field is correct using the
  context selected by the SPI within mandatory authentication extension
  like MN-FA AE or MN-HA AE.  See Section 7.1.1 for a description of
  how this is performed.  If incorrect, the MN MUST reject the GNM and
  MAY send a GNAM to the initiator with Code 197, including an
  Identification field computed in accordance with the rules specified
  in Section 7.1.1.  The MN MUST do no further processing with such a
  notification, though it SHOULD log the error as a security exception.

The order of paragraphs in this section seems wrong to me.
I think the "A" flag needs to be checked after checking MN-FA AE or MN-HA AE, and also after checking the Identification field.

There might be a similar problem in other sections.

[Ballot discuss]
1. I do not believe that the way Vendor/Organization specific extensions are currently defined allow for any level of interoperability or are for any use in a multi-vendor deployment. Even for mobile nodes and agents belonging to the same vendor, how do these recognize each other and the level of vendor extenstions that they support? It looks like this needs some more wor to design capability advertising and/or negotiation mechanism.

2. If Generic String Extensions MUST be strictly defined as mentioned in section 5.1 should not an IANA register for these extensions be created together with the subtype field registries defined in Section 6?

3. The specification is completely mute about the management aspects of the notifications capability. At a minimum I would expect that nodes and agennts expose a list of the supported notifications be accessible to operators via some management interface, that there would be switches to enable / disable notifications, and the capability to tune timers of retransmission.

[Ballot comment]
This protocol defines a semantic free messaging protocol. The problem with this is the semantics are derived from the payloads that it caries. This will result in several issues.

1) Lack of Interoperability: Different vendors will do different things. There is way for one vendor to find out what other vendors extensions or how they work as there is no requirement to register them in a standardized way.

2) Inappropriateness: Many of the things vendors do will not be and appropriate use of mip4.

3) Incorrectness: Many of the extensions will suffer from errors, security problems, race conditions, and other problems. This happens due to lack of review of payloads and constrains implied by the transport.

These issues could be resolved with significant rework of the draft that moved it to have a way to negotiate payloads each side supported and preferred, a way of indicating if the payload was mandatory to understand or optional to understand. A way of upgrading from an early version of an extension to a later way. And finally a way of registering payloads that used IANA and was specification required.

[Ballot discuss]
Discuss-discuss: I'd like to see more motivation for the notification message and more fleshed out examples so we can judge the utility of the messages as well as the efficacy and correctness of the protocol.

[Ballot discuss]
(1) Sections 4.1 and 4.2, the description of SubType ends with:

      The value 0 is reserved and SHOULD NOT be used.  The value 1
      indicates that the actual information is carried in vendor
      specific extensions.  Other values are reserved for future
      extensions.

However, the value 2 is also defined in this text.  Is there a reason it is omitted from the list?

(2) Section 8.1, second paragraph:

  The style of replay protection in effect between any two peer nodes
  among MN, FA and HA.  A sending node and its receiving node MUST
  agree on which method of replay protection will be used. 

Is there a negotiation mechanism or is this an out-of-band agreement?

(3) A number of issues were raised in the secdir review, and the authors have graciously
agreed to resolve them.  (Thanks!)  Since text was not proposed, this part of my discuss is
just a placeholder for a review of -12 when it appears.

[Ballot comment]
The also wonder what the motivation for this generic mechanism is. Especially why does it need to be generic? Can't it purpose be expressed more clearly?

[Ballot comment]
There are plenty of usage scenarios listed in Section 3. But the
document is very short of examples of what the notification might be
used for (just a little in Seciton 5). I don't see any I-Ds in the
working group proposing uses of this extension, and there is nothing
referenced from this I-D. Are you sure that you haven't invented a
protocol mechanism without any specific requirements? Will you be
cluttering the protocol implementations with support for messages
that will never be used?

I note that the protocol write-up does not mention any implementations
or plans for implementaiton.

---

idnits says
** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086)

---

Section 2
s/terms are/term is/

---

Section 4.3 needs to say when to give up retransmitting, and what to
do with a GNAM that arrives for a GNM that was transmitted several
retransmissions ago.

IANA questions/comments:

- In Action 2 the document says, "This document reserves four values
for the Subtype field"; however, only three values are specified.
Which fourth value is reserved?

- In Section 4.2 you specify error codes that are not registered in
Code Values for Mobile IP Registration Reply Messages. Should we
register these?

Notification denied by the mobile node
192 -- reason unspecified
193 -- administratively prohibited
194 -- insufficient resources
195 -- foreign agent failed authentication
196 -- home agent failed authentication
197 -- notification Identification mismatch


Action 1:

Upon approval of this document, IANA will make the following assignments
in the "Message Format and Protocol Extensibility" registry at
http://www.iana.org/assignments/mobileip-numbers

TBD Generic Notification Message
[RFC-mip4-generic-notification-message-09]
TBD Generic Notification Acknowledgement Message
[RFC-mip4-generic-notification-message-09]


Action 2:

NOTE: "IETF Consensus" should be changed to "IETF Review," per RFC5226

Upon approval of this document, IANA will create the following registry at
http://www.iana.org/assignments/mobileip-numbers

Registry Name: Generic Notification Subtypes
Registration Procedures: Standards Actions or IETF Review
Initial contents of this sub-registry will be:

0 Reserved
[RFC-mip4-generic-notification-message-09]
1 Information carried in Vendor specific extensions
[RFC-mip4-generic-notification-message-09]
2 Information carried in Generic String Extension
[RFC-mip4-generic-notification-message-09]
3-255 Unassigned

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
This is turning MIP into a reliable signaling protocol, which I think is a bad idea. I also don't understand how RFC3115 and RFC4917 aren't sufficient already.

[Ballot comment]
6.  IANA Considerations

  This document describes two new messages, the GNM in section 4.1 and
  the GNAM in section 4.2.  These two messages SHOULD be allocated from
  the same address space used by the Registration Request and
  Registration Reply messages in [RFC3344].  The subtype of these two
  messages indicate what kind of information is carried and will be
  under assigned by IANA namespace.

This sentence doesn't read well.


4.2.  Generic Notification Acknowledgment Message

  Identification

      if the timestamp of the GNM is valid, the receiver copies the
      entire Identification field into the GNAM it returns the GNAM
      message to the sender. if the timestamp of the GNM is not valid,
      the receiver copies only the low-order 32 bits into the GNAM, and
      supplies the high-order 32 bits from its own time of day.  Both
      GNM and GNAM mandate Timestamps.

What about "nonces"? Note that section 4.1 says:

  Identification

      A 64-bit number, constructed by the sender, used for matching GNM
      with GNAM, and for protecting against replay attacks of
      notification messages.  Here is the same as Sections 5.4 and 5.7
      of [RFC3344].  Timestamps is mandatory and nonces is optional.

[Ballot discuss]
Updated as per revision -10:

1).
4.3.1.  Receiving Generic Notification Messages

  When the MN is using FA-CoA and receives a Notification message, if
  the "MD" value is 0, it means that the notification message came from
  the HA.  If the "MD" value is 4, the notification came from the FA.

  If this notification message came from a FA and the MN accepts the
  FA's GNM, it will process the notification extension according to the
  specific rules for that extension.

  After that, the MN MAY reply GNAM back to the FA.  If the "A" flag is
  set in the GNM, then the MN MUST send the acknowledgement.

  The MN MUST check for the presence of an authorization-enabling
  extension, and perform the indicated authentication.  Exactly one
  authorization-enabling extension MUST be present in the GNM, if this
  message came from a FA, MN-FA AE MUST be present, If no MN-FA AE is
  found, or if more than one MN-FA AE is found, or if the Authenticator
  is invalid, the MN MUST reject the GNM and MAY send a GNAM to the FA
  with Code 195, including an Identification field computed in
  accordance with the rules specified in Section 7.1.1.  The MN MUST do
  no further processing with such a notification, though it SHOULD log
  the error as a security exception.

  The MN MUST check that the Identification field is correct using the
  context selected by the SPI within mandatory authentication extension
  like MN-FA AE or MN-HA AE.  See Section 7.1.1 for a description of
  how this is performed.  If incorrect, the MN MUST reject the GNM and
  MAY send a GNAM to the initiator with Code 197, including an
  Identification field computed in accordance with the rules specified
  in Section 7.1.1.  The MN MUST do no further processing with such a
  notification, though it SHOULD log the error as a security exception.

The order of paragraphs in this section seems wrong to me.
I think the "A" flag needs to be checked after checking MN-FA AE or MN-HA AE, and also after checking the Identification field.

There might be a similar problem in other sections.

2).
4.5.4.  Sending Generic Notification Acknowledgement Messages

  If the GNM message came from the MN, the HA MAY reply with a GNAM
  message to the MN based on the "A" flag in the GNM message.  If the
  "A" flag is set in the GNM message, then the HA MUST send a GNAM
  message.

The second sentence is just repeating the first,
but using MUST instead of MAY. I think the first sentence needs to be deleted. And please also check other sections for similar text.

The problem mentioned above was fixed, there is one more instance in the same section.

[Ballot comment]
4.1.  Generic Notification Message

  A

      This bit indicates whether the notification message MUST be
      acknowledged by the recipient. if "A" bit has been set during the
      message, but the sender doesn't receive any acknowledgement
      message, the sender will have to resend the notification message
      again.

How many time/for how long the message needs to be resent?

4.2.  Generic Notification Acknowledgment Message

  Identification

      if the timestamp of the GNM is valid, the receiver copies the
      entire Identification field into the GNAM it returns the GNAM
      message to the sender. if the timestamp of the GNM is not valid,
      the receiver copies only the low-order 32 bits into the GNAM, and
      supplies the high-order 32 bits from its own time of day.  Both
      GNM and GNAM mandate Timestamps.

What about "nonces"? Note that section 4.1 says:

  Identification

      A 64-bit number, constructed by the sender, used for matching GNM
      with GNAM, and for protecting against replay attacks of
      notification messages.  Here is the same as Sections 5.4 and 5.7
      of [RFC3344].  Timestamps is mandatory and nonces is optional.

[Ballot discuss]
1). DISCUSS DISCUSS:

4.2.  Generic Notification Acknowledgment Message

  code

      A value indicating the result of the GNM.  See below for a list of
      currently defined Code values.

  Notification suceessful

      0 -- notification accepted

  Notification denied by the HA

      128 -- reason unspecified

      129 -- administratively prohibited

      130 -- insufficient resources

      131 -- mobile node failed authentication

      132 -- foreign agent failed authentication

      133 -- notification Identification mismatch

[...]

Does this need a new IANA registry?

2).

4.3.1.  Receiving Generic Notification Messages

  When the MN is using FA-CoA and receives a Notification message, if
  the "MD" value is 0, it means that the notification message came from
  the HA.  If the "MD" value is 4, the notification came from the FA.

  If this notification message came from a FA and the MN accepts the
  FA's GNM, it will process the notification extension according to the
  specific rules for that extension.

  After that, the MN MAY reply GNAM back to the FA.  If the "A" flag is
  set in the GNM, then the MN MUST send the acknowledgement.

  The MN MUST check for the presence of an authorization-enabling
  extension, and perform the indicated authentication.  Exactly one
  authorization-enabling extension MUST be present in the GNM, if this
  message came from a FA, MN-FA AE MUST be present, If no MN-FA AE is
  found, or if more than one MN-FA AE is found, or if the Authenticator
  is invalid, the MN MUST reject the GNM and MAY send a GNAM to the FA
  with Code 195, including an Identification field computed in
  accordance with the rules specified in Section 7.1.1.

Here and everywhere else in the document - this document doesn't
have section 7.1.1. I think you meant 8.1.1.

  The MN MUST do
  no further processing with such a notification, though it SHOULD log
  the error as a security exception.

  The MN MUST check that the Identification field is correct using the
  context selected by the SPI within mandatory authentication extension
  like MN-FA AE or MN-HA AE.  See Section 7.1.1 for a description of
  how this is performed.  If incorrect, the MN MUST reject the GNM and
  MAY send a GNAM to the initiator with Code 197, including an
  Identification field computed in accordance with the rules specified
  in Section 7.1.1.  The MN MUST do no further processing with such a
  notification, though it SHOULD log the error as a security exception.

The order of paragraphs in this section seems wrong to me.
I think the "A" flag needs to be checked after checking MN-FA AE or MN-HA AE, and also after checking the Identification field.

3).
4.5.4.  Sending Generic Notification Acknowledgement Messages

  If the GNM message came from the MN, the HA MAY reply with a GNAM
  message to the MN based on the "A" flag in the GNM message.  If the
  "A" flag is set in the GNM message, then the HA MUST send a GNAM
  message.

Unless I am too asleep, the second sentence is just repeating the first,
but using MUST instead of MAY. I think the first sentence needs to be deleted. And please also check other sections for similar text.

4).
6.  IANA Considerations

  This document describes two new messages, the GNM in section 4.1 and
  the GNAM in section 4.2.  These two messages SHOULD be allocated from
  the same address space used by the Registration Request and
  Registration Reply messages in [RFC3344].  The subtype of these two
  messages indicate what kind of information is carried and will be
  under assigned by IANA namespace.

This sentence doesn't read well.

  This document creates a new IANA registry for the Subtype field in
  the GNM and GNAM.  New values SHOULD be allocated by Standards

Why SHOULD and not MUST here? I.e. what is the IANA procedure if the SHOULD is not followed?

  Actions or IETF Consensus.  This document reserves four values for

I only counted 3.

  the Subtype field

  0 Reserved

  1 Information carried in Vendor specific extensions

  2 Information carried in Generic String Extension

I have reviewed this document. It was generally well written, though a bit tiresome to read given the many slightly different behaviours between messages sent from HA/FA/MN to HA/FA/MN. I did not see any major problems, but there were a few editorial issues, and a few errors or inconsistencies. My main worries were:

1. The inconsistency of the rules regarding A flag and code 0.

2. The inconsistency and accuracy of the text that specifies how the FA deals with failed HA-FA AEs.

3. The rules on how the HA decides whether it is seeing a message from the FA or MN directly.

Please address these issues and issue a new draft (I can ask the secretariat to allow posting or if that turns out to not be possible, I can register some OLD/NEW edits in the tracker).

Detailed comments:

> The value 0 is reserved and SHOULD not be used.

s/SHOULD not/SHOULD NOT/ (2 instances)

> [RFC3846]  Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004.

This is an unnecessary reference. Please remove and/or justify.

> This document mandate the MN-HA AE when this message is sent

Instead: This document mandates the MN-HA Authentication Extension (AE) when this message is sent

>      Source Port            Copied from the source port of the
>                            corresponding GNM.

Shouldn't this be:

      Source Port            Copied from the destination port of the
                            corresponding GNM.

> If the "A" flag is set in the GNM, then the MN MUST send the acknowledgement with Code 0.

I understand that the acknowledgement must be sent. But why is there a requirement that the code must be set to 0 in this case? It does not seem to make make sense, but maybe I'm missing something. In any case, Section 4.3.2 already says: "The Code field of the GNAM is chosen in accordance with the rules specified in the section 4.2.  When replying to an accepted notification, a MN SHOULD respond with Code 0." I think this is sufficient, and I would suggest deleting the "with Code 0" part from above.

>    if the "MD" value is set to 0, the FA MAY validate the FA-HA AE if present. if the FA-HA AE is invalid, all non-authentication
>    extensions between HA and FA MUST be removed, FA SHOULD relay the GNM
>    to the MN's home address as specified in the Home Address field of
>    the GNM, MN will eventually validate the MN-HA AE to ensure that all
>    information sent to the MN is integrity protected. if the FA-HA AE is
>    valid, FA MUST relay the GNM to the MN's home address as specified in
>    the Home Address field of the GNM. 
s/if/If/

Also, I do not understand the part about removing non-authentication extensions. Did you mean all extensions specified to be for HA-FA only? Or all extensions, period? Why would anything be forwarded if the HA-FA authentication is present but fails? What would be the use of the notification if all non-authentication data was stripped but it still ended up in the MN? I would suggest reformulating this as follows:

OLD:
all non-authentication extensions between HA and FA MUST be removed,
NEW:
all extensions between the HA-MN AE and the HA-FA AE MUST be removed,

But maybe I am missing something. How are HA-FA AEs handled in other specifications?

>    The FA MUST check that the Identfication field is correct using the

s/Identfication/Identification/


>    if the "MD" value is set to 2, the FA MAY check the MN-FA AE and
>    Authenticator value in the Extension. if the MN-FA AE is invalid, all
>    non-authentication extensions between MN and FA MUST be removed, FA
>    SHOULD relay the GNM to the HA's address as specified in the Home
>    Agent Address field of the GNM, HA will eventually validate the MN-HA
>    AE to ensure that all information sent to the HA is integrity
>    protected. if the FA-HA AE is valid, FA MUST relay the GNM to the
>    HA's address as specified in the Home Agent Address field of the GNM.
>    The FA MUST NOT modify any of the fields beginning with the fixed
>    portion of the GNM through the MN-HA AE or other authentication
>    extension supplied by the MN as an authorization-enabling extension
>    for the HA.

Same issues as above with MD 0. s/if/If/ and

OLD:
if the MN-FA AE is invalid, all non-authentication extensions between MN and FA MUST be removed
NEW:
If the MN-FA AE is invalid, all extensions between the MN-HA AE and the MN-FA AE MUST be removed

>    In the case of a FA-CoA and if the "MD" value is set to 2, if the FA
>    received this message, the MN-FA AE MUST be checked, and the FA MUST
>    check the Authenticator value in the Extension.  If no MN-FA AE is
>    found, or if more than one MN-FA AE is found, or if the Authenticator
>    is invalid, the FA MUST silently discard the GNAM message.  If FA
>    accepted the MN's GNAM message, it MUST relay this message to the HA.
>    The FA MUST NOT modify any of the fields beginning with the fixed
>    portion of the GNAM message through the including the MN-HA AE or
>    other authentication extension supplied by the HA as an
>    authorization-enabling extension for the MN.

Isn't the treatment of relayed notification messages and acknowledgments is different between 4.4.1 and 4.4.4? In 4.4.1, the conditions about MN-FA AE are different, and it talks about removing extensions. But here the entire message is discarded. Is this correct?

>    If the "MD" value is set to 2, MN-HA AE MUST be checked, and the HA
>    MUST check the Authenticator value in the Extension.  If no MN-HA AE
>    is found, or if more than one MN-HA AE is found, or if the
>    Authenticator is invalid, the HA MUST silently discard the GNAM.  If
>    the HA accepted this message, the HA MAY also process it based on the
>    notification event.
>
>    In the case of a Co-located CoA, if the HA received this message, the
>    MN-HA AE MUST be checked, and the HA MUST check the Authenticator
>    value in the Extension.  If no MN-HA AE is found, or if more than one
>    MN-HA AE is found, or if the Authenticator is invalid, the HA MUST
>    silently discard the GNAM message.

This is from Section 4.5.2. Perhaps my eyes are tired, but I cannot see the difference between the two paragraphs. Shouldn't the latter paragraph talk about FA-HA AEs?

>    The HA MUST check that the Identfication field is correct using the

Typo

>    if the the "MD" value is set to 2, this message come from MN, if
>    FA-HA AE is presented, it MUST be checked, and the HA MUST check the
>    Authenticator value in the Extension.

s/if/If/

Also, this text from Section 4.5.3 seems different from the text in Section 4.5.2. In this text we look a the presence of the FA-HA AE, and in the former we just check if co-located CoAs are in use. Shouldn't the HA always determine if co-located mode is in use, and if it is, require FA-HA AE?

> An example would be "Maintenance Stopping", "Prepaid Expire".  These string MUST be strictly defined so they could be easily understood by all of the network entities.  "Subtype" number would need to be decided by the working group.

I would rephrase this slightly:

An example would be "Maintenance Downtime", "Prepaid
  Expiration".  Such strings would have to standardized so that
can be understood by all network entities, and a

These string MUST be strictly defined so they could be easily understood by all of the network entities, and a suitable GNM Subtype number would have to be allocated. All such definitions are left for future specifications.

> This documents require that all MNs, FAs and HAs MUST implement timestamp- based replay protection.

This document...

> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?

Document shepherd: Pete McCann
I have reviewed this version of the I-D and believe it is ready for IESG
review and publication.


> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?

The document received several reviews from key WG members and comments
were incorporated. No review by non-WG members has been performed. I
have no concerns about the depth or breadth of the reviews.

> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization, or XML?

No concerns.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document,
or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here. Has an IPR disclosure related to this
document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.

A few typos exist that can be addressed after Last Call:

Section 4.1:

IP Fields:

Source Address Same as the last Registration Reply/Request
message received.

Destination Address Same as the last Registration Reply/Request
message.

Should say:

IP Fields:

Source Address Same as the last Registration Reply/Request
message sent.

Destination Address Same as the last Registration Reply/Request
message sent.

Should also add the word "sent" to the UDP Source Port/Destination Port
descriptions.

Section 4.2:

Source Port Copied from the source port of the
corresponding GNM.
Should say:
Source Port Copied from the destination port of the
corresponding GNM.


> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?

The WG as a whole understands the document. There is good consensus
to advance it.

> (1.f) Has anyone threatened an appeal or otherwise indicated
extreme
> discontent? If so, please summarize the areas of conflict in
> separate email messages to the Responsible Area Director.
(It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)

No appeals have been threatened.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See
> http://www.ietf.org/ID-Checklist.html and
> http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
> not enough; this check needs to be thorough. Has the
document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type, and URI type reviews? If the document
> does not already indicate its intended status at the top of
> the first page, please indicate the intended status here.

The idnits tool returns several warnings, but they mainly seem to be
red herrings and boilerplate issues.

> (1.h) Has the document split its references into normative and
> informative? Are there normative references to documents
that
> are not ready for advancement or are otherwise in an unclear
> state? If such normative references exist, what is the
> strategy for their completion? Are there normative
references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].

The document has only normative references. No downrefs exist in the
normative references section.

> (1.i) Has the Document Shepherd verified that the document's IANA
> Considerations section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC2434]. If the
> document describes an Expert Review process, has the Document
> Shepherd conferred with the Responsible Area Director so that
> the IESG can appoint the needed Expert during IESG
> Evaluation?

The IANA considerations is complete. There are two assignments needed
from the Mobile IP Message Type number space, and the new GNM Sub-Type
space is created and populated with some initial values.

> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?

No such formal languages are used.

> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up. Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:

Technical Summary

The Generic Notification Message for Mobile IPv4 augments the
original
registration process of Mobile IPv4, which supports only mobile-node
initiated signaling, with two new messages. The Generic Notification
Message can be generated by any mobility agent and directed at any
other
mobility agent, and the Generic Notification Acknowledgement Message
can
be sent in response. The new mechanism is expected to be a useful
container
for information exchange and session management between the three
kinds of
mobility agents.

Working Group Summary

The document underwent Working Group Last call in April 2008 and was
improved based on lengthy subsequent discussion. In particular, the
security considerations were updated to describe the timestamp-based
replay protection mechanism and clock re-synchronization.

Document Quality

The document was reviewed for quality by Pete McCann.

Personnel

Document shepherd: Pete McCann
Responsible AD: Jari Arkko