Subject: [Mip6] Request to progress MIP6 WG I-D: draft-ietf-mip6-bootstrapping-split-04.txt

From: Basavaraj Patil <[email-masked]>
Date: Wed, 20 Dec 2006 15:34:33 -0600

Hi Jari,

The MIP6 WG I-D: "Mobile IPv6 bootstrapping in split scenario",
<draft-ietf-mip6-bootstrapping-split> has completed WG last call and
is ready for IESG review and publication. Revision 4 of the I-D has
been submitted to address ID-nits and boiler plate issues.

Status sought for this I-D: Standards track

Please review and progress the I-D thru the standards process.

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

Document shepherd: Basavaraj Patil
I have reviewed 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?

It has been reviewed by several WG members and also been discussed and
presented at several IETF MIP6 WG meetings. The depth and breadth of
reviews are sufficient. In terms of non-WG members reviewing this I-D,
there are not many who have been able to review it since it requires a
good understanding of the MIP6 protocol.

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

I think the reviews are sufficient for it to be progressed forward. I
o not think any additional reviews are essential.

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

No specific concerns or issues at this time.

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

There is a strong consensus on the need for bootstrapping
solutions. This I-D is one of the solutions based on the bootstrapping
PS (RFC4640). The WG as a whole is in general agreement.

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

I have verified the document for ID-nits. It meets all formal review
criteria. No media types of URI types are defined in this I-D.

   (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 have been split into normative and informative ones. The
normative reference to draft-ietf-mip6-ikev2-ipsec is the only
significant one of concern. This I-D has completed IETF LC and the
issues arising out of that are being addressed. So there is no problem
advancing this draft as the IKEv2 for MIP6 spec is expected to be
complete fairly soon.

The reference to the PS I-D is incorrect. It needs to be changed to
the Bootstrap PS RFC (4640). This will be done in the next revision as
part of addressing any AD review comments.

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

The IANA considerations section provides sufficient information for
IANA to assign the values being defined by this I-D. It does not
propose the creation of a new registry. The MIP6 registry should be
used. The document does not define an expert review process.

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

The document does not have any XML or BNF content. No MIB definitions
are specified in this 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
  A Mobile IPv6 node requires a Home Agent address, a home address,
  and IPsec security associations with its Home Agent before it can
  start utilizing Mobile IPv6 service. RFC 3775 requires that some or
  all of these are statically configured. This document defines how a
  Mobile IPv6 node can bootstrap this information from non-topological
  information and security credentials preconfigured on the Mobile
  Node. The solution defined in this document solves the bootstrapping
  problem from draft-ietf-mip6-bootstrapping-ps-02 when the Mobile
  Node's mobility service is authorized by a different service
  provider than basic network access, and is therefore generically
  applicable to any bootstrapping case.

          Working Group Summary

No major concerns or issues have come up in the WG w.r.t this I-D.

          Document Quality

No known implementations of this protocol are available at this
time. Several WG members have indicated plans to implement this
specificaation. This work is also relevant for bootstrapping of MIP6
and may be adopted by other SDOs. All relevant reviewers and
contributors have been acknowledged.

          Personnel

Document Shepherd: Basavaraj Patil
Responsible Area Director: Jari Arkko

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