Mobile IPv6 Experimental Messages
RFC 5096
Yes
(Jari Arkko)
No Objection
(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Sam Hartman)
(Tim Polk)
Note: This ballot was opened for revision 03 and is now closed.
Lars Eggert
No Objection
Comment
(2007-09-20)
Unknown
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 IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2007-09-17)
Unknown
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 IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2007-09-18)
Unknown
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.