[netext] Request to progress I-D: draft-ietf-netext-pmipv6-sipto-option-06
Basavaraj Patil <bpatil1@gmail.com> Tue, 16 October 2012 20:31 UTC
Return-Path: <bpatil1@gmail.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251DA11E80E9; Tue, 16 Oct 2012 13:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTmFIj8h4rJ5; Tue, 16 Oct 2012 13:30:59 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 38ED711E80E6; Tue, 16 Oct 2012 13:30:59 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id o25so5652435iad.31 for <multiple recipients>; Tue, 16 Oct 2012 13:30:58 -0700 (PDT)
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=+NgpTM/cEoyYuEBrf232O2J/Sm5J1m5+Lu+Gufm5jbQ=; b=pn/Pynt4X6BpgvYSEOkpDCbMa+fjPFYcxdUD/MAx/4R9lYoupy9VF0IV1JvkNPUqfw +6ir4w6NYxv2xrDkEoZStvpok/KSf60KP+nerAsRTSjY28aHHwFl/l+g8C4bsXaS7y3s UO8jhZLhJzCv3LrTXYgFy6hPLnMMuhYyLPR8OI/YCXCxAiHFv/8xyRlFhG/RgCArn2Cw +XaiNa9dZw1v533gIVMwRzRaZ9wWVTQ0pNp9VXfPs1E8G0HXxd4Z1b7kIWQO8YdsC9kC kGZKVVowsrmqsSc6Aq6AiDVcblh+fpO8qaNojm42gXpIejXc5fGyg4f0xWF1GF90MbMP om2Q==
MIME-Version: 1.0
Received: by 10.50.46.134 with SMTP id v6mr13420281igm.55.1350419458680; Tue, 16 Oct 2012 13:30:58 -0700 (PDT)
Received: by 10.43.89.1 with HTTP; Tue, 16 Oct 2012 13:30:58 -0700 (PDT)
Date: Tue, 16 Oct 2012 15:30:58 -0500
Message-ID: <CAA5F1T0T6Cug=cUe-Pu4c5WjGZekFOv4eVJJ4mg-bdhCTwGBQQ@mail.gmail.com>
From: Basavaraj Patil <bpatil1@gmail.com>
To: iesg-secretary@ietf.org
Content-Type: multipart/alternative; boundary="14dae9340f5321e6da04cc3308ad"
X-Mailman-Approved-At: Tue, 16 Oct 2012 13:34:57 -0700
Cc: netext@ietf.org, netext-chairs@tools.ietf.org
Subject: [netext] Request to progress I-D: draft-ietf-netext-pmipv6-sipto-option-06
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 16 Oct 2012 20:32:37 -0000
Hello, The Netext WG has completed working group last call on the I-D: draft-ietf-netext-pmipv6-sipto-option The I-D is ready for IESG review and publication. Please find below the proto writeup for this Netext WG document. I-D: draft-ietf-netext-pmipv6-sipto-option-06.txt Title: IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 (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? Type of RFC being requested: Proposed Standard The I-D proposes a new option to be included for use in Proxy Mobile IPv6 signalng (RFC5213) and hence a proposed standard status is being requested for the document. The title page header of the I-D requests a Proposed standard status for the RFC. (2) 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 specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. The intent of the option being defined in this I-D is to enable IPv4 traffic associated with a mobile node to be routed from the access network itself instead of having to tunnel it back to the home network (Local Mobility Agent). Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There is nothing unusual about this I-D or WG process w.r.t this I-D that is noteworthy. The I-D has been presented and discussed at various IETF meetings and has been reviewed by several WG members and chair. Since one of the co-authors (Rajeev Koodli) is also a Netext WG chair, he has recused himself from the review or shepherding process and I am acting as the sole chair with responsibility for this I-D. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the 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? 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? Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document shepherd: Basavaraj Patil (NetExt WG Co-chair) Responsible 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 (Basavaraj Patil) have reviewed the I-D multiple times and provided feedback to the authors. The authors have made efforts to address my comments and resolve them. The current version of the I-D is ready to be progressed to the IESG since the proposed option/extension to Proxy MIP6 signaling is quite clear as specified in the I-D. The authors are likely to revise the I-D further based on some additional comments that I have sent them. However I believe that the I-D in its current state is ready for IESG review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. The I-D has been reviewed by WG members who understand the protocol well as well as people outside the WG. (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. There is some ambiguity regarding the interaction with policy servers and protocols used for such. However the I-D clearly indicates that such interaction is out of scope of this I-D. The focus of this I-D is to specify the option that allows selective IPv4 traffic offloading using NAT functionality in the access network. And hence the policy aspects which are described in the I-D are not part of the core functionality being specified here. (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. As document shepherd, I have expressed some reservations about parts of the I-D which explain how an LMA sets the traffic selectors or how a MAG chooses the traffic selectors to be sent as a proposal in the request. The WG has discussed these issues in the past and I have raised the same with the authors. There are no concerns about these scenarios and it is okay to advance the document. (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? Each author has confirmed that all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and 79 have been met. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) 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 behind this I-D. While a few are very vocal and strongly support it the WG as a whole understands its need and supports it. (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.) No. (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. None. As per IDnits tool: Summary: 0 errors (**), 0 warnings (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not define any MIBS, media types or URI types. (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? If such normative references exist, what is the plan for their completion? No. All normative references are existing RFCs. (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? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? 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. No. Publication of this document will not change the status of existing Proxy Mobile IPv6 RFCs. This is an extension to RFC5213 and does not affect the base protocol. (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). I have reviewed the IANA considerations section and it is consistent with the body of the document. The instructions for assignment by IANA are clear. (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 IANA registries are needed or require expert review for future allocations. (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. Document does not specify any XML code, BNF rules or, MIB definitions and hence no such reviews have been performed. -Basavaraj -- Basavaraj Patil
- [netext] Request to progress I-D: draft-ietf-neteā¦ Basavaraj Patil