Skip to main content

Fast Handovers for Mobile IPv6
draft-ietf-mipshop-fast-mipv6-03

Yes

(Thomas Narten)

No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Scott Hollenbeck)

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

Thomas Narten Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection (2004-09-16) Unknown
I've reviewed the use of the Experimental ICMPv6 format wrt to the other users, CARD and
CTP.  I'm not sure IANA can start assignment with 0, so the requested values may be 
incorrect.

The discussion of the benefits from fast handoff is compelling - should the draft include text 
describing the terms of experiment:  how the protocol will be evaluated and developed towards becoming standards track?  or is this in the working group's charter?
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-09-16) Unknown
Reviewed by John Loughney, Gen-ART

His review:

Conflict of interest warning, the author of this draft is from the same
lab here at NRC as I am in.

Sumary: this is an experimental protocol from the MIPSHOP working group.
I think that the protocol is reasonable explained and IANA Considerations
& Security sections are covered in a reasonable manner for an experimental
document, so this should be approved.  A few nits were found.

Nits:

1) `` and '' characters should be replaced with "
2) Double blank line spacing throughout document.
3) MN abbreviation used before it is defined (section 19.
4) ``IP connectivity'' latency is used as a term, defining
   this might be a good idea.
5) IP-capable is used as a term, defining this might be a good idea.
6) Disclaimer of validity, Full Copyright Statement, etc. shouldn't be
   listed as appendicies.
7) Full Copyright Statement says: Copyright (C) The Internet Society (year).  
   probably want to fill the (year) part with 2004.
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2004-09-14) Unknown
  The Security Considerations say:
  :
  : ... However, the future work, either as part of this document or in a
  : separate document, may specify this security establishment.
  :
  Obviously, future work cannot be part of this document.  A subsequent
  update to this document is possible.  Also, please change "security
  establishment" to "security association establishment."
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Steven Bellovin Former IESG member
No Objection
No Objection (2004-09-13) Unknown
For an Experimental RFC, the security discussion is adequate.  It is *not* adequate for a standards track document.  The suggested work on security MUST take place.  I caution the authors that many of the AH security associations mentioned in the text are going to be very hard to set up, since the mobile node may have no a priori way to determine the authorized Access Routers.