Subject: [Mip6] Request to forward to IESG MIP6 I-D: draft-ietf-mip6-dsmip-problem-02.txt

From: Basavaraj Patil <[email-masked]>
Date: Wed, 20 Dec 2006 12:25:13 -0600

Hi Jari,

The MIP6 WG I-D: Mobility management for Dual stack mobile nodes: A
Problem Statement  <draft-ietf-mip6-dsmip-problem-02.txt> has
completed WG last call. It is ready to be moved forward in the
process. The completed IESG template for the I-D is below. Please note
that the status sought for this I-D is Informational.

-Raj

------------------------------------

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

Basavaraj Patil. I have reviewed the I-D and believe it is ready to be
forwarded 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. A joint WG LC (MIP6/4) was done for this I-D since the problem
statement is applicable to both. I do not have any concerns about the
depth or breadth of the reviews. I believe it has been reviewed
sufficiently. 

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

The document has had adequate review and I do not believe further or
extended reviews are necessary.

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

I do not have any concerns in moving forward with this I-D in the
standards process.

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

Solid WG consensus exists behind this document. Both the MIP6 and MIP4
WGs agree with this document contents.

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

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

There are a few I-D nits abd boiler-plate problems. These will be
addressed following the AD comments and a subsequent revision.

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

No. This is on an Informational track and is a problem statement
draft. There are some corrections needed to the references
section. The MIP6 reference is incorrect. These will be addressed in
the next revision as part of either addressing the AD comments or
during the RFC ed. process.

   (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 suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  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?

This is a problem statement I-D. No specific protocol extensions or
IANA requirements exist.

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

Does not apply. This is a problem statement I-D.

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Writeup?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

  This draft discusses the issues associated with mobility management
   for dual stack mobile nodes. Currently, two mobility management
   protocols are defined for IPv4 and IPv6. Deploying both in a dual
   stack mobile node introduces a number of inefficiencies. Deployment
   and operational issues motivate the use of a single mobility
   management protocol. This draft discusses such motivations. The draft
   also hints on how the current MIP4 and MIP6 protocols could be
   extended so that they can support mobility management for a dual
   stack node. 

          Working Group Summary

This I-D was initially produced as a problem statement for the MIP6
WG. However subsequently it was noted that it applied to MIP4 as
well. Hence the I-D is now considered as being applicable to the MIP4
and MIP6 WGs. There is consensus behind this document and the need to
address the problem.

          Document Quality

The I-D is a problem statement document. The quality of the document
is good.

          Personnel
             Who is the Document Shepherd for this document?  Who is the
             Responsible Area Director?

Document shepherd: Basavaraj Patil
Responsible AD: Jari Arkko

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6