[Mip4] Request to advance draft-ietf-mip4-generic-notification-message-08.txt to Proposed Standard

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

Dear iesg-secretary,

This is a request to advance the document:
draft-ietf-mip4-generic-notification-message-08.txt
to Proposed Standard RFC status.  Please see the questionnaire answers
below.


>   (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?

Document shepherd: Pete McCann
I have reviewed this version of the I-D and believe it is ready for IESG
review and 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?

The document received several reviews from key WG members and comments
were incorporated.  No review by non-WG members has been performed.  I
have no concerns about the depth or breadth of the reviews.

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

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

A few typos exist that can be addressed after Last Call:

Section 4.1:

   IP Fields:

     Source Address         Same as the last Registration Reply/Request
                            message received.

     Destination Address    Same as the last Registration Reply/Request
                            message.

Should say:

   IP Fields:

     Source Address         Same as the last Registration Reply/Request
                            message sent.

     Destination Address    Same as the last Registration Reply/Request 
                            message sent.

Should also add the word "sent" to the UDP Source Port/Destination Port
descriptions.

Section 4.2:

     Source Port            Copied from the source port of the
                            corresponding GNM.
Should say:
     Source Port            Copied from the destination port of the
                            corresponding GNM.


>   (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 understands the document.  There is good consensus
to advance it.

>   (1.f)  Has anyone threatened an appeal or otherwise indicated
extreme
>          discontent?  If so, please summarize 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
>          http://www.ietf.org/ID-Checklist.html 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?  If the document
>          does not already indicate its intended status at the top of
>          the first page, please indicate the intended status here.

The idnits tool returns several warnings, but they mainly seem to be
red herrings and boilerplate issues.

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

The document has only normative references.  No downrefs exist in the 
normative references section.

>   (1.i)  Has the Document Shepherd verified that the document's IANA
>          Considerations 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 [RFC2434].  If the
>          document describes an Expert Review process, has the Document
>          Shepherd conferred with the Responsible Area Director so that
>          the IESG can appoint the needed Expert during IESG
>          Evaluation?

The IANA considerations is complete.  There are two assignments needed
from the Mobile IP Message Type number space, and the new GNM Sub-Type
space is created and populated with some initial values.

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

   The Generic Notification Message for Mobile IPv4 augments the
original
   registration process of Mobile IPv4, which supports only mobile-node
   initiated signaling, with two new messages.  The Generic Notification
   Message can be generated by any mobility agent and directed at any
other
   mobility agent, and the Generic Notification Acknowledgement Message
can
   be sent in response.  The new mechanism is expected to be a useful
container 
   for information exchange and session management between the three
kinds of
   mobility agents.

Working Group Summary

   The document underwent Working Group Last call in April 2008 and was
   improved based on lengthy subsequent discussion.  In particular, the
   security considerations were updated to describe the timestamp-based
   replay protection mechanism and clock re-synchronization.

Document Quality

  The document was reviewed for quality by Pete McCann.

Personnel

   Document shepherd: Pete McCann
   Responsible AD: Jari Arkko