Re: [Gen-art] Gen-ART LC review of draft-ietf-geopriv-http-location-delivery-07

"Mary Barnes" <mary.barnes@nortel.com> Wed, 14 May 2008 16:28 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 EDCE83A693B; Wed, 14 May 2008 09:28:52 -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 2872A3A695B for <gen-art@core3.amsl.com>; Wed, 14 May 2008 09:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.514
X-Spam-Level:
X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 QuUGXix6pl6E for <gen-art@core3.amsl.com>; Wed, 14 May 2008 09:28:49 -0700 (PDT)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 064DF3A68A7 for <gen-art@ietf.org>; Wed, 14 May 2008 09:28:47 -0700 (PDT)
Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m4EGROx13442; Wed, 14 May 2008 16:27:24 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 14 May 2008 11:24:42 -0500
Message-ID: <F66D7286825402429571678A16C2F5EE0372E8FA@zrc2hxm1.corp.nortel.com>
In-Reply-To: <7CD22E28-D6DE-42D0-92F9-3B05C15BC90A@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: AciyFE3tfq76/2hyTlag2ddkIqWdFQDyngfA
References: <A2692069-AE99-4C7D-9107-B3EABB67E2B8@estacado.net> <F66D7286825402429571678A16C2F5EE0360AC1E@zrc2hxm1.corp.nortel.com> <7CD22E28-D6DE-42D0-92F9-3B05C15BC90A@estacado.net>
From: Mary Barnes <mary.barnes@nortel.com>
To: Ben Campbell <ben@estacado.net>
Cc: Cullen Jennings <fluffy@cisco.com>, Jon Peterson <jon.peterson@neustar.biz>, General Area Review Team <gen-art@ietf.org>, 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,

Thanks for the response. Additional responses are embedded below [MB2].
I've snipped the things with which we have agreement to keep the thread
a bit shorter. 

Mary. 

-----Original Message-----
From: Ben Campbell [mailto:ben@estacado.net] 
Sent: Friday, May 09, 2008 3:35 PM
To: Barnes, Mary (RICH2:AR00)
Cc: General Area Review Team; Robert Sparks; Jon Peterson; Cullen
Jennings; james.winterbottom@andrew.com; martin.thomson@andrew.com;
Stark, Barbara
Subject: Re: Gen-ART LC review of
draft-ietf-geopriv-http-location-delivery-07

Further comments inline:

Thanks!

Ben.

On May 9, 2008, at 2:02 PM, Mary Barnes wrote:

> 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:
>
----snipped by mary for [MB2] responses
>

>
>
> -- 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]

Understood. Maybe a brief mention the fact that HELD intentionally does
not support that use case, and the reasoning behind the decision would
help.

[MB2] How about adding a statement something like the following to
section 4.2 (I'll add this point at the end of section 4.2).
NEW: 
  It should also be noted that while the lybr requirements document
  specifies a requirement that a client SHOULD be able to cancel
  location references, the protocol specified in this document
  does not provide that functionality. The mechanism to
  provide this support in the protocol requires explicit management
  of Target state on the LIS. It is anticipated that extensions to HELD
  may support that requirement. 
[/MB2]

>
>
> -- 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]

I'm not sure "necessary" is the right word--but it would certainly
shortcut any argument about whether _this_ draft needs to solve the
problem.

[MB2] In re-reading section 4.2, I think we need to clarify some of that
text. What it was really trying to say is that the mechanisms (and
authorization) for dereferencing are not a requirement for HELD. But,
rather those requirements are specific to the dereference protocol. So,
I would propose rewording section 4.2 and adding the new text above as a
new paragraph. 

OLD:
   However, this does not in any way suggest that the LIS is bound to 
   reveal the location associated with the location URI.  This issue is

   deemed out of scope for this document.  The merits and drawbacks of 
   using a  Location URI approach are discussed in
   [I-D.ietf-geopriv-lbyr-requirements]

