From nobody Wed Mar 4 12: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 55B451ACEDF; Wed, 4 Mar 2015 12:54:24 -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 hWx8G2wL1J-8; Wed, 4 Mar 2015 12:54:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2F21ACEE6; Wed, 4 Mar 2015 12:54:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304205414.15762.75509.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 12:54:14 -0800 Archived-At: Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-qos-wifi-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: Wed, 04 Mar 2015 20:54:24 -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 : Mapping PMIPv6 QoS Procedures with WLAN QoS Procedures Authors : John Kaippallimalil Rajesh Pazhyannur Parviz Yegani Filename : draft-ietf-netext-pmip-qos-wifi-07.txt Pages : 23 Date : 2015-03-04 Abstract: This document provides guidelines for achieving end to end Quality- of-Service (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobility Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11, Wi-Fi Multimedia - Admission Control (WMM-AC) describes methods for QoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters. This document is intended to be used as a companion document to RFC 7222 to enable implementation of end to end QoS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-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 Wed Mar 4 12:54:37 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 4B3941ACEE4; Wed, 4 Mar 2015 12:54:25 -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 Jas8t_19SzIy; Wed, 4 Mar 2015 12:54:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5B41ACEE8; Wed, 4 Mar 2015 12:54:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304205414.15762.85572.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 12:54:14 -0800 Archived-At: Subject: [netext] New Version Notification - draft-ietf-netext-pmip-qos-wifi-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: Wed, 04 Mar 2015 20:54:25 -0000 A new version (-07) has been submitted for draft-ietf-netext-pmip-qos-wifi: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-qos-wifi-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-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 Wed Mar 4 12:54:38 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-pmip-qos-wifi.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 66A741ACEE7; Wed, 4 Mar 2015 12:54:25 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-pmip-qos-wifi.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-pmip-qos-wifi.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3941ACEE4; Wed, 4 Mar 2015 12:54:25 -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 Jas8t_19SzIy; Wed, 4 Mar 2015 12:54:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5B41ACEE8; Wed, 4 Mar 2015 12:54:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304205414.15762.85572.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 12:54:14 -0800 Archived-At: Subject: [netext] New Version Notification - draft-ietf-netext-pmip-qos-wifi-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: Wed, 04 Mar 2015 20:54:25 -0000 A new version (-07) has been submitted for draft-ietf-netext-pmip-qos-wifi: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-qos-wifi-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-qos-wifi-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 Wed Mar 4 18:32:28 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 34BE31AD0F0; Wed, 4 Mar 2015 18:32: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 fKFOlWKsuF9g; Wed, 4 Mar 2015 18:32:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD21AD0CF; Wed, 4 Mar 2015 18:32:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 18:32:25 -0800 Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 05 Mar 2015 02:32:27 -0000 Richard Barnes has entered the following ballot position for draft-ietf-netext-ani-location-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. From nobody Wed Mar 4 18:32:30 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5773D1AD151; Wed, 4 Mar 2015 18:32:27 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BE31AD0F0; Wed, 4 Mar 2015 18:32: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 fKFOlWKsuF9g; Wed, 4 Mar 2015 18:32:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD21AD0CF; Wed, 4 Mar 2015 18:32:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 18:32:25 -0800 Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 05 Mar 2015 02:32:27 -0000 Richard Barnes has entered the following ballot position for draft-ietf-netext-ani-location-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. From nobody Wed Mar 4 19:14:41 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 A450C1A8A9C; Wed, 4 Mar 2015 19:14:38 -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 5ON40effjBls; Wed, 4 Mar 2015 19:14:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCFF1A1BCD; Wed, 4 Mar 2015 19:14:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305031437.7587.71906.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 19:14:37 -0800 Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS and COMMENT) 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: Thu, 05 Mar 2015 03:14:38 -0000 Richard Barnes has entered the following ballot position for draft-ietf-netext-ani-location-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. (5) Did the WG consider constraining the set of civic address elements that can be used? It's not clear to me that the use cases for this document require very granular information, e.g., to the individual building, floor, or room. The RFC 4776 format makes it fairly easy to express these constraints, by saying something like "The civic addresses carried in the civic location sub option MUST NOT contain elements other than A1, ..., A6 and PC." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another way to address the concerns here is to provision location information at the least granular level possible. Suggested: "The other way to protect the sensitive location information of network users is of course to not send it in the first places. Users of the civic location sub option should provision location values with the highest possible level of granularity, e.g., to the province or city level, rather than provisioning specific addresses. In addition to helping protect private information, reducing granularity will also reduce the size of the civic location sub option." From nobody Wed Mar 4 19:14:42 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C94AD1A8AA8; Wed, 4 Mar 2015 19:14:38 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A450C1A8A9C; Wed, 4 Mar 2015 19:14:38 -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 5ON40effjBls; Wed, 4 Mar 2015 19:14:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCFF1A1BCD; Wed, 4 Mar 2015 19:14:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Richard Barnes" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305031437.7587.71906.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 19:14:37 -0800 Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS and COMMENT) 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: Thu, 05 Mar 2015 03:14:39 -0000 Richard Barnes has entered the following ballot position for draft-ietf-netext-ani-location-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) In Section 3.1, the "civic location" description here mentions the use of a location URI, but there's no corresponding Format for it. Is that what you actually mean to have for XML Encoding (1)? You're not going to fit much XML in 253 octets anyway. I would suggest having format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML document. (2) It would help interoperability if you could constrain the classes of location URI that are supported. For example, if the mechanism in RFC 6753 is sufficient for your purposes, you could require that geolocation values in format 1 use an HTTPS URI to be dereferenced using that mechanism. Likewise, unless there's a known, compelling need to support HTTP URIs, you should require HTTPS. The fact that you have 253 format codes remaining means that if there are future needs for other URI types, you can liberalize. (3) To ensure that the location information referenced by location URIs is protected, please comment on the assumed access control model for these URIs. Can anyone with the URI dereference it? Or are they required to be access-controlled? Section 4 of RFC 6753 should provide a helpful framework. (4) Alternatively to (2) and (3), you could just remove the option for a XML/URI-based location altogether. Is there a compelling use cases here for very precise location? Even with the 253-octet limit, the RFC 4776 format would allow you to specify down to roughly the neighborhood level in most cases. For example, encoding "Washington, DC 20001, US" takes only 26 octets. Even looking at some Japanese addresses, which are more verbose, the examples I'm finding are still on the order of 70-100 octets. (5) Did the WG consider constraining the set of civic address elements that can be used? It's not clear to me that the use cases for this document require very granular information, e.g., to the individual building, floor, or room. The RFC 4776 format makes it fairly easy to express these constraints, by saying something like "The civic addresses carried in the civic location sub option MUST NOT contain elements other than A1, ..., A6 and PC." ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a good discussion of confidentiality protections in the Security Considerations. It would be helpful if you could also note that another way to address the concerns here is to provision location information at the least granular level possible. Suggested: "The other way to protect the sensitive location information of network users is of course to not send it in the first places. Users of the civic location sub option should provision location values with the highest possible level of granularity, e.g., to the province or city level, rather than provisioning specific addresses. In addition to helping protect private information, reducing granularity will also reduce the size of the civic location sub option." From nobody Thu Mar 5 07:14:44 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 A36F81A0BE8; Thu, 5 Mar 2015 07:14:42 -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 wyTICyIeJ_2j; Thu, 5 Mar 2015 07:14:39 -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 CB6F31A0389; Thu, 5 Mar 2015 07:13: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 A18FD88154; Thu, 5 Mar 2015 07:13:16 -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 CFE181368260; Thu, 5 Mar 2015 07:13:15 -0800 (PST) Message-ID: <54F87285.8070703@innovationslab.net> Date: Thu, 05 Mar 2015 10:13:09 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes , The IESG References: <20150305031437.7587.71906.idtracker@ietfa.amsl.com> In-Reply-To: <20150305031437.7587.71906.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc" Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS and COMMENT) 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: Thu, 05 Mar 2015 15:14:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Richard, On 3/4/15 10:14 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-netext-ani-location-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > (1) In Section 3.1, the "civic location" description here mentions the > use of a location URI, but there's no corresponding Format for it. Is > that what you actually mean to have for XML Encoding (1)? You're not > going to fit much XML in 253 octets anyway. I would suggest having > format 0 be the RFC 4776 format, and format 1 be a URI pointing to an X= ML > document. Just on the above point... I had a comment during my AD Evaluation on 3.1 and got this response: >> >> 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. > 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. So, I do not envision 253 bytes of XML. However, your point about clarifying the format is a good one. The rest of your points I will leave to the authors. Regards, Brian >=20 > (2) It would help interoperability if you could constrain the classes o= f > location URI that are supported. For example, if the mechanism in RFC > 6753 is sufficient for your purposes, you could require that geolocatio= n > values in format 1 use an HTTPS URI to be dereferenced using that > mechanism. Likewise, unless there's a known, compelling need to suppor= t > HTTP URIs, you should require HTTPS. The fact that you have 253 format= > codes remaining means that if there are future needs for other URI type= s, > you can liberalize. >=20 > (3) To ensure that the location information referenced by location URIs= > is protected, please comment on the assumed access control model for > these URIs. Can anyone with the URI dereference it? Or are they > required to be access-controlled? Section 4 of RFC 6753 should provide= a > helpful framework.=20 >=20 > (4) Alternatively to (2) and (3), you could just remove the option for = a > XML/URI-based location altogether. Is there a compelling use cases her= e > for very precise location? Even with the 253-octet limit, the RFC 4776= > format would allow you to specify down to roughly the neighborhood leve= l > in most cases. For example, encoding "Washington, DC 20001, US" takes > only 26 octets. Even looking at some Japanese addresses, which are mor= e > verbose, the examples I'm finding are still on the order of 70-100 > octets. >=20 > (5) Did the WG consider constraining the set of civic address elements > that can be used? It's not clear to me that the use cases for this > document require very granular information, e.g., to the individual > building, floor, or room. The RFC 4776 format makes it fairly easy to > express these constraints, by saying something like "The civic addresse= s > carried in the civic location sub option MUST NOT contain elements othe= r > than A1, ..., A6 and PC." >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for a good discussion of confidentiality protections in the > Security Considerations. It would be helpful if you could also note th= at > another way to address the concerns here is to provision location > information at the least granular level possible. Suggested: >=20 > "The other way to protect the sensitive location information of network= > users is of course to not send it in the first places. Users of the > civic location sub option should provision location values with the > highest possible level of granularity, e.g., to the province or city > level, rather than provisioning specific addresses. In addition to > helping protect private information, reducing granularity will also > reduce the size of the civic location sub option." >=20 >=20 >=20 >=20 --7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc 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 iQEcBAEBCgAGBQJU+HKKAAoJEBOZRqCi7goqq0oH/iZdLcKEGOTSYpcZW1Xj273g RMatcPfx0/Bevz0almIAynT7C28+k60x8n4tALKW5bYB3OsroFBlKIpXh5RwncMi 2r4goD2EM1woGVUC1uV3W0KQ2T/LYiU3Is3Q4Axo9ZfxvfmLfUGCOR1TDwii8LNH g106qtvkhzfWYMqowi1Gvl797ymoFHuqgD8EwHoHdiC9KAMMUnS2cmQ7qxsU8wjW IdIpHstodACFJiUvXcclJb9XKn8XDs5bVfXWWKrPF92EySE/4CcGB+YEPz7635Vd WFEIedsX9xUiX6rv45Ks+JfGGOpwmUeJSsI/kq2y2fpE7gahHbTJ2YlE4U5Zdxc= =ibZ1 -----END PGP SIGNATURE----- --7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc-- From nobody Thu Mar 5 07:14:50 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CF16D1A19E4; Thu, 5 Mar 2015 07:14:42 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36F81A0BE8; Thu, 5 Mar 2015 07:14:42 -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 wyTICyIeJ_2j; Thu, 5 Mar 2015 07:14:39 -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 CB6F31A0389; Thu, 5 Mar 2015 07:13: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 A18FD88154; Thu, 5 Mar 2015 07:13:16 -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 CFE181368260; Thu, 5 Mar 2015 07:13:15 -0800 (PST) Message-ID: <54F87285.8070703@innovationslab.net> Date: Thu, 05 Mar 2015 10:13:09 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes , The IESG References: <20150305031437.7587.71906.idtracker@ietfa.amsl.com> In-Reply-To: <20150305031437.7587.71906.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc" Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS and COMMENT) 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: Thu, 05 Mar 2015 15:14:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Richard, On 3/4/15 10:14 PM, Richard Barnes wrote: > Richard Barnes has entered the following ballot position for > draft-ietf-netext-ani-location-08: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > (1) In Section 3.1, the "civic location" description here mentions the > use of a location URI, but there's no corresponding Format for it. Is > that what you actually mean to have for XML Encoding (1)? You're not > going to fit much XML in 253 octets anyway. I would suggest having > format 0 be the RFC 4776 format, and format 1 be a URI pointing to an X= ML > document. Just on the above point... I had a comment during my AD Evaluation on 3.1 and got this response: >> >> 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. > 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. So, I do not envision 253 bytes of XML. However, your point about clarifying the format is a good one. The rest of your points I will leave to the authors. Regards, Brian >=20 > (2) It would help interoperability if you could constrain the classes o= f > location URI that are supported. For example, if the mechanism in RFC > 6753 is sufficient for your purposes, you could require that geolocatio= n > values in format 1 use an HTTPS URI to be dereferenced using that > mechanism. Likewise, unless there's a known, compelling need to suppor= t > HTTP URIs, you should require HTTPS. The fact that you have 253 format= > codes remaining means that if there are future needs for other URI type= s, > you can liberalize. >=20 > (3) To ensure that the location information referenced by location URIs= > is protected, please comment on the assumed access control model for > these URIs. Can anyone with the URI dereference it? Or are they > required to be access-controlled? Section 4 of RFC 6753 should provide= a > helpful framework.=20 >=20 > (4) Alternatively to (2) and (3), you could just remove the option for = a > XML/URI-based location altogether. Is there a compelling use cases her= e > for very precise location? Even with the 253-octet limit, the RFC 4776= > format would allow you to specify down to roughly the neighborhood leve= l > in most cases. For example, encoding "Washington, DC 20001, US" takes > only 26 octets. Even looking at some Japanese addresses, which are mor= e > verbose, the examples I'm finding are still on the order of 70-100 > octets. >=20 > (5) Did the WG consider constraining the set of civic address elements > that can be used? It's not clear to me that the use cases for this > document require very granular information, e.g., to the individual > building, floor, or room. The RFC 4776 format makes it fairly easy to > express these constraints, by saying something like "The civic addresse= s > carried in the civic location sub option MUST NOT contain elements othe= r > than A1, ..., A6 and PC." >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for a good discussion of confidentiality protections in the > Security Considerations. It would be helpful if you could also note th= at > another way to address the concerns here is to provision location > information at the least granular level possible. Suggested: >=20 > "The other way to protect the sensitive location information of network= > users is of course to not send it in the first places. Users of the > civic location sub option should provision location values with the > highest possible level of granularity, e.g., to the province or city > level, rather than provisioning specific addresses. In addition to > helping protect private information, reducing granularity will also > reduce the size of the civic location sub option." >=20 >=20 >=20 >=20 --7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc 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 iQEcBAEBCgAGBQJU+HKKAAoJEBOZRqCi7goqq0oH/iZdLcKEGOTSYpcZW1Xj273g RMatcPfx0/Bevz0almIAynT7C28+k60x8n4tALKW5bYB3OsroFBlKIpXh5RwncMi 2r4goD2EM1woGVUC1uV3W0KQ2T/LYiU3Is3Q4Axo9ZfxvfmLfUGCOR1TDwii8LNH g106qtvkhzfWYMqowi1Gvl797ymoFHuqgD8EwHoHdiC9KAMMUnS2cmQ7qxsU8wjW IdIpHstodACFJiUvXcclJb9XKn8XDs5bVfXWWKrPF92EySE/4CcGB+YEPz7635Vd WFEIedsX9xUiX6rv45Ks+JfGGOpwmUeJSsI/kq2y2fpE7gahHbTJ2YlE4U5Zdxc= =ibZ1 -----END PGP SIGNATURE----- --7Rivr6o4OF57DJaa6fqj7I1fklvI0gJJc-- From nobody Thu Mar 5 07:48:44 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 2A6181A1B24; Thu, 5 Mar 2015 07:48:40 -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 xKweeW3mEeWc; Thu, 5 Mar 2015 07:48:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AEF1A1A4D; Thu, 5 Mar 2015 07:46:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:46:30 -0800 Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: [netext] Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) 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: Thu, 05 Mar 2015 15:48:40 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netext-ani-location-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - What if the network being identified here was a tethering n/w or any other kind of n/w that's carried about by a person? In that case ANI, and these new options, would be privacy invasive. Does that statement exist in one of the RFCs referred to in section 6? If not, would it be worth adding here, even though it might better belong elsewhere? - intro: What if a WLAN operator has no realm? - intro: DPI? What's that got to do with it? I'd suggest removing that. From nobody Thu Mar 5 07:48:45 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4BB611A1B27; Thu, 5 Mar 2015 07:48:40 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6181A1B24; Thu, 5 Mar 2015 07:48:40 -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 xKweeW3mEeWc; Thu, 5 Mar 2015 07:48:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AEF1A1A4D; Thu, 5 Mar 2015 07:46:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 07:46:30 -0800 Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: [netext] Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) 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: Thu, 05 Mar 2015 15:48:40 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netext-ani-location-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - What if the network being identified here was a tethering n/w or any other kind of n/w that's carried about by a person? In that case ANI, and these new options, would be privacy invasive. Does that statement exist in one of the RFCs referred to in section 6? If not, would it be worth adding here, even though it might better belong elsewhere? - intro: What if a WLAN operator has no realm? - intro: DPI? What's that got to do with it? I'd suggest removing that. From nobody Thu Mar 5 08:04:21 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 B5D2B1A1A4E; Thu, 5 Mar 2015 08:04:12 -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 1z8qX9CnBboI; Thu, 5 Mar 2015 08:04:07 -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 A58461A1A11; Thu, 5 Mar 2015 08:03:51 -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 7DDDE880CE; Thu, 5 Mar 2015 08:03:51 -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 BBE34136825A; Thu, 5 Mar 2015 08:03:50 -0800 (PST) Message-ID: <54F87E5F.7080107@innovationslab.net> Date: Thu, 05 Mar 2015 11:03:43 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> In-Reply-To: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq" Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: Re: [netext] Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) 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: Thu, 05 Mar 2015 16:04:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Stephen, On 3/5/15 10:46 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-netext-ani-location-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 >=20 > - What if the network being identified here was a tethering > n/w or any other kind of n/w that's carried about by a person? That isn't applicable as far as I know. The location option is used between the two infrastructure devices (LMA and MAG) providing the proxy mobility service. The actual user's location is not being carried and the MAG is not a mobile platform. Regards, Brian --Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq 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 iQEcBAEBCgAGBQJU+H5lAAoJEBOZRqCi7goqiskH/jIJkOYQVOmedG1DHlEs4ydS YGdlmCrbwpvKH9tB9zPzOAT8HXTWnzIaI5SWjYOVVfsRxLJ1U2kvYJxSNXQ59jIR RyZIdYh53sIWi/2F4DPhBf9NUth3ucxKasPlN2lDRIDAPTv81nxUjlEu8LKGgsQS u78tlsdwcHyxJrQ/m2rhhRGWI0odqjbi9uQkTuuxu+LgGpVdqml5A0aZ3ziRDz3r iXFvHDPaZhDkLBmn2G3P86/tyC5PQrutczO50ESAR0QboeqFRcZAem0UB92DTTz2 tME+orXm5zcibI0Z2AQLNweGx45cYJ9P2EBnHQJuHTT5EXBakScBWo3OzmwdGzE= =mA4x -----END PGP SIGNATURE----- --Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq-- From nobody Thu Mar 5 08:04:22 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D7B061A1A6F; Thu, 5 Mar 2015 08:04:12 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2B1A1A4E; Thu, 5 Mar 2015 08:04:12 -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 1z8qX9CnBboI; Thu, 5 Mar 2015 08:04:07 -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 A58461A1A11; Thu, 5 Mar 2015 08:03:51 -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 7DDDE880CE; Thu, 5 Mar 2015 08:03:51 -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 BBE34136825A; Thu, 5 Mar 2015 08:03:50 -0800 (PST) Message-ID: <54F87E5F.7080107@innovationslab.net> Date: Thu, 05 Mar 2015 11:03:43 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> In-Reply-To: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq" Archived-At: Cc: netext@ietf.org, netext-chairs@ietf.org, draft-ietf-netext-ani-location.all@ietf.org Subject: Re: [netext] Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) 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: Thu, 05 Mar 2015 16:04:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya Stephen, On 3/5/15 10:46 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-netext-ani-location-08: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this= > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.htm= l > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 >=20 > - What if the network being identified here was a tethering > n/w or any other kind of n/w that's carried about by a person? That isn't applicable as far as I know. The location option is used between the two infrastructure devices (LMA and MAG) providing the proxy mobility service. The actual user's location is not being carried and the MAG is not a mobile platform. Regards, Brian --Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq 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 iQEcBAEBCgAGBQJU+H5lAAoJEBOZRqCi7goqiskH/jIJkOYQVOmedG1DHlEs4ydS YGdlmCrbwpvKH9tB9zPzOAT8HXTWnzIaI5SWjYOVVfsRxLJ1U2kvYJxSNXQ59jIR RyZIdYh53sIWi/2F4DPhBf9NUth3ucxKasPlN2lDRIDAPTv81nxUjlEu8LKGgsQS u78tlsdwcHyxJrQ/m2rhhRGWI0odqjbi9uQkTuuxu+LgGpVdqml5A0aZ3ziRDz3r iXFvHDPaZhDkLBmn2G3P86/tyC5PQrutczO50ESAR0QboeqFRcZAem0UB92DTTz2 tME+orXm5zcibI0Z2AQLNweGx45cYJ9P2EBnHQJuHTT5EXBakScBWo3OzmwdGzE= =mA4x -----END PGP SIGNATURE----- --Iq0Tsm19ICF5SIiGrc5NFLI69IdxoB1cq-- From nobody Thu Mar 5 11:20:23 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 742A51A8741; Thu, 5 Mar 2015 11:20:21 -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 wE5_OEKjttxC; Thu, 5 Mar 2015 11:20:19 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E411A873E; Thu, 5 Mar 2015 11:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1924; q=dns/txt; s=iport; t=1425583219; x=1426792819; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=r4Lu5z7YwetZvFnPXMe+yxiLuvEQ5tfOprnc/djw2/k=; b=DadRmKWsoslpgJR+xyqVUT4MJWfQwc9B0vqXbh8TePmhZLHcCluw4h11 bzueXd9daxGuGn5IWMVvj42+ofpgN4khbirYZ0+sCrd4TYzuvPHjcCi1k F7vdhPFmI9NlNP6/Rd9/QSLAR0PW2M+oa+dPqCs9QlEpi8JXlrvU55w/7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DVCgBLq/hU/5FdJa1agwZSWgS7OYNIgjaFcAKBO00BAQEBAQF8hBABAQRnEhACAQhGMiUCBAENBQmIJQEN2C4BAQEBAQEBAQEBAQEBAQEBAQEBARiLF4QMEQFQAgWEKwWFd4RAhVCDY4VqgRo5gm2PLyOCMoE8bwGBCjl/AQEB X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208";a="401234245" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 05 Mar 2015 19:20:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t25JKI88022166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 19:20:18 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 13:20:18 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) Thread-Index: AQHQV1vtJw49ArvUAU2P1NimIKbc3p0OIpaA Date: Thu, 5 Mar 2015 19:20:17 +0000 Message-ID: References: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> In-Reply-To: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> 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: [171.70.241.212] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) 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: Thu, 05 Mar 2015 19:20:21 -0000 On 3/5/15, 7:46 AM, "Stephen Farrell" wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-netext-ani-location-08: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > > >- What if the network being identified here was a tethering >n/w or any other kind of n/w that's carried about by a person? >In that case ANI, and these new options, would be privacy >invasive. Does that statement exist in one of the RFCs >referred to in section 6? If not, would it be worth adding >here, even though it might better belong elsewhere? Copying Brian=B9s answer as well for context. That isn't applicable as far as I know. The location option is used between the two infrastructure devices (LMA and MAG) providing the proxy mobility service. The actual user's location is not being carried and the MAG is not a mobile platform. Yes, I agree. The civic location is that of the MAG (and not the end-user) and the MAG is typically on a router, access point, etc. > >- intro: What if a WLAN operator has no realm? The operator-identifier (which contains realm) is optional. They can choose to not send it if they have no realm. > >- intro: DPI? What's that got to do with it? I'd suggest >removing that. Ok. > > From nobody Thu Mar 5 11:20:27 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A0F441A8742; Thu, 5 Mar 2015 11:20:21 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742A51A8741; Thu, 5 Mar 2015 11:20:21 -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 wE5_OEKjttxC; Thu, 5 Mar 2015 11:20:19 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97E411A873E; Thu, 5 Mar 2015 11:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1924; q=dns/txt; s=iport; t=1425583219; x=1426792819; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=r4Lu5z7YwetZvFnPXMe+yxiLuvEQ5tfOprnc/djw2/k=; b=DadRmKWsoslpgJR+xyqVUT4MJWfQwc9B0vqXbh8TePmhZLHcCluw4h11 bzueXd9daxGuGn5IWMVvj42+ofpgN4khbirYZ0+sCrd4TYzuvPHjcCi1k F7vdhPFmI9NlNP6/Rd9/QSLAR0PW2M+oa+dPqCs9QlEpi8JXlrvU55w/7 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DVCgBLq/hU/5FdJa1agwZSWgS7OYNIgjaFcAKBO00BAQEBAQF8hBABAQRnEhACAQhGMiUCBAENBQmIJQEN2C4BAQEBAQEBAQEBAQEBAQEBAQEBARiLF4QMEQFQAgWEKwWFd4RAhVCDY4VqgRo5gm2PLyOCMoE8bwGBCjl/AQEB X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208";a="401234245" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP; 05 Mar 2015 19:20:18 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t25JKI88022166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 19:20:18 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 13:20:18 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: Stephen Farrell , The IESG Thread-Topic: Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) Thread-Index: AQHQV1vtJw49ArvUAU2P1NimIKbc3p0OIpaA Date: Thu, 5 Mar 2015 19:20:17 +0000 Message-ID: References: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> In-Reply-To: <20150305154630.11284.40854.idtracker@ietfa.amsl.com> 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: [171.70.241.212] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Stephen Farrell's No Objection on draft-ietf-netext-ani-location-08: (with COMMENT) 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: Thu, 05 Mar 2015 19:20:21 -0000 On 3/5/15, 7:46 AM, "Stephen Farrell" wrote: >Stephen Farrell has entered the following ballot position for >draft-ietf-netext-ani-location-08: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > > >- What if the network being identified here was a tethering >n/w or any other kind of n/w that's carried about by a person? >In that case ANI, and these new options, would be privacy >invasive. Does that statement exist in one of the RFCs >referred to in section 6? If not, would it be worth adding >here, even though it might better belong elsewhere? Copying Brian=B9s answer as well for context. That isn't applicable as far as I know. The location option is used between the two infrastructure devices (LMA and MAG) providing the proxy mobility service. The actual user's location is not being carried and the MAG is not a mobile platform. Yes, I agree. The civic location is that of the MAG (and not the end-user) and the MAG is typically on a router, access point, etc. > >- intro: What if a WLAN operator has no realm? The operator-identifier (which contains realm) is optional. They can choose to not send it if they have no realm. > >- intro: DPI? What's that got to do with it? I'd suggest >removing that. Ok. > > From nobody Thu Mar 5 11:49:32 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 D3FAF1A88D5; Thu, 5 Mar 2015 11:49:30 -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 UA8DWK7OuBDn; Thu, 5 Mar 2015 11:49:29 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31FF1A88CA; Thu, 5 Mar 2015 11:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3505; q=dns/txt; s=iport; t=1425584970; x=1426794570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gQdOr9viuK4V6KJOPNzV0Pi5T0OrTBmqwwivOrDawHQ=; b=ABOVtwRW5V0aZ2h0SIvq8L51q2j06vkrnC2fU7q0f3Z/KQDJBjgBnkJK mVGpeVtI4nRed7YnR97ynQdjyTxo1oDdjZRSfvF1peeurhVuk3EhOCH1V JJjxG9QLvxHbZlVqVOUtiywSSZIgJt09IdF7NT3vl9KYZtY+oTIIIOHfy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBgACs/hU/5BdJa1agwZSWgS/AYIsCoUnSQKBO00BAQEBAQF8hBABAQQBAQE3NAsQAgEIDigQJwslAgQBDQUJiCUBDdgtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhAwLBgFQAgWEKwWFd4oQg2OCGINSgRo5gm2LbYNCI4F/HxSBPG8BgQIIFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208";a="129320103" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 05 Mar 2015 19:49:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t25JnRG1018926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 19:49:28 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 13:49:27 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: Richard Barnes , The IESG Thread-Topic: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) Thread-Index: AQHQVuyhoJvOx1fN5UqX5E4fYH1vKp0OK5oA Date: Thu, 5 Mar 2015 19:49:27 +0000 Message-ID: References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> In-Reply-To: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> 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: [171.70.241.212] Content-Type: text/plain; charset="us-ascii" Content-ID: <136C6A2EA185CE49A8740E41E022278B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 05 Mar 2015 19:49:31 -0000 Hello=20 Thanks for the review and suggestions. Best=20 Rajesh On 3/4/15, 6:32 PM, "Richard Barnes" wrote: >Richard Barnes has entered the following ballot position for >draft-ietf-netext-ani-location-08: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >(1) In Section 3.1, the "civic location" description here mentions the >use of a location URI, but there's no corresponding Format for it. Is >that what you actually mean to have for XML Encoding (1)? You're not >going to fit much XML in 253 octets anyway. I would suggest having >format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML >document. So, yes we recognized the limitation of not being able to fit much in 253 bytes.=20 Initially, we felt that it was still worthwhile to have that option in case someone wanted to fit an XML based object within that. But, I am increasingly skeptical of the value. So I am okay with the change suggested.=20 However, this may be a moot point given what we decide with respect to your point (3) below. =20 > >(2) It would help interoperability if you could constrain the classes of >location URI that are supported. For example, if the mechanism in RFC >6753 is sufficient for your purposes, you could require that geolocation >values in format 1 use an HTTPS URI to be dereferenced using that >mechanism. Likewise, unless there's a known, compelling need to support >HTTP URIs, you should require HTTPS. The fact that you have 253 format >codes remaining means that if there are future needs for other URI types, >you can liberalize. > >(3) To ensure that the location information referenced by location URIs >is protected, please comment on the assumed access control model for >these URIs. Can anyone with the URI dereference it? Or are they >required to be access-controlled? Section 4 of RFC 6753 should provide a >helpful framework. > >(4) Alternatively to (2) and (3), you could just remove the option for a >XML/URI-based location altogether. Is there a compelling use cases here >for very precise location? Even with the 253-octet limit, the RFC 4776 >format would allow you to specify down to roughly the neighborhood level >in most cases. For example, encoding "Washington, DC 20001, US" takes >only 26 octets. Even looking at some Japanese addresses, which are more >verbose, the examples I'm finding are still on the order of 70-100 >octets. I am quite in favor of this, because I think the DHCP based option will meet all the deployment scenarios and the preferred option because it eliminates the need for dereferencing. if there is a need for it, we can always come back and add other formats in the future (for example URL based) > > > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Thu Mar 5 11:49:40 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 004381A88D7; Thu, 5 Mar 2015 11:49:30 -0800 (PST) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FAF1A88D5; Thu, 5 Mar 2015 11:49:30 -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 UA8DWK7OuBDn; Thu, 5 Mar 2015 11:49:29 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31FF1A88CA; Thu, 5 Mar 2015 11:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3505; q=dns/txt; s=iport; t=1425584970; x=1426794570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gQdOr9viuK4V6KJOPNzV0Pi5T0OrTBmqwwivOrDawHQ=; b=ABOVtwRW5V0aZ2h0SIvq8L51q2j06vkrnC2fU7q0f3Z/KQDJBjgBnkJK mVGpeVtI4nRed7YnR97ynQdjyTxo1oDdjZRSfvF1peeurhVuk3EhOCH1V JJjxG9QLvxHbZlVqVOUtiywSSZIgJt09IdF7NT3vl9KYZtY+oTIIIOHfy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CvBgACs/hU/5BdJa1agwZSWgS/AYIsCoUnSQKBO00BAQEBAQF8hBABAQQBAQE3NAsQAgEIDigQJwslAgQBDQUJiCUBDdgtAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhAwLBgFQAgWEKwWFd4oQg2OCGINSgRo5gm2LbYNCI4F/HxSBPG8BgQIIFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,348,1422921600"; d="scan'208";a="129320103" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 05 Mar 2015 19:49:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t25JnRG1018926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 19:49:28 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 13:49:27 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: Richard Barnes , The IESG Thread-Topic: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) Thread-Index: AQHQVuyhoJvOx1fN5UqX5E4fYH1vKp0OK5oA Date: Thu, 5 Mar 2015 19:49:27 +0000 Message-ID: References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> In-Reply-To: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> 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: [171.70.241.212] Content-Type: text/plain; charset="us-ascii" Content-ID: <136C6A2EA185CE49A8740E41E022278B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 05 Mar 2015 19:49:31 -0000 Hello=20 Thanks for the review and suggestions. Best=20 Rajesh On 3/4/15, 6:32 PM, "Richard Barnes" wrote: >Richard Barnes has entered the following ballot position for >draft-ietf-netext-ani-location-08: Discuss > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ > > > >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >(1) In Section 3.1, the "civic location" description here mentions the >use of a location URI, but there's no corresponding Format for it. Is >that what you actually mean to have for XML Encoding (1)? You're not >going to fit much XML in 253 octets anyway. I would suggest having >format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML >document. So, yes we recognized the limitation of not being able to fit much in 253 bytes.=20 Initially, we felt that it was still worthwhile to have that option in case someone wanted to fit an XML based object within that. But, I am increasingly skeptical of the value. So I am okay with the change suggested.=20 However, this may be a moot point given what we decide with respect to your point (3) below. =20 > >(2) It would help interoperability if you could constrain the classes of >location URI that are supported. For example, if the mechanism in RFC >6753 is sufficient for your purposes, you could require that geolocation >values in format 1 use an HTTPS URI to be dereferenced using that >mechanism. Likewise, unless there's a known, compelling need to support >HTTP URIs, you should require HTTPS. The fact that you have 253 format >codes remaining means that if there are future needs for other URI types, >you can liberalize. > >(3) To ensure that the location information referenced by location URIs >is protected, please comment on the assumed access control model for >these URIs. Can anyone with the URI dereference it? Or are they >required to be access-controlled? Section 4 of RFC 6753 should provide a >helpful framework. > >(4) Alternatively to (2) and (3), you could just remove the option for a >XML/URI-based location altogether. Is there a compelling use cases here >for very precise location? Even with the 253-octet limit, the RFC 4776 >format would allow you to specify down to roughly the neighborhood level >in most cases. For example, encoding "Washington, DC 20001, US" takes >only 26 octets. Even looking at some Japanese addresses, which are more >verbose, the examples I'm finding are still on the order of 70-100 >octets. I am quite in favor of this, because I think the DHCP based option will meet all the deployment scenarios and the preferred option because it eliminates the need for dereferencing. if there is a need for it, we can always come back and add other formats in the future (for example URL based) > > > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Fri Mar 6 03:52: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 5AC751ACDA4; Fri, 6 Mar 2015 03:52:48 -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 pkHdIoq3RBwW; Fri, 6 Mar 2015 03:52:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 272F01ACDA0; Fri, 6 Mar 2015 03:52:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306115247.3186.20830.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 03:52:47 -0800 Archived-At: Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-logical-interface-support-11.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, 06 Mar 2015 11:52:48 -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 : Logical-interface Support for Multi-access enabled IP Hosts Authors : Telemaco Melia Sri Gundavelli Filename : draft-ietf-netext-logical-interface-support-11.txt Pages : 18 Date : 2015-03-06 Abstract: A Logical-interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical-interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-support/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-support-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-logical-interface-support-11 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 Mar 16 22:49:50 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 7D7371A004C; Mon, 16 Mar 2015 22:49:42 -0700 (PDT) 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 PGm91h-XIyAL; Mon, 16 Mar 2015 22:49:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603D01A004B; Mon, 16 Mar 2015 22:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3809; q=dns/txt; s=iport; t=1426571378; x=1427780978; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8PxejwCEM5cHsIP3hD01mlKSfe1EaG65eF2rxdaljRA=; b=BlISsra7wq2LqXRgT8sWUN6JL21uYou795ynAwkfkPsRVtDoNZTtqhLl CT1rKqSm/SsbAIhXD/P4tb1hLIsZ5JL8XCad55TW1WvyyybV3QcoWGRiW BRe1PmM9JOoP6wHjUhNr9jA1J5UKrdnqF38ryzHfkCBx+1PgfCyhGyDWV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DqBgDgvwdV/5BdJa1bgwZSWgTDBIIvCoUsSQKBO0wBAQEBAQF9hBABAQQBAQE3NAsQAgEIDgoeECcLJQIEAQ0FCYgmDck3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhA8LBgFQAgWELQWGDoosg2uCI4NYgRs5gnKMB4NHI4F/HxSBPG8BgQIIFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,414,1422921600"; d="scan'208";a="404290095" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 17 Mar 2015 05:49:37 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2H5nbPW011364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 05:49:37 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 00:49:37 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Richard Barnes , The IESG , "brian@innovationslab.net" Thread-Topic: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) Thread-Index: AQHQVuyhoJvOx1fN5UqX5E4fYH1vKp0OK5oAgBHxUYA= Date: Tue, 17 Mar 2015 05:49:36 +0000 Message-ID: References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> In-Reply-To: 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.6.208] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Tue, 17 Mar 2015 05:49:42 -0000 Hello Richard and Brian Shall I go ahead and make the changes based on (4) and submit a new version ?=20 Thanks Rajesh On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" wrote: >Hello=20 > >Thanks for the review and suggestions. > >Best=20 > >Rajesh >On 3/4/15, 6:32 PM, "Richard Barnes" wrote: > >>Richard Barnes has entered the following ballot position for >>draft-ietf-netext-ani-location-08: Discuss >> >>When responding, please keep the subject line intact and reply to all >>email addresses included in the To and CC lines. (Feel free to cut this >>introductory paragraph, however.) >> >> >>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>for more information about IESG DISCUSS and COMMENT positions. >> >> >>The document, along with other ballot positions, can be found here: >>http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >> >> >> >>---------------------------------------------------------------------- >>DISCUSS: >>---------------------------------------------------------------------- >> >>(1) In Section 3.1, the "civic location" description here mentions the >>use of a location URI, but there's no corresponding Format for it. Is >>that what you actually mean to have for XML Encoding (1)? You're not >>going to fit much XML in 253 octets anyway. I would suggest having >>format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML >>document. > >So, yes we recognized the limitation of not being able to fit much in 253 >bytes.=20 >Initially, we felt that it was still worthwhile to have that option in >case someone wanted to fit an XML based object within that. >But, I am increasingly skeptical of the value. So I am okay with the >change suggested.=20 >However, this may be a moot point given what we decide with respect to >your point (3) below. >=20 >> >>(2) It would help interoperability if you could constrain the classes of >>location URI that are supported. For example, if the mechanism in RFC >>6753 is sufficient for your purposes, you could require that geolocation >>values in format 1 use an HTTPS URI to be dereferenced using that >>mechanism. Likewise, unless there's a known, compelling need to support >>HTTP URIs, you should require HTTPS. The fact that you have 253 format >>codes remaining means that if there are future needs for other URI types, >>you can liberalize. >> >>(3) To ensure that the location information referenced by location URIs >>is protected, please comment on the assumed access control model for >>these URIs. Can anyone with the URI dereference it? Or are they >>required to be access-controlled? Section 4 of RFC 6753 should provide a >>helpful framework. >> >>(4) Alternatively to (2) and (3), you could just remove the option for a >>XML/URI-based location altogether. Is there a compelling use cases here >>for very precise location? Even with the 253-octet limit, the RFC 4776 >>format would allow you to specify down to roughly the neighborhood level >>in most cases. For example, encoding "Washington, DC 20001, US" takes >>only 26 octets. Even looking at some Japanese addresses, which are more >>verbose, the examples I'm finding are still on the order of 70-100 >>octets. > >I am quite in favor of this, because I think the DHCP based option will >meet all the deployment scenarios and the preferred >option because it eliminates the need for dereferencing. >if there is a need for it, we can always come back and add other formats >in the future (for example URL based) > >> >> >> >> >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext > From nobody Mon Mar 16 22:49:58 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B3CD01A0056; Mon, 16 Mar 2015 22:49:42 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7371A004C; Mon, 16 Mar 2015 22:49:42 -0700 (PDT) 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 PGm91h-XIyAL; Mon, 16 Mar 2015 22:49:38 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603D01A004B; Mon, 16 Mar 2015 22:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3809; q=dns/txt; s=iport; t=1426571378; x=1427780978; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8PxejwCEM5cHsIP3hD01mlKSfe1EaG65eF2rxdaljRA=; b=BlISsra7wq2LqXRgT8sWUN6JL21uYou795ynAwkfkPsRVtDoNZTtqhLl CT1rKqSm/SsbAIhXD/P4tb1hLIsZ5JL8XCad55TW1WvyyybV3QcoWGRiW BRe1PmM9JOoP6wHjUhNr9jA1J5UKrdnqF38ryzHfkCBx+1PgfCyhGyDWV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DqBgDgvwdV/5BdJa1bgwZSWgTDBIIvCoUsSQKBO0wBAQEBAQF9hBABAQQBAQE3NAsQAgEIDgoeECcLJQIEAQ0FCYgmDck3AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhA8LBgFQAgWELQWGDoosg2uCI4NYgRs5gnKMB4NHI4F/HxSBPG8BgQIIFyJ/AQEB X-IronPort-AV: E=Sophos;i="5.11,414,1422921600"; d="scan'208";a="404290095" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 17 Mar 2015 05:49:37 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t2H5nbPW011364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Mar 2015 05:49:37 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 17 Mar 2015 00:49:37 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Richard Barnes , The IESG , "brian@innovationslab.net" Thread-Topic: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) Thread-Index: AQHQVuyhoJvOx1fN5UqX5E4fYH1vKp0OK5oAgBHxUYA= Date: Tue, 17 Mar 2015 05:49:36 +0000 Message-ID: References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> In-Reply-To: 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.6.208] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Tue, 17 Mar 2015 05:49:42 -0000 Hello Richard and Brian Shall I go ahead and make the changes based on (4) and submit a new version ?=20 Thanks Rajesh On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" wrote: >Hello=20 > >Thanks for the review and suggestions. > >Best=20 > >Rajesh >On 3/4/15, 6:32 PM, "Richard Barnes" wrote: > >>Richard Barnes has entered the following ballot position for >>draft-ietf-netext-ani-location-08: Discuss >> >>When responding, please keep the subject line intact and reply to all >>email addresses included in the To and CC lines. (Feel free to cut this >>introductory paragraph, however.) >> >> >>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >>for more information about IESG DISCUSS and COMMENT positions. >> >> >>The document, along with other ballot positions, can be found here: >>http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >> >> >> >>---------------------------------------------------------------------- >>DISCUSS: >>---------------------------------------------------------------------- >> >>(1) In Section 3.1, the "civic location" description here mentions the >>use of a location URI, but there's no corresponding Format for it. Is >>that what you actually mean to have for XML Encoding (1)? You're not >>going to fit much XML in 253 octets anyway. I would suggest having >>format 0 be the RFC 4776 format, and format 1 be a URI pointing to an XML >>document. > >So, yes we recognized the limitation of not being able to fit much in 253 >bytes.=20 >Initially, we felt that it was still worthwhile to have that option in >case someone wanted to fit an XML based object within that. >But, I am increasingly skeptical of the value. So I am okay with the >change suggested.=20 >However, this may be a moot point given what we decide with respect to >your point (3) below. >=20 >> >>(2) It would help interoperability if you could constrain the classes of >>location URI that are supported. For example, if the mechanism in RFC >>6753 is sufficient for your purposes, you could require that geolocation >>values in format 1 use an HTTPS URI to be dereferenced using that >>mechanism. Likewise, unless there's a known, compelling need to support >>HTTP URIs, you should require HTTPS. The fact that you have 253 format >>codes remaining means that if there are future needs for other URI types, >>you can liberalize. >> >>(3) To ensure that the location information referenced by location URIs >>is protected, please comment on the assumed access control model for >>these URIs. Can anyone with the URI dereference it? Or are they >>required to be access-controlled? Section 4 of RFC 6753 should provide a >>helpful framework. >> >>(4) Alternatively to (2) and (3), you could just remove the option for a >>XML/URI-based location altogether. Is there a compelling use cases here >>for very precise location? Even with the 253-octet limit, the RFC 4776 >>format would allow you to specify down to roughly the neighborhood level >>in most cases. For example, encoding "Washington, DC 20001, US" takes >>only 26 octets. Even looking at some Japanese addresses, which are more >>verbose, the examples I'm finding are still on the order of 70-100 >>octets. > >I am quite in favor of this, because I think the DHCP based option will >meet all the deployment scenarios and the preferred >option because it eliminates the need for dereferencing. >if there is a need for it, we can always come back and add other formats >in the future (for example URL based) > >> >> >> >> >>_______________________________________________ >>netext mailing list >>netext@ietf.org >>https://www.ietf.org/mailman/listinfo/netext > From nobody Tue Mar 17 05:21:44 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 10AD61A039D; Tue, 17 Mar 2015 05:21:38 -0700 (PDT) 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 ZOatKclaY1HK; Tue, 17 Mar 2015 05:21:36 -0700 (PDT) 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 17C6C1A039A; Tue, 17 Mar 2015 05:21:36 -0700 (PDT) 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 E4A9C88146; Tue, 17 Mar 2015 05:21:35 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 424DA13682AD; Tue, 17 Mar 2015 05:21:35 -0700 (PDT) Message-ID: <55081C46.4000109@innovationslab.net> Date: Tue, 17 Mar 2015 08:21:26 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Rajesh Pazhyannur (rpazhyan)" , Richard Barnes , The IESG References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH" Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Tue, 17 Mar 2015 12:21:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rajesh, On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote: > Hello Richard and Brian >=20 > Shall I go ahead and make the changes based on (4) and submit a new > version ?=20 >=20 I believe option 4 is the best approach. If anyone in the WG disagrees, they can scream now. Regards, Brian > Thanks >=20 > Rajesh >=20 > On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" > wrote: >=20 >> Hello=20 >> >> Thanks for the review and suggestions. >> >> Best=20 >> >> Rajesh >> On 3/4/15, 6:32 PM, "Richard Barnes" wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-netext-ani-location-08: Discuss >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut th= is >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.h= tml >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> (1) In Section 3.1, the "civic location" description here mentions th= e >>> use of a location URI, but there's no corresponding Format for it. I= s >>> that what you actually mean to have for XML Encoding (1)? You're not= >>> going to fit much XML in 253 octets anyway. I would suggest having >>> format 0 be the RFC 4776 format, and format 1 be a URI pointing to an= XML >>> document. >> >> So, yes we recognized the limitation of not being able to fit much in = 253 >> bytes.=20 >> Initially, we felt that it was still worthwhile to have that option in= >> case someone wanted to fit an XML based object within that. >> But, I am increasingly skeptical of the value. So I am okay with the >> change suggested.=20 >> However, this may be a moot point given what we decide with respect to= >> your point (3) below. >> >>> >>> (2) It would help interoperability if you could constrain the classes= of >>> location URI that are supported. For example, if the mechanism in RF= C >>> 6753 is sufficient for your purposes, you could require that geolocat= ion >>> values in format 1 use an HTTPS URI to be dereferenced using that >>> mechanism. Likewise, unless there's a known, compelling need to supp= ort >>> HTTP URIs, you should require HTTPS. The fact that you have 253 form= at >>> codes remaining means that if there are future needs for other URI ty= pes, >>> you can liberalize. >>> >>> (3) To ensure that the location information referenced by location UR= Is >>> is protected, please comment on the assumed access control model for >>> these URIs. Can anyone with the URI dereference it? Or are they >>> required to be access-controlled? Section 4 of RFC 6753 should provi= de a >>> helpful framework. >>> >>> (4) Alternatively to (2) and (3), you could just remove the option fo= r a >>> XML/URI-based location altogether. Is there a compelling use cases h= ere >>> for very precise location? Even with the 253-octet limit, the RFC 47= 76 >>> format would allow you to specify down to roughly the neighborhood le= vel >>> in most cases. For example, encoding "Washington, DC 20001, US" take= s >>> only 26 octets. Even looking at some Japanese addresses, which are m= ore >>> verbose, the examples I'm finding are still on the order of 70-100 >>> octets. >> >> I am quite in favor of this, because I think the DHCP based option wil= l >> meet all the deployment scenarios and the preferred >> option because it eliminates the need for dereferencing. >> if there is a need for it, we can always come back and add other forma= ts >> in the future (for example URL based) >> >>> >>> >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> --jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCBxLAAoJEBOZRqCi7goqubkH/2hc8XzRzD4zV22qtGD8c8EQ jhPTzYVs/Z8baXNmlhGXE+NSjZRyFREJmuO1VdxR72n8zBBroZJ+Y8+ZTEhk9w7a IGl5pPfLeR2N/NwswlMxYxfDlBVzyyYhnb6JRt40uOzFZavhFtGAthiRc1L92m/7 AdTL5X6qJm0sb2x2zLUjoty4cr7wNbaleoj18DqK6ogi1IDNZvPguu1d7nWLxj4p sBYMtkd+UysqV4i08U+2tvO2Fwv3M38BtZEmNv6AaegGF6tbKE82anNuXzRgBqKO tNgp/Ufd+CVVEJOrH1yJfpV6bhWiNFsG5egH595WzyI8I0p9KM9OXmqm02SXgKA= =NChv -----END PGP SIGNATURE----- --jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH-- From nobody Tue Mar 17 05:21:46 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3CE7E1A039F; Tue, 17 Mar 2015 05:21:38 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD61A039D; Tue, 17 Mar 2015 05:21:38 -0700 (PDT) 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 ZOatKclaY1HK; Tue, 17 Mar 2015 05:21:36 -0700 (PDT) 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 17C6C1A039A; Tue, 17 Mar 2015 05:21:36 -0700 (PDT) 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 E4A9C88146; Tue, 17 Mar 2015 05:21:35 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 424DA13682AD; Tue, 17 Mar 2015 05:21:35 -0700 (PDT) Message-ID: <55081C46.4000109@innovationslab.net> Date: Tue, 17 Mar 2015 08:21:26 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Rajesh Pazhyannur (rpazhyan)" , Richard Barnes , The IESG References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH" Archived-At: Cc: "netext@ietf.org" , "netext-chairs@ietf.org" , "draft-ietf-netext-ani-location.all@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Tue, 17 Mar 2015 12:21:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rajesh, On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote: > Hello Richard and Brian >=20 > Shall I go ahead and make the changes based on (4) and submit a new > version ?=20 >=20 I believe option 4 is the best approach. If anyone in the WG disagrees, they can scream now. Regards, Brian > Thanks >=20 > Rajesh >=20 > On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" > wrote: >=20 >> Hello=20 >> >> Thanks for the review and suggestions. >> >> Best=20 >> >> Rajesh >> On 3/4/15, 6:32 PM, "Richard Barnes" wrote: >> >>> Richard Barnes has entered the following ballot position for >>> draft-ietf-netext-ani-location-08: Discuss >>> >>> When responding, please keep the subject line intact and reply to all= >>> email addresses included in the To and CC lines. (Feel free to cut th= is >>> introductory paragraph, however.) >>> >>> >>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.h= tml >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >>> >>> >>> >>> ---------------------------------------------------------------------= - >>> DISCUSS: >>> ---------------------------------------------------------------------= - >>> >>> (1) In Section 3.1, the "civic location" description here mentions th= e >>> use of a location URI, but there's no corresponding Format for it. I= s >>> that what you actually mean to have for XML Encoding (1)? You're not= >>> going to fit much XML in 253 octets anyway. I would suggest having >>> format 0 be the RFC 4776 format, and format 1 be a URI pointing to an= XML >>> document. >> >> So, yes we recognized the limitation of not being able to fit much in = 253 >> bytes.=20 >> Initially, we felt that it was still worthwhile to have that option in= >> case someone wanted to fit an XML based object within that. >> But, I am increasingly skeptical of the value. So I am okay with the >> change suggested.=20 >> However, this may be a moot point given what we decide with respect to= >> your point (3) below. >> >>> >>> (2) It would help interoperability if you could constrain the classes= of >>> location URI that are supported. For example, if the mechanism in RF= C >>> 6753 is sufficient for your purposes, you could require that geolocat= ion >>> values in format 1 use an HTTPS URI to be dereferenced using that >>> mechanism. Likewise, unless there's a known, compelling need to supp= ort >>> HTTP URIs, you should require HTTPS. The fact that you have 253 form= at >>> codes remaining means that if there are future needs for other URI ty= pes, >>> you can liberalize. >>> >>> (3) To ensure that the location information referenced by location UR= Is >>> is protected, please comment on the assumed access control model for >>> these URIs. Can anyone with the URI dereference it? Or are they >>> required to be access-controlled? Section 4 of RFC 6753 should provi= de a >>> helpful framework. >>> >>> (4) Alternatively to (2) and (3), you could just remove the option fo= r a >>> XML/URI-based location altogether. Is there a compelling use cases h= ere >>> for very precise location? Even with the 253-octet limit, the RFC 47= 76 >>> format would allow you to specify down to roughly the neighborhood le= vel >>> in most cases. For example, encoding "Washington, DC 20001, US" take= s >>> only 26 octets. Even looking at some Japanese addresses, which are m= ore >>> verbose, the examples I'm finding are still on the order of 70-100 >>> octets. >> >> I am quite in favor of this, because I think the DHCP based option wil= l >> meet all the deployment scenarios and the preferred >> option because it eliminates the need for dereferencing. >> if there is a need for it, we can always come back and add other forma= ts >> in the future (for example URL based) >> >>> >>> >>> >>> >>> _______________________________________________ >>> netext mailing list >>> netext@ietf.org >>> https://www.ietf.org/mailman/listinfo/netext >> --jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCBxLAAoJEBOZRqCi7goqubkH/2hc8XzRzD4zV22qtGD8c8EQ jhPTzYVs/Z8baXNmlhGXE+NSjZRyFREJmuO1VdxR72n8zBBroZJ+Y8+ZTEhk9w7a IGl5pPfLeR2N/NwswlMxYxfDlBVzyyYhnb6JRt40uOzFZavhFtGAthiRc1L92m/7 AdTL5X6qJm0sb2x2zLUjoty4cr7wNbaleoj18DqK6ogi1IDNZvPguu1d7nWLxj4p sBYMtkd+UysqV4i08U+2tvO2Fwv3M38BtZEmNv6AaegGF6tbKE82anNuXzRgBqKO tNgp/Ufd+CVVEJOrH1yJfpV6bhWiNFsG5egH595WzyI8I0p9KM9OXmqm02SXgKA= =NChv -----END PGP SIGNATURE----- --jk0ibvrS4VGNmDvIGOvhflmcxwjlFiRhH-- From nobody Thu Mar 19 09:44:44 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 05F491A1BF4 for ; Thu, 19 Mar 2015 09:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 5MhT5d9FUo59 for ; Thu, 19 Mar 2015 09:44:40 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEB51A1DBD for ; Thu, 19 Mar 2015 09:44:38 -0700 (PDT) Received: by ladw1 with SMTP id w1so66940886lad.0 for ; Thu, 19 Mar 2015 09:44:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HODp5WvRyMWidhDAIXHsKoyB8F4D06idaz2odg730Eg=; b=d1boPR4QFLYfLcxcn1VmKmOLDGCkws18YyEpdvHGGaBVY+ROiACPbVdbkD2r1KSmt7 9jkgpuC3Bww6t5bADtEeLVPwVcKwn0Ff/zTfOsnAhbToBq5DXOXNbbX4Ha/LHKEdL9XX lrR9yoYsr9TD3ax0CTmqd2elp4PWVnsYb8aJqrbcgnrg0PGJoO8udkoro7l+pCSy5E6L 3NpPAfdVdTz3Fa8U2Ps9behYR/BUvG7hEJxnjmmRYbYWwrDidMC+H9Ub6/cFofVxmu2S soIKyofRdrMKcTlHW4gC9ymyU4aiCwNLN2MVYXocbMOsNBuRV16Irw56TySaTri311AW SOXg== X-Gm-Message-State: ALoCoQkcB4U0885nPXI+OxXaOCKIh7QVzMe6hC7eENfFrb/aDCm2VNg9sXExtnkJL/hdFeXLTGTC MIME-Version: 1.0 X-Received: by 10.112.148.38 with SMTP id tp6mr69185993lbb.82.1426783476827; Thu, 19 Mar 2015 09:44:36 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 09:44:36 -0700 (PDT) In-Reply-To: <55081C46.4000109@innovationslab.net> References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> <55081C46.4000109@innovationslab.net> Date: Thu, 19 Mar 2015 12:44:36 -0400 Message-ID: From: Richard Barnes To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b343fbe4ed3fc0511a6ea51 Archived-At: Cc: "draft-ietf-netext-ani-location.all@ietf.org" , The IESG , "netext-chairs@ietf.org" , "netext@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 19 Mar 2015 16:44:43 -0000 --047d7b343fbe4ed3fc0511a6ea51 Content-Type: text/plain; charset=UTF-8 In the spirit of cleaning things out before my departure from the IESG, I went ahead and cleared on this. Brian: I assume you will make sure the relevant change is made? Thanks, --Richard On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman wrote: > Hi Rajesh, > > On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote: > > Hello Richard and Brian > > > > Shall I go ahead and make the changes based on (4) and submit a new > > version ? > > > > I believe option 4 is the best approach. If anyone in the WG disagrees, > they can scream now. > > Regards, > Brian > > > Thanks > > > > Rajesh > > > > On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" > > wrote: > > > >> Hello > >> > >> Thanks for the review and suggestions. > >> > >> Best > >> > >> Rajesh > >> On 3/4/15, 6:32 PM, "Richard Barnes" wrote: > >> > >>> Richard Barnes has entered the following ballot position for > >>> draft-ietf-netext-ani-location-08: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> (1) In Section 3.1, the "civic location" description here mentions the > >>> use of a location URI, but there's no corresponding Format for it. Is > >>> that what you actually mean to have for XML Encoding (1)? You're not > >>> going to fit much XML in 253 octets anyway. I would suggest having > >>> format 0 be the RFC 4776 format, and format 1 be a URI pointing to an > XML > >>> document. > >> > >> So, yes we recognized the limitation of not being able to fit much in > 253 > >> bytes. > >> Initially, we felt that it was still worthwhile to have that option in > >> case someone wanted to fit an XML based object within that. > >> But, I am increasingly skeptical of the value. So I am okay with the > >> change suggested. > >> However, this may be a moot point given what we decide with respect to > >> your point (3) below. > >> > >>> > >>> (2) It would help interoperability if you could constrain the classes > of > >>> location URI that are supported. For example, if the mechanism in RFC > >>> 6753 is sufficient for your purposes, you could require that > geolocation > >>> values in format 1 use an HTTPS URI to be dereferenced using that > >>> mechanism. Likewise, unless there's a known, compelling need to > support > >>> HTTP URIs, you should require HTTPS. The fact that you have 253 format > >>> codes remaining means that if there are future needs for other URI > types, > >>> you can liberalize. > >>> > >>> (3) To ensure that the location information referenced by location URIs > >>> is protected, please comment on the assumed access control model for > >>> these URIs. Can anyone with the URI dereference it? Or are they > >>> required to be access-controlled? Section 4 of RFC 6753 should > provide a > >>> helpful framework. > >>> > >>> (4) Alternatively to (2) and (3), you could just remove the option for > a > >>> XML/URI-based location altogether. Is there a compelling use cases > here > >>> for very precise location? Even with the 253-octet limit, the RFC 4776 > >>> format would allow you to specify down to roughly the neighborhood > level > >>> in most cases. For example, encoding "Washington, DC 20001, US" takes > >>> only 26 octets. Even looking at some Japanese addresses, which are > more > >>> verbose, the examples I'm finding are still on the order of 70-100 > >>> octets. > >> > >> I am quite in favor of this, because I think the DHCP based option will > >> meet all the deployment scenarios and the preferred > >> option because it eliminates the need for dereferencing. > >> if there is a need for it, we can always come back and add other formats > >> in the future (for example URL based) > >> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> netext mailing list > >>> netext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netext > >> > > --047d7b343fbe4ed3fc0511a6ea51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the spirit of cleaning things out before= my departure from the IESG, I went ahead and cleared on this.

