[Mip4] Review of draft-ietf-mip4-dynamic-assignment-00.txt

[Henrik Levkowetz <henrik at levkowetz.com>]

Hi,

    In parallel with the last call period, I made a review of
draft-ietf-mip4-dynamic-assignment-00.txt .  A number of the comments
in the review was also made during last call.

The full review is available here:
<http://www.mip4.org/tools/rfcmarkup/rfcmarkup.cgi?url=../../reviews/review-ietf-mip4-dynamic-assignment-00.txt&comments=HENRIK>

and a summary is enclosed below.

	Henrik


---------

	
	This draft is on the right track but has open issues, described
	below and in the full review.

	Technical:
	
	* The use of ALL-ZERO-ONE-ADDR instead of a MIPv4 extension
	  to trigger dynamic HA allocation has limitations - it does not
	  permit the use of flags or additional information to
	  distinguish different cases of dynamic HA allocation.  Suggest
	  using an extension in addition to ALL-ZERO-ONE-ADDR.
	  
	* The format of the extension carrying the address of the
	  redirected HA does not follow the format recommended in RFC
	  3344; it would be advantageous to define it so as to support
	  subtypes; and it would be better if the HA address was aligned
	  on a 4-octet boundary.
	  
	* As currently written, the mechanism seems to be broken at
	  this point: In the case of registering through an FA and
	  being re-directed to a second HA, it seems the FA has no way
	  to know that the second registration should be sent to the
	  second HA, while still signalling to the second HA that
	  dynamic HA assignment is active.  This could be resolved
	  by using an extension in addition to the ALL-ZERO-ONE-ADDR.
	
	
	* There is insufficiently clear motivation for permitting the
	  case where HA reassingment is to be done althogh a HA unicast
	  address is given in the RRQ, rather than the ALL-ZERO-ONE-ADDR
	  address.  The unicast address case makes me uncomfortable, and
	  I'd rather see it go.  Eliminating the unicast address case 
	  may be made easier by using an extension in addition to the
	  ALL-ZERO-ONE-ADDR.
	  
	* The circumstances when an FA may send a registration request
	  to an HA different from the one explicitly indicated needs to
	  be strongly limited and clearly described (if not outright
	  eliminated.)
	  
	Editorial:
	  
	* The organisation of the subject matter could be improved
	  somewhat. Possibly a schema similar to the following could be good:
	  I.   Intro & terminology
	  II.  Problem statement
	  III. Protocol overview
	  IV.  Extension format
	  V.   Protocol details
	  VI.  Security considerations, IANA etc.
	  
	* One more detailed observation is that it might be clearer if
	  the 4.1 section was removed or moved after the 4.2 section,
	  as the main case is the redirection case. 
	  
	* The illustrations of the MIP4 registration requests in
	  sections 4.1.1 and 4.2.1 omits some fields, without making
	  that clear; they could do with some re-work. There's a
	  suggestion in the full review.
	
	* There are numerous minor language fixes needed; in the first
	  half of the review such has been marked explicitly.
	  
	* There are a number of too long lines and non-ascii characters
	  in the draft. These are listed at the end of the review, under
	  [idnits-output].  There are also many instances of weird
	  spacing in the document, has it been typeset with
	  justification rather than ragged-right?
	  
	* You should upgrade the boilerplate to match RFC 3667 instead
	  of RFC 2026.  (RFC 3667 was announced 18 Feb 2004, so this is
	  fairly recent.)

--------

-- 
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/