From nobody Mon Jan 5 09:46:30 2015 Return-Path: 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 716FA1A871D; Mon, 5 Jan 2015 09:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 purBqPLbZatE; Mon, 5 Jan 2015 09:46:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D67C21A6F3A; Mon, 5 Jan 2015 09:46:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105174625.13085.8511.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 09:46:25 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/3y2W6V7er2IDerdowzRaWd795ho Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-16.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 17:46:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : EAP Attributes for Wi-Fi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-16.txt Pages : 18 Date : 2015-01-05 Abstract: With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP-AKA (and EAP-AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above- mentioned functions in such networks. The attributes are exchanged between a client (such as a Mobile Node) and its network counterpart (such as a AAA server) in the service provider's infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 5 10:22:54 2015 Return-Path: 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 41CE91A8777; Mon, 5 Jan 2015 10:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, USER_IN_WHITELIST=-100] 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 qzdZl9MvqH5S; Mon, 5 Jan 2015 10:22:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEED1A879D; Mon, 5 Jan 2015 10:22:32 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150105182232.16842.18193.idtracker@ietfa.amsl.com> Date: Mon, 05 Jan 2015 10:22:32 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/OSXsEPzeFaNhM5zCM09YzeEiwoM Cc: netext mailing list , netext chair , RFC Editor Subject: [netext] Document Action: 'EAP Attributes for Wi-Fi - EPC Integration' to Informational RFC (draft-ietf-netext-wifi-epc-eap-attributes-16.txt) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 18:22:50 -0000 The IESG has approved the following document: - 'EAP Attributes for Wi-Fi - EPC Integration' (draft-ietf-netext-wifi-epc-eap-attributes-16.txt) as Informational RFC This document is the product of the Network-Based Mobility Extensions Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ Technical Summary: With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. Working Group Summary: This document has been in a dormant state for a while. There is no controversy regarding the document. Using EAP attributes to address a problem that is faced in mobile networks when attaching via WiFi is one solution. And there is enough consensus in the WG w.r.t the solution. Document Quality: There are no known implementations of the attributes for EAP defined by this document. At this time there is'nt any indication from vendors or 3GPP to use the approach specified by this document. The document has acknowledged the one person who has helped in improving the specification. The document does not specify any media type or MIB and hence no specialists have been consulted for reviews. Personnel: Document Shepherd: Basavaraj Patil Responsible AD: Brian Haberman From nobody Fri Jan 16 11:59:49 2015 Return-Path: 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 2A8641B2B05; Fri, 16 Jan 2015 11:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 spp1W1T2JirX; Fri, 16 Jan 2015 11:59:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7921ACEE4; Fri, 16 Jan 2015 11:59:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150116195944.22778.69169.idtracker@ietfa.amsl.com> Date: Fri, 16 Jan 2015 11:59:44 -0800 Archived-At: Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-ani-location-06.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 19:59:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Extensions to the PMIPv6 Access Network Identifier Option Authors : Rajesh S. Pazhyannur Sebastian Speicher Sri Gundavelli Jouni Korhonen John Kaippallimalil Filename : draft-ietf-netext-ani-location-06.txt Pages : 12 Date : 2015-01-16 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-ani-location-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 19 13:11:15 2015 Return-Path: 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: From: Basavaraj Patil To: iesg-secretary@ietf.org Content-Type: multipart/alternative; boundary=089e0102dc32b70d12050d07c26e Archived-At: Cc: "netext@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 21:11:11 -0000 --089e0102dc32b70d12050d07c26e Content-Type: text/plain; charset=UTF-8 Hello, The Netext WG has completed the WG last call and reviews of the I-D: Extensions to the PMIPv6 Access Network Identifier Option 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 --089e0102dc32b70d12050d07c26e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

The Netext WG has= completed the WG last call and reviews of the I-D: Extensions to the PMIPv= 6 Access Network Identifier Option <draft-ietf-netext-ani-location-06.tx= t>

The document is ready for IESG review and ap= proval.

Please find below the proto writeup.
=


(1) What type of RFC is being reque= sted (BCP, Proposed Standard,
Internet Standard, Informational, E= xperimental, or Historic)? Why is
this the proper type of RFC? Is= this type of RFC indicated in the
title page header? =C2=A0

This I-D is being progressed for publication as a Prop= osed Standard.
The I-D proposes new extensions which will need IA= NA action and hence
the standards track is appropriate.=C2=A0
The type of RFC is indicated in the title header of the I-D.=C2=A0


(2) The IESG approval announcement i= ncludes a Document Announcement
Write-Up.=C2=A0

Technical Summary:

=C2=A0 =C2=A0Access Net= work Identifier (ANI) Mobility option was introduced in
=C2=A0 = =C2=A0Access Network Identifier Option for Proxy Mobile IPv6 (RFC 6757).
=C2=A0 =C2=A0This enables a Mobility Access Gateway (MAG) to convey= identifiers
=C2=A0 =C2=A0like network identifier, geolocation, a= nd operator identifier.=C2=A0 This
=C2=A0 =C2=A0specification ext= ends the Access Network Identifier mobility option
=C2=A0 =C2=A0w= ith sub options to carry civic location and MAG group Identifier.
=C2=A0 =C2=A0This specification also defines an ANI Update-Timer sub optio= n that
=C2=A0 =C2=A0determines when and how often the ANI option = will be updated.

Working Group Summary:
=
The WG initially considered updating RFC 6757 (Access Networ= k
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 approac= h.=C2=A0
Consensus was strong to create a new WG I-D and extend R= FC6757.=C2=A0

Document Quality:

Are there existing implementations of the protocol?

=C2=A0 Not at the present time.

Have a si= gnificant number of vendors indicated their plan to implement
the= specification?=C2=A0

=C2=A0 At least one vendor h= as expressed plans to implement this
=C2=A0 specification.=C2=A0<= /div>

Are there any reviewers that merit special mention= as having done a
thorough review, e.g., one that resulted in imp= ortant changes or a
conclusion that the document had no substanti= ve issues?=C2=A0
=C2=A0=C2=A0
=C2=A0 All reviewers have been acknowledged in t= he I-D.=C2=A0

If there was a MIB Doctor, Media Typ= e or other expert review, what was
its course (briefly)? In the c= ase of a Media Type review, on what date
was the request posted? = =C2=A0

=C2=A0 The document does not specific a MIB= or media type.=C2=A0


Personnel:

Who is the Document Shepherd? Who is the Responsible= Area Director?

=C2=A0 =C2=A0Doc Shepherd: Basavar= aj Patil
=C2=A0 =C2=A0AD: Brian Haberman
=C2=A0=C2=A0

(3) Briefly describe the review of this document th= at was performed by
the Document Shepherd. If this version of the= document is not ready
for publication, please explain why the do= cument is being forwarded to
the IESG.=C2=A0

=
=C2=A0 =C2=A0I have reviewed the document multiple times and provided = feedback
=C2=A0 =C2=A0to the authors. It is now ready for publica= tion and hence being
=C2=A0 =C2=A0forwarded to the IESG.=C2=A0

(4) Does the document Shepherd have any concerns abo= ut the depth or
breadth of the reviews that have been performed?= =C2=A0

=C2=A0 No concerns about the depth or bread= th of the reviews performed to
=C2=A0 date.=C2=A0

<= /div>
(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 th= e review that
took place.=C2=A0

=C2=A0 = =C2=A0Do not see a reason for additonal reviews from any specific area.=C2= =A0

(6) Describe any specific concerns or issues t= hat the Document
Shepherd has with this document that the Respons= ible Area Director
and/or the IESG should be aware of? For exampl= e, perhaps he or she is
uncomfortable with certain parts of the d= ocument, or has concerns
whether there really is a need for it. I= n any event, if the WG has
discussed those issues and has indicat= ed that it still wishes to
advance the document, detail those con= cerns here.=C2=A0

=C2=A0 =C2=A0There are no concer= ns or issues with this I-D. The working group
=C2=A0 =C2=A0suppor= ts this I-D and its publication.=C2=A0


<= div>(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?=C2=A0

=C2=A0 =C2=A0Yes. All authors have confirmed conforma= nce with the provisions of
=C2=A0 =C2=A0BCP 78, 79.=C2=A0

(8) Has an IPR disclosure been filed that references this= document? If
so, summarize any WG discussion and conclusion rega= rding the IPR
disclosures.=C2=A0

=C2=A0 = No known IPR disclosures have been filed that reference this
=C2= =A0 document.=C2=A0

(9) How solid is the WG consen= sus behind this document?=C2=A0

=C2=A0 =C2=A0 WG c= onsensus is strong.=C2=A0

Does it represent the st= rong concurrence of a few individuals, with others
being silent, = or does the WG as a whole understand and agree with it?=C2=A0
=C2=A0 =C2=A0The WG as a whole understands the document and the= extension to RFC
=C2=A0 =C2=A06757 being proposed therein. There= is general agreement in the WG
=C2=A0 =C2=A0about the need for t= his extension.=C2=A0

(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 bec= ause this questionnaire is publicly available.)=C2=A0

<= div>=C2=A0 =C2=A0There is no disagreement or discontent in the working grou= p
=C2=A0 =C2=A0regarding this document.=C2=A0

(11) Identify any ID nits the Document Shepherd has found in this
Internet-Drafts Checklist)= . Boilerplate checks are not enough; this
check needs to be thoro= ugh.=C2=A0

=C2=A0 =C2=A0No major ID nits.=C2=A0

Output from checking is :
=C2=A0 =C2=A0Sum= mary: 0 errors (**), 0 flaws (~~), 1 warning (=3D=3D), 1 comment (--).

(12) Describe how the document meets any required form= al review
criteria, such as the MIB Doctor, media type, and URI t= ype reviews.=C2=A0

=C2=A0 =C2=A0No MIB, media type= of URI types are specified in the document.=C2=A0

(13) Have all references within this document been identified as
either normative or informative?=C2=A0

=C2=A0 =C2= =A0Yes.=C2=A0

(14) Are there normative references = to documents that are not ready
for advancement or are otherwise = in an unclear state?=C2=A0

=C2=A0 =C2=A0All normat= ive references are published RFCs.

If such normati= ve references exist, what is the plan for their
completion?=C2=A0=

=C2=A0 =C2=A0N/A

(15) Ar= e there downward normative references references (see RFC
3967)? = If so, list these downward references to support the Area
Directo= r in the Last Call procedure.=C2=A0

=C2=A0 =C2=A0N= o.=C2=A0

(16) Will publication of this document ch= ange the status of any
existing RFCs?=C2=A0
=C2=A0 =C2= =A0
=C2=A0 =C2=A0Yes.=C2=A0

Are those RF= Cs listed on the title page header, listed
in the abstract, and d= iscussed in the introduction?=C2=A0

=C2=A0 =C2=A0Y= es. Listed in the abstract.=C2=A0

If the RFCs are = not listed in the Abstract and Introduction, explain
why, and poi= nt to the part of the document where the relationship of
this doc= ument to the other RFCs is discussed. If this information is
not = in the document, explain why the WG considers it unnecessary.=C2=A0

=C2=A0 =C2=A0N/A

(17) Describe t= he Document Shepherd's review of the IANA
considerations sect= ion, especially with regard to its consistency with
the body of t= he document. Confirm that all protocol extensions that
the docume= nt 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,<= /div>
that allocations procedures for future registrations are defined,= and
a reasonable name for the new registry has been suggested (s= ee RFC
5226).=C2=A0

=C2=A0 =C2=A0 The IA= NA section is clear in terms of the instructions. There is
=C2=A0= =C2=A0 no requirement to create a new registry for this I-D.=C2=A0

=C2=A0 =C2=A0 The registry where the IANA assignments wil= l be maintained is
=C2=A0 =C2=A0 clearly indicated.=C2=A0

(18) List any new IANA registries that require Expert Rev= iew for
future allocations. Provide any public guidance that the = IESG would
find useful in selecting the IANA Experts for these ne= w registries.=C2=A0

=C2=A0 =C2=A0No new registry i= s being requested.=C2=A0

(19) Describe reviews and= automated checks performed by the Document
Shepherd to validate = sections of the document written in a formal
language, such as XM= L code, BNF rules, MIB definitions, etc.=C2=A0

=C2= =A0 =C2=A0No XML code, BNF rules, MIBs etc. are specified in the document.<= /div>


Rgds,
-Raj


-- 
Basavaraj Patil




--089e0102dc32b70d12050d07c26e--


From nobody Fri Jan 23 08:45:20 2015
Return-Path: 
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 2C3C71A87AC for ; Fri, 23 Jan 2015 08:45:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 lbjVc6wgeLCc for ; Fri, 23 Jan 2015 08:45:16 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738C41A1AD8 for ; Fri, 23 Jan 2015 08:45:16 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 584EB880E2; Fri, 23 Jan 2015 08:45:16 -0800 (PST)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DA85371C0002; Fri, 23 Jan 2015 08:45:15 -0800 (PST)
Message-ID: <54C27A93.4010504@innovationslab.net>
Date: Fri, 23 Jan 2015 11:45:07 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: draft-ietf-netext-ani-location@tools.ietf.org,  "netext-chairs@tools.ietf.org" , "netext@ietf.org" 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5uvqTQ7ieDJoVkS6USHpRtLJcEDhRRan5"
Archived-At: 
Subject: [netext] AD Evaluation: draft-ietf-netext-ani-location
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. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 16:45:18 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5uvqTQ7ieDJoVkS6USHpRtLJcEDhRRan5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

All,
     I have performed the usual AD Evaluation of
draft-ietf-netext-ani-location as a part of the RFC publication process.
 I only have a few comments/questions on this draft that I would like to
see resolved prior to starting IETF Last Call:

1. I would think that this document should be marked as "Updates RFC
6757".  Thoughts on this?

2. In Section 3.1, the civic location field is limited to 253 bytes.
Given that there are civic locations that exceed that length, can you
provide a brief justification for that limit?

3. The two sub-sections of Section 4 use 2119 keywords when describing
implementation details that really do not impact interoperability.
Unless you want to get into interesting procedural discussions with some
ADs, I would suggest modifying the text to not use 2119 keywords.

Regards,
Brian


--5uvqTQ7ieDJoVkS6USHpRtLJcEDhRRan5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUwnqZAAoJEBOZRqCi7goqkYkH/3+QvCiJyFTfF1xZH40bjOAW
IPedrKYjrTKv3eQ/5znD5g5YX/FBsPca2pyQtJOrNmU1HTl3/7yw1nEKeK2k+bei
RE5S8LCWZdIEyQdcqUmNLw4MS+HEOG0NsYyj+wBsW1UjtEUcUcZeiKE8dE6m4kPR
dvYxC5KhHTNDN1J+7c2RH8+wDHbBBsRjiH2OiVkfRStqseHHUeyvfJrix8TgqIIO
R/6K/bzlvIZNc7l8QYXAYhhew6GC/4xy45cKrlh9/IajzwlTrfk2yCKciLFMHToM
a6knYwLT2JPyw/LmzEpCOWNQ0yQeaXD+v2XpUie9KDE7YzlmKU39wExXNBLFRgs=
=1NLn
-----END PGP SIGNATURE-----

--5uvqTQ7ieDJoVkS6USHpRtLJcEDhRRan5--


From nobody Fri Jan 23 14:47:19 2015
Return-Path: 
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 EE56E1AD09D for ; Fri, 23 Jan 2015 14:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 3BC58OBmEKua for ; Fri, 23 Jan 2015 14:47:17 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A992E1AD0A1 for ; Fri, 23 Jan 2015 14:47:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1547; q=dns/txt; s=iport; t=1422053237; x=1423262837; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5gWK27x3Ulmo0o91tnRYZwTIjU4P+RZhAyuhpzHONhI=; b=CLVP/rL9VBg7GB4a3K5RhpB5AthtjXuU5jr/SOSQE+YtBf6n3iT6Megk BevGSh9dc1sMfwNnBdpyTNz8dZBmvz0LZ1j7+J5zO1tgnF7zL1jG1f8yw OuGsMylPO5rnYhZKNRbV1irNgnaVcqojmCnKcKpiDG6vQyxsuWwDp9ez2 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AloFAAvOwlStJV2U/2dsb2JhbABagwaBL8QliBYCgRVDAQEBAQF9hA0BAQQ6TwIBCDYQMiUCBAESiCzSYQEBAQEBAQEDAQEBAQEBHI8gAV6EKQEEjmyJIZI8IoF/H4FQb4ECAR8ifgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,456,1418083200"; d="scan'208";a="117099850"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 23 Jan 2015 22:47:16 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t0NMlF4V027843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 22:47:16 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.25]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 16:47:15 -0600
From: "Rajesh Pazhyannur (rpazhyan)" 
To: Brian Haberman , "draft-ietf-netext-ani-location@tools.ietf.org" , "netext-chairs@tools.ietf.org" , "netext@ietf.org" 
Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-ani-location
Thread-Index: AQHQNyv6+F6qqgRGTkuWjiIArO6N75zOLTMA
Date: Fri, 23 Jan 2015 22:47:15 +0000
Message-ID: 
References: <54C27A93.4010504@innovationslab.net>
In-Reply-To: <54C27A93.4010504@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.6.141106
x-originating-ip: [10.24.148.60]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7799F16CA54C8D4CA0D0196A82FBC6D1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netext] AD Evaluation: draft-ietf-netext-ani-location
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. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 22:47:18 -0000

Hello Brian

Thanks for the evaluation.
Comments embedded.=20

Thanks

Rajesh

On 1/23/15, 8:45 AM, "Brian Haberman"  wrote:

>All,
>     I have performed the usual AD Evaluation of
>draft-ietf-netext-ani-location as a part of the RFC publication process.
> I only have a few comments/questions on this draft that I would like to
>see resolved prior to starting IETF Last Call:
>
>1. I would think that this document should be marked as "Updates RFC
>6757".  Thoughts on this?


This is not making any changes to RFC6757 and so this not updating RFC6757.



>
>2. In Section 3.1, the civic location field is limited to 253 bytes.
>Given that there are civic locations that exceed that length, can you
>provide a brief justification for that limit?

This is a good question. The practical reason for 253 bytes is that the
ANI length field is one byte.
However, the DHCPv4 Civic Location also has a one byte length, so we felt
it was reasonable.=20
For longer length, a PIDF location URI could be used (a URI that would
dereference to a location object).
Potentially, we can add text around how the 253 byte limit could be
handled for long civic locations.
 =20
>
>3. The two sub-sections of Section 4 use 2119 keywords when describing
>implementation details that really do not impact interoperability.
>Unless you want to get into interesting procedural discussions with some
>ADs, I would suggest modifying the text to not use 2119 keywords.

Ok.

>
>Regards,
>Brian
>


From nobody Fri Jan 23 14:54:25 2015
Return-Path: 
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 DCCFF1A8AEA for ; Fri, 23 Jan 2015 14:54:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 HizHYjwm0gJQ for ; Fri, 23 Jan 2015 14:54:22 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808701A00A8 for ; Fri, 23 Jan 2015 14:54:22 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 53F7B88135; Fri, 23 Jan 2015 14:54:22 -0800 (PST)
Received: from clemson.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id C1B7D71C0002; Fri, 23 Jan 2015 14:54:21 -0800 (PST)
Message-ID: <54C2D11D.8090205@innovationslab.net>
Date: Fri, 23 Jan 2015 17:54:21 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "Rajesh Pazhyannur (rpazhyan)" ,  "draft-ietf-netext-ani-location@tools.ietf.org" ,  "netext-chairs@tools.ietf.org" ,  "netext@ietf.org" 
References: <54C27A93.4010504@innovationslab.net> 
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ChwBCDfjaAXed9sXLF2IHG0HQc7EKfFq5"
Archived-At: 
Subject: Re: [netext] AD Evaluation: draft-ietf-netext-ani-location
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. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 22:54:24 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ChwBCDfjaAXed9sXLF2IHG0HQc7EKfFq5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Rajesh,

On 1/23/15 5:47 PM, Rajesh Pazhyannur (rpazhyan) wrote:
> Hello Brian
>=20
> Thanks for the evaluation.
> Comments embedded.=20
>=20
> Thanks
>=20
> Rajesh
>=20
> On 1/23/15, 8:45 AM, "Brian Haberman"  wrote:=

>=20
>> All,
>>     I have performed the usual AD Evaluation of
>> draft-ietf-netext-ani-location as a part of the RFC publication proces=
s.
>> I only have a few comments/questions on this draft that I would like t=
o
>> see resolved prior to starting IETF Last Call:
>>
>> 1. I would think that this document should be marked as "Updates RFC
>> 6757".  Thoughts on this?
>=20
>=20
> This is not making any changes to RFC6757 and so this not updating RFC6=
757.
>=20

An Updates tag is not reserved only for changing an RFC.  Do you want
new implementers of 6757 to also implement this spec at the same time?

>=20
>=20
>>
>> 2. In Section 3.1, the civic location field is limited to 253 bytes.
>> Given that there are civic locations that exceed that length, can you
>> provide a brief justification for that limit?
>=20
> This is a good question. The practical reason for 253 bytes is that the=

> ANI length field is one byte.
> However, the DHCPv4 Civic Location also has a one byte length, so we fe=
lt
> it was reasonable.=20
> For longer length, a PIDF location URI could be used (a URI that would
> dereference to a location object).
> Potentially, we can add text around how the 253 byte limit could be
> handled for long civic locations.
>  =20

I think some text describing how to handle locations that won't fit in
the field would be good.

>>
>> 3. The two sub-sections of Section 4 use 2119 keywords when describing=

>> implementation details that really do not impact interoperability.
>> Unless you want to get into interesting procedural discussions with so=
me
>> ADs, I would suggest modifying the text to not use 2119 keywords.
>=20
> Ok.
>=20

Cool.

Regards,
Brian



--ChwBCDfjaAXed9sXLF2IHG0HQc7EKfFq5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJUwtEdAAoJEBOZRqCi7goq9lQIAJoTl7XLFrtsIRyhqI/6xw4I
oaG9D1KipCocYSRuHJM/StjYzidpZyCgbW0gXjvCIb04AV1nj+rn89ZZIzEi23R2
rSd138K3voI7hhyLrBTzsXb++nT5RUje1vhudk6F2G5dzPwbeYDSUlTTfeDoCrGS
P9Cz0BNaZivF+ZsgQo4H2u6WxV7E0OAiK6Pp2KB8e9ndqvH+zsdjmazd9d8CGStM
aJvCCpvOPrtynRHciISSvqNUHqhE025he0NpnyJO2nGH8ZhTOlNUiTEA+c61d9dR
d2VQN/WxVLk3h3SVeQhyGkaKBqY8TYjKxyHLp+5d/f9l6KI2S9Pr/fxBv9IdWyk=
=6B+f
-----END PGP SIGNATURE-----

--ChwBCDfjaAXed9sXLF2IHG0HQc7EKfFq5--


From nobody Fri Jan 23 15:01:07 2015
Return-Path: 
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 A1F511A8823 for ; Fri, 23 Jan 2015 15:01:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Dx4fPPWsEJNQ for ; Fri, 23 Jan 2015 15:01:02 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9DC1A87E4 for ; Fri, 23 Jan 2015 15:01:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2332; q=dns/txt; s=iport; t=1422054062; x=1423263662; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=aewXgybV0mOXCi1HZEEzh2kUZHltpc7hOAJw+eU+IIw=; b=IVTKC4iCyAxUA2wRaLVDvUh3RU4vJmLwv+RjbSgwB1ySWZUwVLIskOAN h6UqF5D4i98TYOLmk2ZYBPbDC3ZJi1KaGO3VAM3bJJmqiipLI/yBQUpmk Jzk6YwzaeNRbkKx2hzKRhJXoEa+K/ecvKjpUI0K7NPICTOC9Y25o6ge2n k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AloFAFPRwlStJA2N/2dsb2JhbABagwaBL8QliBYCgRVDAQEBAQF9hA0BAQQ6UQEIGB5CJQIEARKILNJnAQEBAQEBBAEBAQEBHY8gAV6EKQWObIkhgRWKdIYzIoF/H4FQb4ECAR8ifgEBAQ
X-IronPort-AV: E=Sophos;i="5.09,456,1418083200"; d="scan'208";a="390390515"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jan 2015 23:01:01 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t0NN11qb028293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 23 Jan 2015 23:01:01 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.150]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 17:01:00 -0600
From: "Sri Gundavelli (sgundave)" 
To: Brian Haberman , "Rajesh Pazhyannur (rpazhyan)" , "draft-ietf-netext-ani-location@tools.ietf.org" , "netext-chairs@tools.ietf.org" , "netext@ietf.org" 
Thread-Topic: [netext] AD Evaluation: draft-ietf-netext-ani-location
Thread-Index: AQHQN2B0+F6qqgRGTkuWjiIArO6N7w==
Date: Fri, 23 Jan 2015 23:01:05 +0000
Message-ID: 
In-Reply-To: <54C2D11D.8090205@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.216]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4BB600FD3AA9A049A9FE01BB9C163744@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netext] AD Evaluation: draft-ietf-netext-ani-location
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. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Jan 2015 23:01:04 -0000

