Mobile IPv6 Experimental Messages
draft-ietf-mip6-experimental-messages-03

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

Lars Eggert No Objection

Section 1., paragraph 1:
>    gets deployed with these messages.  Therefore it is considered a good
>    practice to set aside some messages for experimental purposes.  The
>    need for experimental messages is shown in [3].

  It's not _messages_ that are typically set aside for experimentation,
  it's _codepoints_ to allow identification of experimental messages.
  Suggest to clarify this throughout the document.


Section 5., paragraph 0:
>    5.  Security Considerations

  Please see the security considerations of RFC 4727 - three of the four
  paragraphs seem to apply here as well.

(Jari Arkko; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(Cullen Jennings; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(David Ward; former steering group member) (was Discuss) No Objection

(Jon Peterson; former steering group member) No Objection

(Lisa Dusseault; former steering group member) No Objection

(Magnus Westerlund; former steering group member) No Objection

(Mark Townsley; former steering group member) (was Discuss) No Objection

(Ron Bonica; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

  From Gen-ART review by Francis Dupont.

  In abstract page 1: s/header/Header/
  BTW as MH is the common abbrev Mobility Header should always get
  the 'H'.  This is not clear for Mobility Option but a choice has
  to be done and applied...

  ToC and section 7: s/Acknowledgements/Acknowledgments/

  Section 1, page 3: s/Proxy MIPv6/Proxy Mobile IPv6/

  The figure in page 3 seems a bit strange because some important and
  decribed fields are not in it. I believe it is directly from RFC 3775
  section 6.1 "Mobility Header" which gives only the content of messages,
  so IMHO this section needs an explicit reference to RFC 3775 section 6.1.

(Sam Hartman; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection

The introduction generally does a nice job identifying message handling requirements
that are inherited from RFC 3775.  One instance was missed, though:  a reader without
a MIPv6 background could interpret the following text (section 1, paragraph 3) as
imposing a new requirement:

   Mobile nodes that do not recognize the mobility message
   type should discard the message and send an ICMP Parameter problem
   with code 0.

I suggest adding a reference to 3775, as with the processing requirements for Home
Agent or correspondent node implementations in the previous sentence.