[Mip4] Request to advance draft-ietf-mip4-nemo-v4-base-06.txt to Proposed Standard

"McCann Peter-A001034" <pete.mccann@motorola.com> Wed, 31 October 2007 18:13 UTC

Return-path: <mip4-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InI4e-0000zO-Bx; Wed, 31 Oct 2007 14:13:52 -0400
Received: from mip4 by megatron.ietf.org with local (Exim 4.43) id 1InI4d-0000qq-6P for mip4-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 14:13:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InI4c-0000pH-SP; Wed, 31 Oct 2007 14:13:50 -0400
Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InI4b-0003Ck-HT; Wed, 31 Oct 2007 14:13:50 -0400
X-VirusChecked: Checked
X-Env-Sender: pete.mccann@motorola.com
X-Msg-Ref: server-12.tower-128.messagelabs.com!1193854426!14696736!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.101]
Received: (qmail 16998 invoked from network); 31 Oct 2007 18:13:46 -0000
Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-12.tower-128.messagelabs.com with SMTP; 31 Oct 2007 18:13:46 -0000
Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l9VIDf4j002984; Wed, 31 Oct 2007 11:13:46 -0700 (MST)
Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id l9VIDeq3028910; Wed, 31 Oct 2007 13:13:40 -0500 (CDT)
Received: from de01exm67.ds.mot.com (de01exm67.am.mot.com [10.176.8.18]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id l9VIDd2N028899; Wed, 31 Oct 2007 13:13:39 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 Oct 2007 14:13:37 -0400
Message-ID: <BE4B07D4197BF34EB3B753DD34EBCD130200DCF8@de01exm67.ds.mot.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Request to advance draft-ietf-mip4-nemo-v4-base-06.txt to Proposed Standard
Thread-Index: Acgb6cIfwzfYovScSOahQlI0lMnNnQ==
From: McCann Peter-A001034 <pete.mccann@motorola.com>
To: IESG Secretary <iesg-secretary@ietf.org>
X-CFilter-Loop: Reflected
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: mip4@ietf.org
Subject: [Mip4] Request to advance draft-ietf-mip4-nemo-v4-base-06.txt to Proposed Standard
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Errors-To: mip4-bounces@ietf.org

Dear iesg-secretary,

This is a request to advance the document
draft-ietf-mip4-nemo-v4-base-06.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 draft has been reviewed extensively by the working group, but
has not gotten much exposure to non-WG members.  I have no concern
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?

Perhaps the draft would benefit by some review from the Routing
Area, due to its mention of running dynamic routing protocols
over the tunnel between MN and HA.  Hopefully this can happen 
as part of IETF last call.

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

I have no areas of concern.  No disclosures relating to the draft
have been filed at this time.  However, there is a rumor that one
company does indeed hold IPR on the solution.

>   (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 strong WG consensus to advance the document.  Consensus to
advance it was exhibited during WGLC.

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

No nits were found during automatic checking or manual inspection.
The document does have 2 informative references to drafts, which
should be published in the not-to-distant future.

>   (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 split references into normative and informative sections.
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 section is in the document and is complete.
The document creates two new number spaces, each with an assignment
policy of "Expert Review."  We have not yet designated an Expert,
but will confer with the ADs soon.

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

  This document defines some new extensions to Mobile IPv4 that
  allow the Mobile Node to communicate with the Home Agent about
  additional network prefixes that it may serve in the capacity
  of a Mobile Router.  A Mobile Router can be used to provide
  connectivity and mobility to an entire mobile network without
  any modification to other nodes in the mobile network.

  While it is technically possible to create a Mobile Router through
  static configuration, this extension allows the network prefixes
  to be signaled in Registration Request and Reply messages, so that
  the MN and HA can be explicit about which networks are requested
  and granted to the Mobile Router.

Working Group Summary

  The working group made some recent changes to indicate that this
  is just an extension to the Mobile IPv4 protocol, rather than a
  new mobility management protocol.  The document went through last
  call without any major disagreements coming up.

Document Quality

  The document was reviewed for quality by Pete McCann.

Personnel

   Document shepherd: Pete McCann
   Responsible AD: Jari Arkko


-- 
Mip4 mailing list: Mip4@ietf.org
    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/