Hi Brian,



On 1/23/15 2:54 PM, "Brian Haberman"  wrote:

>Hi Rajesh,
>
>On 1/23/15 5:47 PM, Rajesh Pazhyannur (rpazhyan) wrote:
>> Hello Brian
>>=20
>> Thanks for the evaluation.
>> Comments embedded.
>>=20
>> Thanks
>>=20
>> Rajesh
>>=20
>> On 1/23/15, 8:45 AM, "Brian Haberman"  wrote:
>>=20
>>> All,
>>>     I have performed the usual AD Evaluation of
>>> draft-ietf-netext-ani-location as a part of the RFC publication
>>>process.
>>> I only have a few comments/questions on this draft that I would like to
>>> see resolved prior to starting IETF Last Call:
>>>
>>> 1. I would think that this document should be marked as "Updates RFC
>>> 6757".  Thoughts on this?
>>=20
>>=20
>> This is not making any changes to RFC6757 and so this not updating
>>RFC6757.
>>=20
>
>An Updates tag is not reserved only for changing an RFC.  Do you want
>new implementers of 6757 to also implement this spec at the same time?


OK. Make sense to keep the ANI option as a single extension.
We though we were not making changes to the spec and so we did not use the
Update tag.



Regards
Sri


>
>>=20
>>=20
>>>
>>> 2. In Section 3.1, the civic location field is limited to 253 bytes.
>>> Given that there are civic locations that exceed that length, can you
>>> provide a brief justification for that limit?
>>=20
>> This is a good question. The practical reason for 253 bytes is that the
>> ANI length field is one byte.
>> However, the DHCPv4 Civic Location also has a one byte length, so we
>>felt
>> it was reasonable.
>> For longer length, a PIDF location URI could be used (a URI that would
>> dereference to a location object).
>> Potentially, we can add text around how the 253 byte limit could be
>> handled for long civic locations.
>>  =20
>
>I think some text describing how to handle locations that won't fit in
>the field would be good.
>
>>>
>>> 3. The two sub-sections of Section 4 use 2119 keywords when describing
>>> implementation details that really do not impact interoperability.
>>> Unless you want to get into interesting procedural discussions with
>>>some
>>> ADs, I would suggest modifying the text to not use 2119 keywords.
>>=20
>> Ok.
>>=20
>
>Cool.
>
>Regards,
>Brian
>
>