NEW: 
   However, this does not in any way suggest that the LIS 
   indiscriminately reveals the location associated with the location
URI. 
   The specific requirements associated with the dereference of the 
   location are specified in [I-D.ietf-geopriv-lbyr-requirements]. 
   The location dereference protocol details are out of scope of 
   this document and are specified in 
   [I-D.winterbottom-geopriv-location-deref]. 
[/MB2]

>
>
> 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]

So I reread the section, and cannot actually find the place I thought
needed more normative behavior--I think it was a misread on my part.  
However, in the process of re-reading it, I wonder if there is not a
conflict between the normative advice about the client performing
discovery prior to the establishment of the VPN, and the architectural
advice about what VPN device behavior, since if the device follows the
recommended behavior the VPN response to discovery would never get
excercised.

I am guessing the intent is to say that the special "closed network"  
guidance is for situations where one might have a good reason to ignore
the RECOMMENDED advice about client behavior. If that is correct, some
more precise words to that effect might help.

[MB2] The second paragraph in section 4.3.1 is actually independent of
the first (in some sense).  The first paragraph is saying that if you
use a VPN Tunnel (like I do when I work from home), you really should
determine your Location before you setup your tunnel.  The second
paragraph builds on that concept and is describing a configuration
whereby another entity that establishes a VPN (i.e., the devices aren't
aware that a VPN is being used) serves as the LIS for those Devices,
rather than tunneling location requests to a LIS that might not be
geographically relevant. 

In the first paragraph we do specify what might happen if you don't
follow the RECOMMENDED behavior - you might not get the right location
(eg., in my case the firetruck goes to Richardson instead of Flower
Mound right now). Maybe your concern is that we don't re-iterate that
same point for the second paragraph (i.e., if the VPN device doesn't
serve as a LIS and just tunnels those requests, many devices will get
the wrong location). 

[/MB2]

>
>
> 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]

Just to make sure I understand: You can request lbyr only, by asserting
"locationURI" and "exact", but there is nothing I can combine with
"exact" to get me by-value only. Does that mean that you assume it
possible to have devices that only understand lbyr, but not common to
have devices that only understand lbyv? Or that sending by value when
the device doesn't want it is somehow more damaging than sending by
reference if the device doesn't want it?

On re-reading the section, I think it would be helpful to talk a little
more about how the values can be combined. I am somewhat confused by the
fact that the class of location (geodetic, civic,etc) is combined with
the way it is transmitted (by value or by reference.) Are these not
orthagonal?

[MB2]
 Part of the confusion may be due to your nit on the text in that
section. I've proposed some modified text below that I think clarifies
things. I've also added an additional statement about this point.

[/MB2]

>
>
> 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]

Should there be a recommended minimum? I can see how very short values
could cause a lot of poling, or even situations where the location
object expires before it can be delivered to the consumer.

[MB2]  We could suggest a recommended minimum of several minutes. I
can't see anything less than that being particularly useful. Or we could
just specify that it should be in 10s of minutes rather than a few. 
[/MB2]

>
>
> 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]

Okay, I guess. I am probably showing my ignorance of XML schema here.  
It just seemed strange that what I thought was an important data
structure for this protocol is left out of it's formal schema. I don't
really understand schema enough to grok the "schema constraints"  
causing the issue.

[MB2] I'm not an XML guru either, but my understanding is that since the
schema we're wanting to use is already defined elsewhere, we don't want
to duplicate that definition. But, since PIDF is defined already, we can
explicitly use it per the examples. [/MB2]

>
>
>
>
> 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]

To test my understanding: The deref protocol is a completely different
protocol than HELD, but the HELD URI semantics work there as well?  
That is to say, that the dereferencer is _not_ using HELD per se, but
the URI is still useful? I was assuming that the URI type implied the
use of HELD, which didn't seem to make sense for dereference due to the
binding to source IP.

[MB2] The only dereference protocol defined right now is based on HELD,
but it doesn't have to be.  And, again there are different set of
requirements to be supported by the deref protocol, which are not
required to be supported by HELD as specified in this document. [/MB2]


