[Mip4] Request to advance draft-ietf-mip4-rfc3344bis-09.txt to Proposed Standard

["McCann Peter-A001034" <[e-mail]>]

>   (1.a) Who is the Document Shepherd for this document? Has the
>         Document Shepherd personally reviewed this version of the 
>         document and, in particular, does he or she believe this 
>         version is ready for forwarding to the IESG for publication? 

The document shepherd is Pete McCann.  Yes, I believe the document
is ready for forwarding to the IESG for publication.

>   (1.b) Has the document had adequate review both from key WG members 
>         and from key non-WG members? Does the Document Shepherd have 
>         any concerns about the depth or breadth of the reviews that 
>         have been performed?  

Yes, and No.

>   (1.c) Does the Document Shepherd have concerns that the document 
>         needs more review from a particular or broader perspective, 
>         e.g., security, operational complexity, someone familiar with 
>         AAA, internationalization or XML? 

No.

>   (1.d) Does the Document Shepherd have any specific concerns or 
>         issues with this document that the Responsible Area Director
>         and/or the IESG should be aware of? For example, perhaps he 
>         or she is uncomfortable with certain parts of the document, or

>         has concerns whether there really is a need for it. In any 
>         event, if the WG has discussed those issues and has indicated 
>         that it still wishes to advance the document, detail those 
>         concerns here. Has an IPR disclosure related to this document 
>         been filed? If so, please include a reference to the 
>         disclosure and summarize the WG discussion and conclusion on 
>         this issue. 

No concerns or issues.  Well-known IPR exists on the Nonce option
that was described way back in RFC 2002 (IBM Patent #5,148,479).
The WG decided to publish that document anyway.  More recently,
IPR disclosures from Cisco and Nortel have arisen:

https://datatracker.ietf.org/ipr/709/
https://datatracker.ietf.org/ipr/850/

There has been little discussion of these two disclosures in the
WG, although the current consensus seems to be to publish anyway.

>   (1.e) How solid is the WG consensus behind this document? Does it 
>         represent the strong concurrence of a few individuals, with 
>         others being silent, or does the WG as a whole understand and 
>         agree with it?   

The WG as a whole has been working with this document for quite some
time, and the improvements in this draft we well understood.

>   (1.f) Has anyone threatened an appeal or otherwise indicated extreme

>         discontent? If so, please summarise the areas of conflict in 
>         separate email messages to the Responsible Area Director. (It 
>         should be in a separate email because this questionnaire is 
>         entered into the ID Tracker.) 

No appeals have been threatened.
 
>   (1.g) Has the Document Shepherd personally verified that the 
>         document satisfies all ID nits? (See the Internet-Drafts
Checklist 
>         and http://tools.ietf.org/tools/idnits/). Boilerplate checks
are 
>         not enough; this check needs to be thorough. Has the document 
>         met all formal review criteria it needs to, such as the MIB 
>         Doctor, media type and URI type reviews? 

The document contains 2 minor boilerplate nits that I do not believe
are blocking.

>   (1.h) Has the document split its references into normative and 
>         informative? Are there normative references to documents that 
>         are not ready for advancement or are otherwise in an unclear 
>         state? If such normative references exist, what is the 
>         strategy for their completion? Are there normative references 
>         that are downward references, as described in [RFC3967]? If 
>         so, list these downward references to support the Area 
>         Director in the Last Call procedure for them [RFC3967]. 

References are split.  All Normative References are of adequate
maturity.

>   (1.i) Has the Document Shepherd verified that the document IANA 
>         consideration section exists and is consistent with the body 
>         of the document? If the document specifies protocol 
>         extensions, are reservations requested in appropriate IANA 
>         registries? Are the IANA registries clearly identified? If 
>         the document creates a new registry, does it define the 
>         proposed initial contents of the registry and an allocation 
>         procedure for future registrations? Does it suggest a 
>         reasonable name for the new registry? See [RFC5226]. If the 
>         document describes an Expert Review process has Shepherd 
>         conferred with the Responsible Area Director so that the IESG 
>         can appoint the needed Expert during the IESG Evaluation? 

The document requests allocation of only one new number from an
existing Mobile IPv4 registry.  This is called out explicitly
in the IANA considerations.  All other number spaces and assignments
were made previously by RFC 3344.

>   (1.j) Has the Document Shepherd verified that sections of the 
>         document that are written in a formal language, such as XML 
>         code, BNF rules, MIB definitions, etc., validate correctly in 
>         an automated checker? 

No such formal languages are used.

>   (1.k) The IESG approval announcement includes a Document 
>         Announcement Write-Up. Please provide such a Document 
>         Announcement Write-Up? Recent examples can be found in the
>         "Action" announcements for approved documents. The approval 
>         announcement contains the following sections: 
> 
>      Technical Summary 
>         Relevant content can frequently be found in the abstract 
>         and/or introduction of the document. If not, this may be 
>         an indication that there are deficiencies in the abstract 
>         or introduction. 

This document is a revision of RFC3344, and makes changes in the
following areas:

* A new error reply code was added for the case when a Foreign
  Agent detects an invalid Home Agent address in a Registration Request.

* Language was changed to allow more than one authorization enabling
  extensions in a Registration Request (RFC3344 says "Exactly one").

* Clarified that the Foreign-Home Authentication Extension MUST NOT
  apply to de-registration messages.

* Added language to clarify that security associations can be
established
  dynamically.

* Added language to clarify that Authentication Extensions may be
  checked by an entity other than a Mobility Agent, such as a AAA
server.

* Clarified that the Care-of address offered by the Foreign Agent
  must also be the Source IP address of a relayed Registration Request.

* Clarified that the Foreign Agent MUST use the NAI extension to
distinguish
  among multiple overlapping Home Addresses from different Mobile Nodes.

* Clarified processing by the Home Agent when it receives a Registration
  Request with an invalid authentication extension.

>      Working Group Summary 
>         Was there anything in WG process that is worth noting? For 
>         example, was there controversy about particular points or 
>         were there decisions where the consensus was particularly 
>         rough? 

We had some contentious issues but I think the discussions and
subsequent resolutions have satisfied all parties.

>      Document Quality 
>         Are there existing implementations of the protocol? Have a 
>         significant number of vendors indicated their plan to 
>         implement the specification? Are there any reviewers that 
>         merit special mention as having done a thorough review, 
>         e.g., one that resulted in important changes or a 
>         conclusion that the document had no substantive issues? If 
>         there was a MIB Doctor, Media Type or other expert review, 
>         what was its course (briefly)? In the case of a Media Type 
>         review, on what date was the request posted? 

Mobile IPv4 is widely implemented and deployed, especially in
cdma2000 networks.  This update was influenced heavily by these
deployments, especially the allowed inclusion of multiple authorization-
enabling extensions that allow Mobile IP to be deployed with a AAA
back-end.



-Pete