Re: [Gen-art] Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07
"Mary Barnes" <mary.barnes@nortel.com> Fri, 09 May 2008 20:12 UTC
Return-Path: <gen-art-bounces@ietf.org>
X-Original-To: gen-art-archive@optimus.ietf.org
Delivered-To: ietfarch-gen-art-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B19A3A67CE; Fri, 9 May 2008 13:12:58 -0700 (PDT)
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1F93A6801 for <gen-art@core3.amsl.com>; Fri, 9 May 2008 13:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Level:
X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ypLzhcMAKb3 for <gen-art@core3.amsl.com>; Fri, 9 May 2008 13:12:54 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E2B723A681A for <gen-art@ietf.org>; Fri, 9 May 2008 13:10:43 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m49J3a817529; Fri, 9 May 2008 19:03:36 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 09 May 2008 14:02:05 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE0360AC1E@zrc2hxm1.corp.nortel.com>
In-Reply-To: <A2692069-AE99-4C7D-9107-B3EABB67E2B8@estacado.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07
Thread-Index: AcivxQ7VBp1aoZxPT7uTo00FqhmjGwCOL3+A
References: <A2692069-AE99-4C7D-9107-B3EABB67E2B8@estacado.net>
From: Mary Barnes <mary.barnes@nortel.com>
To: Ben Campbell <ben@estacado.net>, General Area Review Team <gen-art@ietf.org>
Cc: Cullen Jennings <fluffy@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>, james.winterbottom@andrew.com, "Stark, Barbara" <bs7652@att.com>, martin.thomson@andrew.com
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
Hi Ben, Thank you for your detailed review. After consulting with the contributors, we've come up with the responses embedded below [MB]. Thanks, Mary. -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net] Sent: Tuesday, May 06, 2008 5:02 PM To: Barnes, Mary (RICH2:AR00); james.winterbottom@andrew.com; martin.thomson@andrew.com; barbara.stark@bellsouth.com; General Area Review Team Cc: Robert Sparks; Jon Peterson; Cullen Jennings Subject: Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-http-location-delivery-07 Reviewer: Ben Campbell Review Date: 2008-05-06 IETF LC End Date: 2008-05-07 IESG Telechat date: (if known) Summary: This document is almost ready for publication as a proposed standard. I have a few questions and comments that should be considered prior to publication. Comments: -- Substantive comments: -- I am a little bit confused by the scope of applicability of this draft. Section 3, paragraph 1 says "This document assumes that the LIS is present within the same administrative domain as the Device (e.g., the access network)." However, section A.3. claims compliance to a requirement to the effect of "The design of the L7 LCP MUST NOT assume a business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider." (It is possibly I am misunderstanding what ASP means in this context?) [MB] The ASP is defined in the RFC 5012 (ECRIT requirements that is a normative reference for draft-ietf-geopriv-l7-lcp-ps). The ASP is the entity that provides voice services for example and really should be independent of the LIS. The ASP might eventually make use of the information that a device gets using HELD, however, the ASP is entirely outside the scope of the HELD protocol, which I think is what that requirement is saying. I can see how the response to that requirement could be misleading, so I would propose to change as follows: OLD: HELD describes a location acquisition protocol and has no dependencies on the business or trust relationship between the ASP and the Access Network Provider. Location acquisition using HELD is subject to the restrictions described in Section 10. NEW: HELD describes a location acquisition protocol between a Device and a LIS. In the context of HELD, the LIS is within the Access Network. Thus, HELD is independent of the business or trust relationship between the Application Service Provider (ASP) and the Access Network Provider. Location acquisition using HELD is subject to the restrictions described in Section 10. [/MB] Furthermore, certain aspects of HELD seem to require fairly tight coupling between the LIS and the access network. For example, the NIS needs to know about any range of addresses for which it is likely to have erroneous location info due to VPNs and NATs. The security considerations indicate that the network needs to be properly configured to avoid ip spoofing attacks, which would seem to indicate at least an administrative coupling between the access network provider. It goes on to make a normative statement that network configuration SHOULD be considered. A paragraph or two describing the expected network architecture might clear this up. Maybe this is covered sufficiently in some of the referenced documents? [MB] Figure 1 was intended to show the general architectural elements relevant to HELD. Draft-ietf-geopriv-l7-lcp-ps defines some more specific scenarios, such as DSL, wireless, etc. But, again, these are all independent of the Access Network to ASP interface and are only addressing the interface between a LIS and the entity (Device in the context of the HELD document) requesting the location. The LIS and access network need to share a special relationship, but attempting to enumerate the options is only likely to limit applicability unnecessarily. [/MB] -- I would like to see a little more analysis on the safety of using the source IP address as the device identifier. My instinct says that reverse routeability may keep this from being a problem--but the security considerations do indicate source address spoofing could cause LI to be compromised, and add a list of approaches, "one or more" of which is recommended to limit the exposure. If there are in fact risks of compromise, I think the draft needs some more exhaustive and explicit statements of what I must do to avoid such attacks. [MB] The first bullet is actually documented as a MUST include the "expires" parameter in the protocol section when one uses locationURIs. So, perhaps it would resolve your concern to make that first bullet a MUST and rearrange this slightly, since one MUST do both the first already and per the subsequent paragraph, the third is really only optional in the context of a fixed network. So, I would propose something like the following: OLD: One or more of the following approaches are RECOMMENDED to limit these exposures: o Location URIs SHOULD have a limited lifetime, as reflected by the value for the expires element in Section 6.5.2. o The network SHOULD have mechanisms that protect against IP address spoofing, such as those defined in [RFC3704]. o The LIS and network SHOULD be configured so that the LIS is made aware of Device movement within the network and addressing changes. If the LIS detects a change in the network that results in it no longer being able to determine the location of the Device, then all location URIs for that Device SHOULD be invalidated. The above measures are dependent on network configuration, which SHOULD be considered. For instance, in a fixed internet access, providers may be able to restrict the allocation of IP addresses to a single physical line, ensuring that spoofing is not possible; in such an environment, other measures may not be necessary. NEW: These exposures are limited by the following: o Location URIs MUST have a limited lifetime, as reflected by the value for the expires element in Section 6.5.2. The lifetime of location URIs necessarily depends on the nature of the access. o The network SHOULD have mechanisms that protect against IP address spoofing, such as those defined in [RFC3704]. o The LIS and network SHOULD be configured so that the LIS is made aware of Device movement within the network and addressing changes. If the LIS detects a change in the network that results in it no longer being able to determine the location of the Device, then all location URIs for that Device SHOULD be invalidated. The above measures are dependent on network configuration, which SHOULD be considered. For instance, in a fixed internet access, providers may be able to restrict the allocation of IP addresses to a single physical line, ensuring that spoofing is not possible; in such an environment, additional measures may not be necessary. [/MB] -- The lbyr requirements draft includes a SHOULD level requirement that a client should be able to cancel location references. HELD does not seem to allow for that capability. I know it was only a SHOULD, but was there a particular reason to leave it out? [MB] The pre-working group version of HELD had an explicit means to void a location URI, and provided a means for the Target to set the lifetime of the URI. Such a mechanism requires explicit management of Target state on the LIS. It was decided by the WG that this wasn't necessary for the base specification. There is one individual submission that currently addresses these considerations but no formal approach has been adopted by the WG at this stage. [/MB] -- Section 4.2: I understand that the authz mechanisms for dereferencing location URLs constitute a bit of an "elephant in the room". But do we really think it is useful to punt entirely on that? The referenced doc does not seem all that helpful on the matter. Even an example of a potentially useful approach might be helpful. (I realize this is not a HELD problem per se, but without some mechanism for it, I question the usefulness of location by reference in HELD.) (If we can point to a location dereference protocol and claim that spec solves this, then no problem.) [MB] This should be addressed in the deref-protocol document. I can add a reference to that doc, as well, if you think it's necessary. [/MB] Section 4.3.1: Should there be normative advice in this section? [MB] I'm not clear as to whether you're suggesting we should or should not have normative text in this section. We do have normative statements in the first paragraph, but there aren't in the second. Part of the issue is this text was carefully crafted as a result of WG consensus, thus it's perhaps not as strong as some would like. The language was softened in this section during the -03 to -04 changes. The justification was that we can't mandate behaviors on elements unless it's specific to the actual protocol. [/MB] Section 6.2 and 6.2.1: I don't see an obvious way to say I only want to get location by value. Is that intentional? [MB] Correct. You cannot ask for just "any" location by value. You can ask for just one type of location or both types using "exact", but you can't do an either/or. If you want either/or, then you may also get a locationURI by just using "any". It makes the protocol slightly more complicated to allow that, when it didn't seem like that would be a high runner - e.g., if neither of the location by values were available, then wouldn't you want to use a locationURI, so this in the end could save on the number of requests at the cost of sometimes getting more information than you want. [/MB] Section 6.3, error code unsupportedMessage: Wasn't there a normative statement ealier that the LIS MUST ignore anything in a request that it does not understand? If so, when would this get used? [MB] The rationale for including this error is take care of any totally new messages that are introduced. The earlier statement is actually a slightly different case, and refers to the concept of additional namespace elements being included in an existing message. For example, if a locationRequest with an identity extension in it is sent, the LIS is free to accept the locationRequest, but ignore the identity extension that it doesn't understand, and everything should just work. The unsupportedMessage case would be like the Target sending a createContext message to the LIS and the LIS being able to send something sensible back to the Target to say I don't understand this. These cases are quite different, and the second case is actually quite catchable by most XML parsers. This could probably be addressed by the following change : OLD: unsupportedMessage: This code indicates that an element in the XML document for the request, was not supported or understood by the LIS. NEW: unsupportedMessage: This code indicates that an element in the XML document for the request, was not supported or understood by the LIS. This error code is used when a HELD request contains a document element that is not supported by the receiver. And, then we should quality that earlier statement in section 5.2 as follows: OLD: The LIS MUST ignore any part of a location request message that it does not understand. NEW: The LIS MUST ignore any part of a location request message that it does not understand, except the document element. [/MB] 6.5.2: Can you give any guidance about useful value ranges for "expires"? I assume very short expirations would not be useful. [MB] Correct. These should not have short expirations. We could add something like the following at the end of that first paragraph: NEW: The "expires" parameter is RECOMMENDED not to exceed 24 hours. [/MB] 6.6, last paragraph: "Note that the presence parameter is not explicitly shown in the XML schema Section 7 for a location response message due to XML schema constraints." Is that not a problem, since section 7 is the formal definition of the protocol syntax? [MB] Maybe we should change this to read: "Note that the presence parameter is not explicitly shown in the XML schema Section 7 for a location response message due to XML schema constraints related to the PIDF namespace. Thus, the "##other" namespace serves as a placeholder for the presence parameter in the schema." [/MB] Section 8: I'm a little confused by the fact that a HELD URI can show up both in a HELD response, and in LIS discovery. Does this use of a HELD URI imply the use of the HELD protocol? If so, how would a HELD URI in a locationReponse message be used? Since HELD uses the source IP address for the identifier, it is not useful to transmit the URI to another device, right? [MB] The HELD URI is defined as a fairly general URI that can be used both to provide the URI for a LIS and to provide the URI associated with a specific location. And, there may be other uses - the obvious one being the dereference. The correlation of the source IP address to a specific location URI isn't something specific to HELD - it's the LIS that determines the location (using source IP address) and then provides the LIS associated location URI in the response. This document doesn't provide a complete description of the usages of the URI (e.g., dereference) and it's not the intention to do so, so maybe that's the confusion. The use of the HELD URI within this document is limited by the functionality defined in this document, but shouldn't necessarily limit the use of the HELD URI overall (if that makes sense). Perhaps adding something like the following at the end of that first paragraph would help: NEW: There are other uses of the HELD: URI, such as [I-D.winterbottom-geopriv-deref-protocol]. Thus, the usages of the HELD: URI described in this document are not intended to limit the applicability of the HELD: URI to other relevant interfaces. [/MB] -- Nits and Editorial Comments: [MB] I'll fix all of these that you suggest, although, I've one question on the next to the last one as I'm not clear as to the concern. [/MB] S1: Expand LIS on first use. (You do so later in paragraph.) Section 4: Paragraph 1 I realized at this point I had not yet seen an expansion of "HELD", nor a statement that HELD is the protocol being defined in this document outside of the document title. Maybe an official "naming" sentence in the last paragraph of the intro would help. Also, this paragraph could use explicit references for pidf-lo and location URIs. Section 4.3, paragraph 3: Please expand VPN on first use. Table 1: Can you add a legend for o and m? I know it seems obvious, but better to be explicit. Also, listing locationUriSet and presence both as optional for responses does not quite capture the normative statement that one or the other MUST exist. Section 5.2: Should there be normative language around the inclusion of locationType? (There is for the other parameters) Section 6.2. "any" value: The normative statement that the LIS SHOULD return all available forms seems to mildly conflict with some of the further normative statements in the paragraph. [MB] I'm not sure where the conflict is here. They are all SHOULDs with a couple MAYs and the last paragraph explains the reason for the SHOULDs. [/MB] Section 12.5: URI Scheme Syntax says "See section" with no section number. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Gen-ART LC review of draft-ietf-geopriv… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Mary Barnes
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Mary Barnes
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Mary Barnes
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Ben Campbell
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Cullen Jennings
- Re: [Gen-art] Gen-ART LC review of draft-ietf-geo… Mary Barnes