Subject: [Mip4] RE: LC review: draft-ietf-mip4-dynamic-assignment-05.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Fri, 19 Aug 2005 12:12:45 -0700

Hi Joel.

Comments below.

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Friday, August 19, 2005 11:46 AM
> To: [email-masked]; Henrik Levkowetz; Margaret Wasserman
> Cc: Milind Kulkarni (mkulkarn); Alpesh Patel (alpesh); Kent 
> Leung (kleung); Peter McCann; [email-masked]
> Subject: Re: LC review: draft-ietf-mip4-dynamic-assignment-05.txt
> 
> Gen_Art last call review of  Mobile IPv4 Dynamic Home Agent Assignment
>      draft-ietf-mip4-dynamic-assignment-05.txt
> 
> The General Area Review Team (Gen_Art) serves as a review 
> team for the IETF Chair.
> We are asked to review documents being considered by the 
> IESG, and where possible to provide reviews during or after 
> IETF last call.
> The Gen-Art reviewer is selected by a quasi-random process 
> from the team.
> I have been selected to review this document.
> 
> This is a re-review, following up on a review done of -03.
> 
> 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.  

The HA address field is set to ALL-ZERO-ONE-ADDR to signify that MN is
still registering in dynamic HA assignment mode.  So step 5 of 4.2.1 is
same as step 1 in the section.

So proposed new text in 4.2.1:

5.  If the MN can authenticate the Reply, the MN extracts the HA address
from the Redirected HA Extension.  The MN then sends a Registration
Request to the Redirected HA, unless it has already received a
redirection response from that HA while processing the Registration
Request.  The Home Agent address field in this Registration Request is
set to ALL-ZERO-ONE-ADDR.  The MN may choose to add Requested HA
extension in this new Registration Request.

>(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.)
> 

See above.

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

Hmm, this seems up to date.  Pls provide some more details so we can fix
this up.

Thanks for the review.

Kent

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

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 19 Aug 2005 22:24:50 +0200

> Hmm, this seems up to date.  Pls provide some more details so we can fix

Most of the errors which idnits report on this document is due to
many boilerplate paragraphs being broken up by blank lines, which
prevents recognition.  Manual removal of these added blank lines
reduces the idnits complaints to just one:

  (Expected a match on the following text:
    "Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress.""
  
   ... but found this:
    "Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet Drafts as reference
    material or to cite them other than as "work in progress".")

This is caused by the final full stop being placed outside the quotes,
instead of inside.

Personally, I think this is just fine, but the current guidelines to
handling boilerplate are very rigid and requires verbatim compliance, which
means putting the full stop before the final double quote.  Or take your
chances.

Whatever you do with this, I think fixing the extraneous blank lines in
the middle of the boilerplate paragraphs would be good, though.

	Henrik

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 19 Aug 2005 17:29:33 -0400

The proposed replacement for bullet 5 in 4.2.1 works for me.  Thank you.

With regard to the IPR, Henrik's very nice IDnits checker reports:

     Checking conformance with RFC 3978/3979 boilerplate...
   * The document seems to lack an RFC 3978 Section 5.5 Disclaimer --
     however, there's a paragraph with a matching beginning. Boilerplate
     error?
   * The document seems to lack an RFC 3979 Section 5, para 1 IPR
     Disclosure Acknowledgement -- however, there's a paragraph with a
     matching beginning. Boilerplate error?
   * The document seems to lack an RFC 3979 Section 5, para 2 IPR
     Disclosure Acknowledgement -- however, there's a paragraph with a
     matching beginning. Boilerplate error?

Yours,
Joel

PS: Thank you for the prompt reply.