Brian: I assume you will make sure the relevant change is made?

Thanks,
--Richard

On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman <brian@innovationslab.net> wrote:
Hi Rajesh,

On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote:
> Hello Richard and Brian
>
> Shall I go ahead and make the changes based on (4) and submit a new > version ?
>

I believe option 4 is the best approach.=C2=A0 If anyone in the WG d= isagrees,
they can scream now.

Regards,
Brian

> Thanks
>
> Rajesh
>
> On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>
> wrote:
>
>> Hello
>>
>> Thanks for the review and suggestions.
>>
>> Best
>>
>> Rajesh
>> On 3/4/15, 6:32 PM, "Richard Barnes" <rlb@ipv.sx> = wrote:
>>
>>> Richard Barnes has entered the following ballot position for >>> draft-ietf-netext-ani-location-08: Discuss
>>>
>>> When responding, please keep the subject line intact and reply= to all
>>> email addresses included in the To and CC lines. (Feel free to= cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement= /discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.=
>>>
>>>
>>> The document, along with other ballot positions, can be found = here:
>>> http://datatracker.ietf.org/doc/draft-ietf-= netext-ani-location/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> DISCUSS:
>>> --------------------------------------------------------------= --------
>>>
>>> (1) In Section 3.1, the "civic location" description= here mentions the
>>> use of a location URI, but there's no corresponding Format= for it.=C2=A0 Is
>>> that what you actually mean to have for XML Encoding (1)?=C2= =A0 You're not
>>> going to fit much XML in 253 octets anyway.=C2=A0 I would sugg= est having
>>> format 0 be the RFC 4776 format, and format 1 be a URI pointin= g to an XML
>>> document.
>>
>> So, yes we recognized the limitation of not being able to fit much= in 253
>> bytes.
>> Initially, we felt that it was still worthwhile to have that optio= n in
>> case someone wanted to fit an XML based object within that.
>> But, I am increasingly skeptical of the value. So I am okay with t= he
>> change suggested.
>> However, this may be a moot point given what we decide with respec= t to
>> your point (3) below.
>>
>>>
>>> (2) It would help interoperability if you could constrain the = classes of
>>> location URI that are supported.=C2=A0 For example, if the mec= hanism in RFC
>>> 6753 is sufficient for your purposes, you could require that g= eolocation
>>> values in format 1 use an HTTPS URI to be dereferenced using t= hat
>>> mechanism.=C2=A0 Likewise, unless there's a known, compell= ing need to support
>>> HTTP URIs, you should require HTTPS.=C2=A0 The fact that you h= ave 253 format
>>> codes remaining means that if there are future needs for other= URI types,
>>> you can liberalize.
>>>
>>> (3) To ensure that the location information referenced by loca= tion URIs
>>> is protected, please comment on the assumed access control mod= el for
>>> these URIs.=C2=A0 Can anyone with the URI dereference it?=C2= =A0 Or are they
>>> required to be access-controlled?=C2=A0 Section 4 of RFC 6753 = should provide a
>>> helpful framework.
>>>
>>> (4) Alternatively to (2) and (3), you could just remove the op= tion for a
>>> XML/URI-based location altogether.=C2=A0 Is there a compelling= use cases here
>>> for very precise location?=C2=A0 Even with the 253-octet limit= , the RFC 4776
>>> format would allow you to specify down to roughly the neighbor= hood level
>>> in most cases.=C2=A0 For example, encoding "Washington, D= C 20001, US" takes
>>> only 26 octets.=C2=A0 Even looking at some Japanese addresses,= which are more
>>> verbose, the examples I'm finding are still on the order o= f 70-100
>>> octets.
>>
>> I am quite in favor of this, because I think the DHCP based option= will
>> meet all the deployment scenarios and the preferred
>> option because it eliminates the need for dereferencing.
>> if there is a need for it, we can always come back and add other f= ormats
>> in the future (for example URL based)
>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netext mailing list
>>> netext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netext
>>


--047d7b343fbe4ed3fc0511a6ea51-- From nobody Thu Mar 19 09:44:48 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1E7951A1EB7; Thu, 19 Mar 2015 09:44:45 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10241ACE4F for ; Thu, 19 Mar 2015 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 7XRZ9buCzdTj for ; Thu, 19 Mar 2015 09:44:43 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20FC1A1EB7 for ; Thu, 19 Mar 2015 09:44:38 -0700 (PDT) Received: by lbcgn8 with SMTP id gn8so57070631lbc.2 for ; Thu, 19 Mar 2015 09:44:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HODp5WvRyMWidhDAIXHsKoyB8F4D06idaz2odg730Eg=; b=l9FWBHoAiwgLt4iYeGs1jTMWqvQcG9wPBdnGWyhtJ9gy5PPaP/b6M503k4S+xuhOpa HcRIIIjtvGw0fHE9LpJ0Vi3kTe0uzqKrp74xtB9Wd8qe2aUZVHzM/MV3lPrgZDwwUzJc qMObt2zKEj6ubpDwf7OKlbvAnbaQ9PKTcuRw6mkU0tV1J3/LpWdDrFXOoYa/AcQXkRGD JgIlM8NVndqwO78u6+d62C8A7VU6dqn+Lg33wZH0+SOPS7Uwh3KH/RXcU7UXp+icd1kY EWn7rWQ6iSTMV8ltjOHATwkLi8jHnK5c3i1/gkSXCa1c2gGfeMM7Q6sU6kOh+IE/y2Hq 3/YQ== X-Gm-Message-State: ALoCoQmY6KFRz4x5XHn+j0S1jiMuuzF9YjsymoDnV/ceeniQIsJj/9By0aI3jh4zBGy55nDXRyAK MIME-Version: 1.0 X-Received: by 10.112.148.38 with SMTP id tp6mr69185993lbb.82.1426783476827; Thu, 19 Mar 2015 09:44:36 -0700 (PDT) Received: by 10.25.135.4 with HTTP; Thu, 19 Mar 2015 09:44:36 -0700 (PDT) In-Reply-To: <55081C46.4000109@innovationslab.net> References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> <55081C46.4000109@innovationslab.net> Date: Thu, 19 Mar 2015 12:44:36 -0400 Message-ID: From: Richard Barnes To: Brian Haberman Content-Type: multipart/alternative; boundary=047d7b343fbe4ed3fc0511a6ea51 Archived-At: Cc: "draft-ietf-netext-ani-location.all@ietf.org" , The IESG , "netext-chairs@ietf.org" , "netext@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 19 Mar 2015 16:44:45 -0000 --047d7b343fbe4ed3fc0511a6ea51 Content-Type: text/plain; charset=UTF-8 In the spirit of cleaning things out before my departure from the IESG, I went ahead and cleared on this. Brian: I assume you will make sure the relevant change is made? Thanks, --Richard On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman wrote: > Hi Rajesh, > > On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote: > > Hello Richard and Brian > > > > Shall I go ahead and make the changes based on (4) and submit a new > > version ? > > > > I believe option 4 is the best approach. If anyone in the WG disagrees, > they can scream now. > > Regards, > Brian > > > Thanks > > > > Rajesh > > > > On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" > > wrote: > > > >> Hello > >> > >> Thanks for the review and suggestions. > >> > >> Best > >> > >> Rajesh > >> On 3/4/15, 6:32 PM, "Richard Barnes" wrote: > >> > >>> Richard Barnes has entered the following ballot position for > >>> draft-ietf-netext-ani-location-08: Discuss > >>> > >>> When responding, please keep the subject line intact and reply to all > >>> email addresses included in the To and CC lines. (Feel free to cut this > >>> introductory paragraph, however.) > >>> > >>> > >>> Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > >>> for more information about IESG DISCUSS and COMMENT positions. > >>> > >>> > >>> The document, along with other ballot positions, can be found here: > >>> http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ > >>> > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> DISCUSS: > >>> ---------------------------------------------------------------------- > >>> > >>> (1) In Section 3.1, the "civic location" description here mentions the > >>> use of a location URI, but there's no corresponding Format for it. Is > >>> that what you actually mean to have for XML Encoding (1)? You're not > >>> going to fit much XML in 253 octets anyway. I would suggest having > >>> format 0 be the RFC 4776 format, and format 1 be a URI pointing to an > XML > >>> document. > >> > >> So, yes we recognized the limitation of not being able to fit much in > 253 > >> bytes. > >> Initially, we felt that it was still worthwhile to have that option in > >> case someone wanted to fit an XML based object within that. > >> But, I am increasingly skeptical of the value. So I am okay with the > >> change suggested. > >> However, this may be a moot point given what we decide with respect to > >> your point (3) below. > >> > >>> > >>> (2) It would help interoperability if you could constrain the classes > of > >>> location URI that are supported. For example, if the mechanism in RFC > >>> 6753 is sufficient for your purposes, you could require that > geolocation > >>> values in format 1 use an HTTPS URI to be dereferenced using that > >>> mechanism. Likewise, unless there's a known, compelling need to > support > >>> HTTP URIs, you should require HTTPS. The fact that you have 253 format > >>> codes remaining means that if there are future needs for other URI > types, > >>> you can liberalize. > >>> > >>> (3) To ensure that the location information referenced by location URIs > >>> is protected, please comment on the assumed access control model for > >>> these URIs. Can anyone with the URI dereference it? Or are they > >>> required to be access-controlled? Section 4 of RFC 6753 should > provide a > >>> helpful framework. > >>> > >>> (4) Alternatively to (2) and (3), you could just remove the option for > a > >>> XML/URI-based location altogether. Is there a compelling use cases > here > >>> for very precise location? Even with the 253-octet limit, the RFC 4776 > >>> format would allow you to specify down to roughly the neighborhood > level > >>> in most cases. For example, encoding "Washington, DC 20001, US" takes > >>> only 26 octets. Even looking at some Japanese addresses, which are > more > >>> verbose, the examples I'm finding are still on the order of 70-100 > >>> octets. > >> > >> I am quite in favor of this, because I think the DHCP based option will > >> meet all the deployment scenarios and the preferred > >> option because it eliminates the need for dereferencing. > >> if there is a need for it, we can always come back and add other formats > >> in the future (for example URL based) > >> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> netext mailing list > >>> netext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netext > >> > > --047d7b343fbe4ed3fc0511a6ea51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In the spirit of cleaning things out before= my departure from the IESG, I went ahead and cleared on this.

Brian: I assume you will make sure the relevant change is made?

Thanks,
--Richard

On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman <brian@innovationslab.net> wrote:
Hi Rajesh,

On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote:
> Hello Richard and Brian
>
> Shall I go ahead and make the changes based on (4) and submit a new > version ?
>

I believe option 4 is the best approach.=C2=A0 If anyone in the WG d= isagrees,
they can scream now.

Regards,
Brian

> Thanks
>
> Rajesh
>
> On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" <rpazhyan@cisco.com>
> wrote:
>
>> Hello
>>
>> Thanks for the review and suggestions.
>>
>> Best
>>
>> Rajesh
>> On 3/4/15, 6:32 PM, "Richard Barnes" <rlb@ipv.sx> = wrote:
>>
>>> Richard Barnes has entered the following ballot position for >>> draft-ietf-netext-ani-location-08: Discuss
>>>
>>> When responding, please keep the subject line intact and reply= to all
>>> email addresses included in the To and CC lines. (Feel free to= cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to http://www.ietf.org/iesg/statement= /discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.=
>>>
>>>
>>> The document, along with other ballot positions, can be found = here:
>>> http://datatracker.ietf.org/doc/draft-ietf-= netext-ani-location/
>>>
>>>
>>>
>>> --------------------------------------------------------------= --------
>>> DISCUSS:
>>> --------------------------------------------------------------= --------
>>>
>>> (1) In Section 3.1, the "civic location" description= here mentions the
>>> use of a location URI, but there's no corresponding Format= for it.=C2=A0 Is
>>> that what you actually mean to have for XML Encoding (1)?=C2= =A0 You're not
>>> going to fit much XML in 253 octets anyway.=C2=A0 I would sugg= est having
>>> format 0 be the RFC 4776 format, and format 1 be a URI pointin= g to an XML
>>> document.
>>
>> So, yes we recognized the limitation of not being able to fit much= in 253
>> bytes.
>> Initially, we felt that it was still worthwhile to have that optio= n in
>> case someone wanted to fit an XML based object within that.
>> But, I am increasingly skeptical of the value. So I am okay with t= he
>> change suggested.
>> However, this may be a moot point given what we decide with respec= t to
>> your point (3) below.
>>
>>>
>>> (2) It would help interoperability if you could constrain the = classes of
>>> location URI that are supported.=C2=A0 For example, if the mec= hanism in RFC
>>> 6753 is sufficient for your purposes, you could require that g= eolocation
>>> values in format 1 use an HTTPS URI to be dereferenced using t= hat
>>> mechanism.=C2=A0 Likewise, unless there's a known, compell= ing need to support
>>> HTTP URIs, you should require HTTPS.=C2=A0 The fact that you h= ave 253 format
>>> codes remaining means that if there are future needs for other= URI types,
>>> you can liberalize.
>>>
>>> (3) To ensure that the location information referenced by loca= tion URIs
>>> is protected, please comment on the assumed access control mod= el for
>>> these URIs.=C2=A0 Can anyone with the URI dereference it?=C2= =A0 Or are they
>>> required to be access-controlled?=C2=A0 Section 4 of RFC 6753 = should provide a
>>> helpful framework.
>>>
>>> (4) Alternatively to (2) and (3), you could just remove the op= tion for a
>>> XML/URI-based location altogether.=C2=A0 Is there a compelling= use cases here
>>> for very precise location?=C2=A0 Even with the 253-octet limit= , the RFC 4776
>>> format would allow you to specify down to roughly the neighbor= hood level
>>> in most cases.=C2=A0 For example, encoding "Washington, D= C 20001, US" takes
>>> only 26 octets.=C2=A0 Even looking at some Japanese addresses,= which are more
>>> verbose, the examples I'm finding are still on the order o= f 70-100
>>> octets.
>>
>> I am quite in favor of this, because I think the DHCP based option= will
>> meet all the deployment scenarios and the preferred
>> option because it eliminates the need for dereferencing.
>> if there is a need for it, we can always come back and add other f= ormats
>> in the future (for example URL based)
>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netext mailing list
>>> netext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netext
>>


--047d7b343fbe4ed3fc0511a6ea51-- From nobody Thu Mar 19 10:20:16 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 4A94E1A6FF8; Thu, 19 Mar 2015 10:20:10 -0700 (PDT) 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 tt0ng1YHZyLD; Thu, 19 Mar 2015 10:20:02 -0700 (PDT) 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 EBDEC1A7002; Thu, 19 Mar 2015 10:19:52 -0700 (PDT) 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 C6597880E1; Thu, 19 Mar 2015 10:19:52 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0C663136830E; Thu, 19 Mar 2015 10:19:51 -0700 (PDT) Message-ID: <550B0554.3010404@innovationslab.net> Date: Thu, 19 Mar 2015 13:20:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> <55081C46.4000109@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts" Archived-At: Cc: "draft-ietf-netext-ani-location.all@ietf.org" , The IESG , "netext-chairs@ietf.org" , "netext@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 19 Mar 2015 17:20:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Richard, On 3/19/15 12:44 PM, Richard Barnes wrote: > In the spirit of cleaning things out before my departure from the IESG,= I > went ahead and cleared on this. Cool. >=20 > Brian: I assume you will make sure the relevant change is made? Will do! Thanks! Regards, Brian >=20 > Thanks, > --Richard >=20 > On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman > wrote: >=20 >> Hi Rajesh, >> >> On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote: >>> Hello Richard and Brian >>> >>> Shall I go ahead and make the changes based on (4) and submit a new >>> version ? >>> >> >> I believe option 4 is the best approach. If anyone in the WG disagree= s, >> they can scream now. >> >> Regards, >> Brian >> >>> Thanks >>> >>> Rajesh >>> >>> On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" >>> wrote: >>> >>>> Hello >>>> >>>> Thanks for the review and suggestions. >>>> >>>> Best >>>> >>>> Rajesh >>>> On 3/4/15, 6:32 PM, "Richard Barnes" wrote: >>>> >>>>> Richard Barnes has entered the following ballot position for >>>>> draft-ietf-netext-ani-location-08: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to a= ll >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here:= >>>>> http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------= --- >>>>> DISCUSS: >>>>> -------------------------------------------------------------------= --- >>>>> >>>>> (1) In Section 3.1, the "civic location" description here mentions = the >>>>> use of a location URI, but there's no corresponding Format for it. = Is >>>>> that what you actually mean to have for XML Encoding (1)? You're n= ot >>>>> going to fit much XML in 253 octets anyway. I would suggest having= >>>>> format 0 be the RFC 4776 format, and format 1 be a URI pointing to = an >> XML >>>>> document. >>>> >>>> So, yes we recognized the limitation of not being able to fit much i= n >> 253 >>>> bytes. >>>> Initially, we felt that it was still worthwhile to have that option = in >>>> case someone wanted to fit an XML based object within that. >>>> But, I am increasingly skeptical of the value. So I am okay with the= >>>> change suggested. >>>> However, this may be a moot point given what we decide with respect = to >>>> your point (3) below. >>>> >>>>> >>>>> (2) It would help interoperability if you could constrain the class= es >> of >>>>> location URI that are supported. For example, if the mechanism in = RFC >>>>> 6753 is sufficient for your purposes, you could require that >> geolocation >>>>> values in format 1 use an HTTPS URI to be dereferenced using that >>>>> mechanism. Likewise, unless there's a known, compelling need to >> support >>>>> HTTP URIs, you should require HTTPS. The fact that you have 253 fo= rmat >>>>> codes remaining means that if there are future needs for other URI >> types, >>>>> you can liberalize. >>>>> >>>>> (3) To ensure that the location information referenced by location = URIs >>>>> is protected, please comment on the assumed access control model fo= r >>>>> these URIs. Can anyone with the URI dereference it? Or are they >>>>> required to be access-controlled? Section 4 of RFC 6753 should >> provide a >>>>> helpful framework. >>>>> >>>>> (4) Alternatively to (2) and (3), you could just remove the option = for >> a >>>>> XML/URI-based location altogether. Is there a compelling use cases= >> here >>>>> for very precise location? Even with the 253-octet limit, the RFC = 4776 >>>>> format would allow you to specify down to roughly the neighborhood >> level >>>>> in most cases. For example, encoding "Washington, DC 20001, US" ta= kes >>>>> only 26 octets. Even looking at some Japanese addresses, which are= >> more >>>>> verbose, the examples I'm finding are still on the order of 70-100 >>>>> octets. >>>> >>>> I am quite in favor of this, because I think the DHCP based option w= ill >>>> meet all the deployment scenarios and the preferred >>>> option because it eliminates the need for dereferencing. >>>> if there is a need for it, we can always come back and add other for= mats >>>> in the future (for example URL based) >>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>> >> >> >=20 --aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCwVaAAoJEBOZRqCi7goqHXgH/3++jA/OI3kphwY99zVAdx0H BMPny+L14WlAXwxxNk/P6JBzcZpc9SYUiFDP2n8Jn9HHkd4NE/STN40ksyGBjrfL hoLDzabN+jGu29DmKTOA6JxRXW4o3PRPJAYdtie3DRD1ymLpWoHa0vGt6g7wILBz X4RZ9A6gv6OxUNKAYU/Rmx6QaWaDO6UxX3r1GOusZAZPtE8oawbbZqC02XOYccK7 R+5N9j+Jh9hsIpMV6tSf+LnoeZOFvPbKipP+RHvoR3/Sx5WylBdWP7H9lb1JRkpp Y+lA4St9KRJokpLDslBKXepkI5Vu63QqH8xE3cvY/fe4PUzRD8ZPPKHUxZp9yng= =ym4E -----END PGP SIGNATURE----- --aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts-- From nobody Thu Mar 19 10:20:18 2015 Return-Path: X-Original-To: expand-draft-ietf-netext-ani-location.all@virtual.ietf.org Delivered-To: netext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6EA7C1A7001; Thu, 19 Mar 2015 10:20:10 -0700 (PDT) X-Original-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-netext-ani-location.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A94E1A6FF8; Thu, 19 Mar 2015 10:20:10 -0700 (PDT) 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 tt0ng1YHZyLD; Thu, 19 Mar 2015 10:20:02 -0700 (PDT) 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 EBDEC1A7002; Thu, 19 Mar 2015 10:19:52 -0700 (PDT) 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 C6597880E1; Thu, 19 Mar 2015 10:19:52 -0700 (PDT) Received: from Brians-MacBook-Pro.local (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0C663136830E; Thu, 19 Mar 2015 10:19:51 -0700 (PDT) Message-ID: <550B0554.3010404@innovationslab.net> Date: Thu, 19 Mar 2015 13:20:20 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Barnes References: <20150305023225.22812.66108.idtracker@ietfa.amsl.com> <55081C46.4000109@innovationslab.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts" Archived-At: Cc: "draft-ietf-netext-ani-location.all@ietf.org" , The IESG , "netext-chairs@ietf.org" , "netext@ietf.org" Subject: Re: [netext] Richard Barnes' Discuss on draft-ietf-netext-ani-location-08: (with DISCUSS) 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: Thu, 19 Mar 2015 17:20:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Richard, On 3/19/15 12:44 PM, Richard Barnes wrote: > In the spirit of cleaning things out before my departure from the IESG,= I > went ahead and cleared on this. Cool. >=20 > Brian: I assume you will make sure the relevant change is made? Will do! Thanks! Regards, Brian >=20 > Thanks, > --Richard >=20 > On Tue, Mar 17, 2015 at 8:21 AM, Brian Haberman > wrote: >=20 >> Hi Rajesh, >> >> On 3/17/15 1:49 AM, Rajesh Pazhyannur (rpazhyan) wrote: >>> Hello Richard and Brian >>> >>> Shall I go ahead and make the changes based on (4) and submit a new >>> version ? >>> >> >> I believe option 4 is the best approach. If anyone in the WG disagree= s, >> they can scream now. >> >> Regards, >> Brian >> >>> Thanks >>> >>> Rajesh >>> >>> On 3/5/15, 11:49 AM, "Rajesh Pazhyannur (rpazhyan)" >>> wrote: >>> >>>> Hello >>>> >>>> Thanks for the review and suggestions. >>>> >>>> Best >>>> >>>> Rajesh >>>> On 3/4/15, 6:32 PM, "Richard Barnes" wrote: >>>> >>>>> Richard Barnes has entered the following ballot position for >>>>> draft-ietf-netext-ani-location-08: Discuss >>>>> >>>>> When responding, please keep the subject line intact and reply to a= ll >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>> >>>>> >>>>> Please refer to >> http://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>> >>>>> >>>>> The document, along with other ballot positions, can be found here:= >>>>> http://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ >>>>> >>>>> >>>>> >>>>> -------------------------------------------------------------------= --- >>>>> DISCUSS: >>>>> -------------------------------------------------------------------= --- >>>>> >>>>> (1) In Section 3.1, the "civic location" description here mentions = the >>>>> use of a location URI, but there's no corresponding Format for it. = Is >>>>> that what you actually mean to have for XML Encoding (1)? You're n= ot >>>>> going to fit much XML in 253 octets anyway. I would suggest having= >>>>> format 0 be the RFC 4776 format, and format 1 be a URI pointing to = an >> XML >>>>> document. >>>> >>>> So, yes we recognized the limitation of not being able to fit much i= n >> 253 >>>> bytes. >>>> Initially, we felt that it was still worthwhile to have that option = in >>>> case someone wanted to fit an XML based object within that. >>>> But, I am increasingly skeptical of the value. So I am okay with the= >>>> change suggested. >>>> However, this may be a moot point given what we decide with respect = to >>>> your point (3) below. >>>> >>>>> >>>>> (2) It would help interoperability if you could constrain the class= es >> of >>>>> location URI that are supported. For example, if the mechanism in = RFC >>>>> 6753 is sufficient for your purposes, you could require that >> geolocation >>>>> values in format 1 use an HTTPS URI to be dereferenced using that >>>>> mechanism. Likewise, unless there's a known, compelling need to >> support >>>>> HTTP URIs, you should require HTTPS. The fact that you have 253 fo= rmat >>>>> codes remaining means that if there are future needs for other URI >> types, >>>>> you can liberalize. >>>>> >>>>> (3) To ensure that the location information referenced by location = URIs >>>>> is protected, please comment on the assumed access control model fo= r >>>>> these URIs. Can anyone with the URI dereference it? Or are they >>>>> required to be access-controlled? Section 4 of RFC 6753 should >> provide a >>>>> helpful framework. >>>>> >>>>> (4) Alternatively to (2) and (3), you could just remove the option = for >> a >>>>> XML/URI-based location altogether. Is there a compelling use cases= >> here >>>>> for very precise location? Even with the 253-octet limit, the RFC = 4776 >>>>> format would allow you to specify down to roughly the neighborhood >> level >>>>> in most cases. For example, encoding "Washington, DC 20001, US" ta= kes >>>>> only 26 octets. Even looking at some Japanese addresses, which are= >> more >>>>> verbose, the examples I'm finding are still on the order of 70-100 >>>>> octets. >>>> >>>> I am quite in favor of this, because I think the DHCP based option w= ill >>>> meet all the deployment scenarios and the preferred >>>> option because it eliminates the need for dereferencing. >>>> if there is a need for it, we can always come back and add other for= mats >>>> in the future (for example URL based) >>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netext mailing list >>>>> netext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netext >>>> >> >> >=20 --aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCwVaAAoJEBOZRqCi7goqHXgH/3++jA/OI3kphwY99zVAdx0H BMPny+L14WlAXwxxNk/P6JBzcZpc9SYUiFDP2n8Jn9HHkd4NE/STN40ksyGBjrfL hoLDzabN+jGu29DmKTOA6JxRXW4o3PRPJAYdtie3DRD1ymLpWoHa0vGt6g7wILBz X4RZ9A6gv6OxUNKAYU/Rmx6QaWaDO6UxX3r1GOusZAZPtE8oawbbZqC02XOYccK7 R+5N9j+Jh9hsIpMV6tSf+LnoeZOFvPbKipP+RHvoR3/Sx5WylBdWP7H9lb1JRkpp Y+lA4St9KRJokpLDslBKXepkI5Vu63QqH8xE3cvY/fe4PUzRD8ZPPKHUxZp9yng= =ym4E -----END PGP SIGNATURE----- --aBgH1Dcq5dJ3v81b9eRpqOxtMAICI7Dts-- From nobody Mon Mar 23 08:16:44 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 E46E91A8AEC; Mon, 23 Mar 2015 08:16:31 -0700 (PDT) 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 xCLoAtMImbRG; Mon, 23 Mar 2015 08:16:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC361A8F3A; Mon, 23 Mar 2015 08:16:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323151625.21521.2893.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:16:25 -0700 Archived-At: Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-ani-location-09.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, 23 Mar 2015 15:16:32 -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-09.txt Pages : 12 Date : 2015-03-23 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-09 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 Mar 23 08:16: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 B30671A903E; Mon, 23 Mar 2015 08:16:39 -0700 (PDT) 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 c3GmzJh2NIt2; Mon, 23 Mar 2015 08:16:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B911A9024; Mon, 23 Mar 2015 08:16:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323151626.21521.67001.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 08:16:26 -0700 Archived-At: Subject: [netext] New Version Notification - draft-ietf-netext-ani-location-09.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, 23 Mar 2015 15:16:39 -0000 A new version (-09) has been submitted for draft-ietf-netext-ani-location: http://www.ietf.org/internet-drafts/draft-ietf-netext-ani-location-09.txt 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-09 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 Mon Mar 23 12:18:23 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 4CE561B29AE; Mon, 23 Mar 2015 12:18:22 -0700 (PDT) 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 sS_BtPVjy2wU; Mon, 23 Mar 2015 12:18:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B2A1B29AF; Mon, 23 Mar 2015 12:18:15 -0700 (PDT) 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.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323191815.10801.99536.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 12:18:15 -0700 Archived-At: Cc: netext mailing list , netext chair , RFC Editor Subject: [netext] Protocol Action: 'Extensions to the PMIPv6 Access Network Identifier Option' to Proposed Standard (draft-ietf-netext-ani-location-09.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, 23 Mar 2015 19:18:22 -0000 The IESG has approved the following document: - 'Extensions to the PMIPv6 Access Network Identifier Option' (draft-ietf-netext-ani-location-09.txt) as Proposed Standard 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-ani-location/ 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: At the present time, there are no known implementations. At least one vendor has expressed plans to implement this specification. Personnel: Doc Shepherd: Basavaraj Patil AD: Brian Haberman