I have some mild confusion over making the URI scheme "held" when the
URI is generally useful across other protocols, but it's probably not
worth pushing this late in the process (and in my experience the only
way to win "naming" games is not to play, sort of like for  global
thermonuclear war.)

[...]

>
>
> 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]

[ Warning: this is highly pedantic--which is why I offered it as a nit
rather than as a substantive comment.]

I was reading it to say you SHOULD send everything you have, and going
on to say you SHOULD send certain forms and MAY send others. Since
anything I could possibly send must be a subset of "everything I have",
then the second SHOULD and the MAY are either non-constraining, or a
relaxation of the initial SHOULD.

I would propose either removing the first SHOULD (and maybe indicating
how sending everything you have by definition fulfills the rest of the
normative requirements), or making everything except the SHOULD send
everything you have non-normative.

Of course, it's possible that I am interpreting "SHOULD attempt to
provide LI in all forms available to it" incorrectly.

[MB2] The SHOULDS and MAYs below the list of specific types was intended
to apply to all the types, but really mostly apply when you request a
specific type, since any: really does what the LIS wants to do. So,
maybe we should clarify that and break that paragraph into the general
statements and the statements specific to when a specific
locationType(s) is/are requested (and the last paragraph also applies
just to the request for specific locationType(s).  
OLD:
   The LIS SHOULD return the requested location type or types.  The LIS
   MAY provide additional location types, or it MAY provide alternative
   types if the request cannot be satisfied for a requested location
   type.  A location URI provided by the LIS is a reference to the most
   current available LI and is not a stable reference to a specific
   location.  The location types the LIS returns also depend on the
   setting of the optional "exact" attribute, as described in the
   following section.  The LIS SHOULD provide the locations in the
   response in the same order in which they were included in the
   "locationType" element in the request.

   The "SHOULD"-strength requirements on this parameter are included to
   allow for soft-failover.  This enables a fixed client configuration
   that prefers a specific location type without causing location
   requests to fail when that location type is unavailable.  For
   example, a notebook computer could be configured to retrieve civic
   addresses, which is usually available from typical home or work
   situations.  However, when using a wireless modem, the LIS might be
   unable to provide a civic address and thus provides a geodetic
   address.

NEW: 
   The LIS SHOULD return the requested location type or types.  
   The location types the LIS returns also depend on the
   setting of the optional "exact" attribute, as described in the
   following section.  The "exact" attribute does not apply (is 
   ignored) for a request for a location type of "any". 

   In the case of a request for specific locationType(s)
   and the "exact" attribute is false, the LIS MAY  
   provide additional location types, or it MAY provide alternative
   types if the request cannot be satisfied for a requested location
   type.  The "SHOULD"-strength requirements on this parameter for 
   specific location types are included to
   allow for soft-failover.  This enables a fixed client configuration
   that prefers a specific location type without causing location
   requests to fail when that location type is unavailable.  For
   example, a notebook computer could be configured to retrieve civic
   addresses, which is usually available from typical home or work
   situations.  However, when using a wireless modem, the LIS might be
   unable to provide a civic address and thus provides a geodetic
   address. 

   It should be noted that the protocol does not support a request to 
   just receive just one of a subset of location types. For example, 
   in the case where a Device has a preference for just "geodetic" or
   "civic", it is necessary to make 
   the request without an "exact" attribute, including both location
types.
   In this case, if neither is
   available a LIS SHOULD return a locationURI if available. 

   A location URI provided by the LIS is a reference to the most
   current available LI and is not a stable reference to a specific
   location.   The LIS SHOULD provide the locations in the
   response in the same order in which they were included in the
   "locationType" element in the request.

It might also be much nicer at this point to pull all that text for any:
(which grew based on feedback during WGLC) into it's own paragraph or
the end of the first (really just leaving that first sentence). 
[/MB2]



>

[...]
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art