Document:  draft-ietf-mip4-dynamic-assignment-05.txt 
Reviewer: Joel M. Halpern [joel@stevecrocker.com]
Review Date: Friday 8/19/2005 1:46 PM CST 
Telechat Date:  18 Aug 2005
LC Review: draft-ietf-mip4-dynamic-assignment-03-halpern.txt

Summary: This draft is almost ready for publication as a Proposed Standard 
RFC.  However, one item that had been noted earlier still leaves room for 
ambiguity about certain fields:

Sections 4.2 and 4.2.1 still do not identify what value is placed in the HA 
Address field of the second registration request, after the redirect has 
been received.  Whatever behavior is intended (put the new HA address in 
the HA Address field, or continue to put ALL-ZERO-ONE-ADDR in the HA 
Address field to allow for further redirection, or either one) should be 
stated.  This was in my earlier comments, and had been acknowledged as 
reasonable.  (Sections 5.1.1 and 5.1.2 note that the new HA address must be 
placed in the Requested HA Extensions, but that does not answer the 
question of what goes in the HA Address field of the packet.)

Nits:
     This document is using an out of date IPR clause.  I don't know if it 
needs to be updated. 

 
----------------------------------------------------------------------------------
Document: draft-ietf-mip4-dynamic-assignment-03.txt
Review: Joel M. Halpern
Date: 15 mars 2005 


This document is nearly ready for publication as a Proposed Standard.  
I believe a revision is underway and it would be desirable if the 
following minor comments could be addressed in that revision.

Minor comments:
In section 4.2, step 4, when describing the MN re-registering with the 
HA it has been redirected to, I infer that it is supposed to use a 
normal registration rather than an ALL-ZEDRO-ONE-ADDR registration with 
a Requested HA extension pointing to the new HA.  The text should state 
explicitly what fields are to be used in the second registration.  
(Text in section 5.1.1 and 5.1.2 seems to imply that the Requested HA 
extensions should be used for the second registration.)

The last paragraph of section 5.1.1 says:
    If the Registration Request contains the Requested HA Extension,
    the HA address in that extension MUST match the destination IP
    of the Request.
This seems to be about the Registration Request from the MN, which in 
this case is going to the FA.  So the destination IP address is the FA, 
not the HA, I think.  (At a guess, this text belongs in 5.1.2.)