From nobody Tue Jan 27 13:36:01 2015
Return-Path: 
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 C4EBC1A8F38; Tue, 27 Jan 2015 13:35:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 6oGLEn3fNGW4; Tue, 27 Jan 2015 13:35:48 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E171A8F3E; Tue, 27 Jan 2015 13:35:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150127213548.10839.92808.idtracker@ietfa.amsl.com>
Date: Tue, 27 Jan 2015 13:35:48 -0800
Archived-At: 
Cc: netext@ietf.org
Subject: [netext] I-D Action: draft-ietf-netext-ani-location-07.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 21:35:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.

        Title           : Extensions to the PMIPv6 Access Network Identifier Option
        Authors         : Rajesh S. Pazhyannur
                          Sebastian Speicher
                          Sri Gundavelli
                          Jouni Korhonen
                          John Kaippallimalil
	Filename        : draft-ietf-netext-ani-location-07.txt
	Pages           : 12
	Date            : 2015-01-27

Abstract:
   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.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netext-ani-location-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Jan 27 13:36:04 2015
Return-Path: 
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 B6FD21A8F3E for ; Tue, 27 Jan 2015 13:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 xzekeHiNYPfn; Tue, 27 Jan 2015 13:35:51 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA9F1A8F40; Tue, 27 Jan 2015 13:35:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: netext@ietf.org, draft-ietf-netext-ani-location.all@tools.ietf.org, netext-chairs@tools.ietf.org, bpatil1+ietf@gmail.com, brian@innovationslab.net
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150127213548.10839.54300.idtracker@ietfa.amsl.com>
Date: Tue, 27 Jan 2015 13:35:48 -0800
Archived-At: 
Subject: [netext] New Version Notification - draft-ietf-netext-ani-location-07.txt
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 21:36:00 -0000

A new version (-07) has been submitted for draft-ietf-netext-ani-location:
http://www.ietf.org/internet-drafts/draft-ietf-netext-ani-location-07.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Tue Jan 27 14:38:27 2015
Return-Path: 
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 65EDE1A909D; Tue, 27 Jan 2015 14:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
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 hRBfdgJygj0l; Tue, 27 Jan 2015 14:38:22 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B69D41A9083; Tue, 27 Jan 2015 14:38:22 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20150127223822.4617.44583.idtracker@ietfa.amsl.com>
Date: Tue, 27 Jan 2015 14:38:22 -0800
Archived-At: 
Cc: netext@ietf.org
Subject: [netext] Last Call:  (Extensions to the PMIPv6 Access Network Identifier Option) to Proposed Standard
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 22:38:24 -0000

The IESG has received a request from the Network-Based Mobility
Extensions WG (netext) to consider the following document:
- 'Extensions to the PMIPv6 Access Network Identifier Option'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-02-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ballot/


No IPR declarations have been submitted directly on this I-D.