Generic Notification Message for Mobile IPv4
RFC 6098

Note: This ballot was opened for revision 16 and is now closed.

(Jari Arkko) (was Discuss, Yes) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2009-09-09 for -)
No email
send info
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.

(Russ Housley) No Objection

Comment (2009-09-09 for -)
No email
send info
  The authors have agreed to make several changes based on the Gen-ART
  Review by Sean Turner that was posted on 7-Sep-2009.

Alexey Melnikov (was Discuss) No Objection

Comment (2010-02-15 for -)
No email
send info
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.

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2009-09-10)
No email
send info
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?

(Sean Turner) No Objection

Comment (2010-09-21 for -)
No email
send info
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?

(Lars Eggert) Abstain

Comment (2009-09-08 for -)
No email
send info
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.

(Cullen Jennings) Abstain

Comment (2009-09-09 for -)
No email
send info
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.

Magnus Westerlund Abstain

Comment (2009-09-09 for -)
No email
send info
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?