[netext] Request to progress Netext WG I-D: draft-ietf-netext-ani-location-06.txt
Basavaraj Patil <bpatil1@gmail.com> Mon, 19 January 2015 21:11 UTC
Return-Path: <bpatil1@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3D51B2C91; Mon, 19 Jan 2015 13:11:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hFCx-6YPq1K; Mon, 19 Jan 2015 13:11:07 -0800 (PST)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA1F1B2C7B; Mon, 19 Jan 2015 13:11:07 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id wo20so30839683obc.13; Mon, 19 Jan 2015 13:11:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=f9gTLuTDAgJN2Gdsf/2jhwzdYhqhSITPq9qCPqumvH4=; b=clunEMuaiai8wlG5fkuFuoVf3aEPFnwu4l4n5x3NmeeRjckZm6l+hLQXzbVkjegLW2 Ix4yAP8dKXiJRxTSJzYYeY4cpSYWmpcE95zSImCBl61zz/sagvbi48cRKWFws8Ju9EKF q8ip3Os0SxG4QCruHpze3vcsv+rVGcqxMH1+Ru4mILPM3S4+iSFBragQ8FhL+V3ACnaj /qwhYpQ3wC/Xq/EQF49DZhNUtfyhFfi0zlPFHkJKeK2zz4CrjOit94UwZXpqbibA6DyX LkY1dZzaKRgsQoZeMwYsa2zZLfj6JteieRHOXGTQO6GZpOwXncIi7XedVSh2rJiKTlB0 Xllw==
MIME-Version: 1.0
X-Received: by 10.60.155.195 with SMTP id vy3mr19625089oeb.62.1421701866260; Mon, 19 Jan 2015 13:11:06 -0800 (PST)
Received: by 10.76.130.176 with HTTP; Mon, 19 Jan 2015 13:11:06 -0800 (PST)
Date: Mon, 19 Jan 2015 15:11:06 -0600
Message-ID: <CAA5F1T0czaGjOvRSK2dokb7UdJdj+vvJE58O9V7F0nz3dyLsBQ@mail.gmail.com>
From: Basavaraj Patil <bpatil1@gmail.com>
To: iesg-secretary@ietf.org
Content-Type: multipart/alternative; boundary="089e0102dc32b70d12050d07c26e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netext/CYFcOrYpLCQrZDQPUIut8VzGSFM>
Cc: "netext@ietf.org" <netext@ietf.org>, "draft-ietf-netext-ani-location@tools.ietf.org" <draft-ietf-netext-ani-location@tools.ietf.org>
Subject: [netext] Request to progress Netext WG I-D: draft-ietf-netext-ani-location-06.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Jan 2015 21:11:11 -0000
Hello, The Netext WG has completed the WG last call and reviews of the I-D: Extensions to the PMIPv6 Access Network Identifier Option <draft-ietf-netext-ani-location-06.txt> The document is ready for IESG review and approval. Please find below the proto writeup. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This I-D is being progressed for publication as a Proposed Standard. The I-D proposes new extensions which will need IANA action and hence the standards track is appropriate. The type of RFC is indicated in the title header of the I-D. (2) The IESG approval announcement includes a Document Announcement Write-Up. Technical Summary: Access Network Identifier (ANI) Mobility option was introduced in Access Network Identifier Option for Proxy Mobile IPv6 (RFC 6757). This enables a Mobility Access Gateway (MAG) to convey identifiers like network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub options to carry civic location and MAG group Identifier. This specification also defines an ANI Update-Timer sub option that determines when and how often the ANI option will be updated. Working Group Summary: The WG initially considered updating RFC 6757 (Access Network Identifier (ANI) Option for Proxy Mobile IPv6). However after considering the scope and the extensions being proposed, it was decided that a separate I-D extending RFC 6757 was a better approach. Consensus was strong to create a new WG I-D and extend RFC6757. Document Quality: Are there existing implementations of the protocol? Not at the present time. Have a significant number of vendors indicated their plan to implement the specification? At least one vendor has expressed plans to implement this 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? All reviewers have been acknowledged in the I-D. 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? The document does not specific a MIB or media type. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Doc Shepherd: Basavaraj Patil AD: Brian Haberman (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document multiple times and provided feedback to the authors. It is now ready for publication and hence being forwarded to the IESG. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns about the depth or breadth of the reviews performed to date. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Do not see a reason for additonal reviews from any specific area. (6) Describe any specific concerns or issues that the Document Shepherd has 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. There are no concerns or issues with this I-D. The working group supports this I-D and its publication. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. All authors have confirmed conformance with the provisions of BCP 78, 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No known IPR disclosures have been filed that reference this document. (9) How solid is the WG consensus behind this document? WG consensus is strong. 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 and the extension to RFC 6757 being proposed therein. There is general agreement in the WG about the need for this extension. (10) 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 publicly available.) There is no disagreement or discontent in the working group regarding this document. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No major ID nits. Output from checking is : Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No MIB, media type of URI types are specified in the document. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? All normative references are published RFCs. If such normative references exist, what is the plan for their completion? N/A (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Yes. Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? Yes. Listed in the abstract. If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. N/A (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA section is clear in terms of the instructions. There is no requirement to create a new registry for this I-D. The registry where the IANA assignments will be maintained is clearly indicated. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registry is being requested. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No XML code, BNF rules, MIBs etc. are specified in the document. Rgds, -Raj -- Basavaraj Patil
- [netext] Request to progress Netext WG I-D: draft… Basavaraj Patil