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

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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."

[Ballot comment]
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.