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

[Ben Campbell <[e-mail]>]

On May 16, 2008, at 2:40 PM, Mary Barnes wrote:

> Hi Ben,
>
> Just a few more comments embedded below [MB3], again snipping what I
> think we've agreed.
>
> Mary.
>
> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Wednesday, May 14, 2008 1:30 PM
> To: Barnes, Mary (RICH2:AR00)
> Cc: General Area Review Team; Robert Sparks; Jon Peterson; Cullen
> Jennings; [e-mail]; [e-mail];
> Stark, Barbara
> Subject: Re: Gen-ART LC review of
> draft-ietf-geopriv-http-location-delivery-07
>
>
> On May 14, 2008, at 11:24 AM, Mary Barnes wrote:
>
>> 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:[e-mail]]
>> Sent: Friday, May 09, 2008 3:35 PM
>> To: Barnes, Mary (RICH2:AR00)
>> Cc: General Area Review Team; Robert Sparks; Jon Peterson; Cullen
>> Jennings; [e-mail]; [e-mail];
>> 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:[e-mail]]
>>> Sent: Tuesday, May 06, 2008 5:02 PM
>>> To: Barnes, Mary (RICH2:AR00); [e-mail];
>>> [e-mail]; [e-mail]; 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 [MB3] responses
>>
>>
>>>
>>>
>>> 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).
>
> I think maybe the key point that needs more emphasis is that the  
> second
> paragraph is for situations where the device is not aware of the VPN
> being used.
>
> [MB3] So, I will add the following to the end of the second paragraph:
>   Otherwise, the other devices would be totally unaware that they
>   could receive inaccurate location information.
> [/MB3]

Okay.

>
>
>
>>
>>
>> [/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]
>
> On rereading that section and your proposed changes, it did not help  
> me
> with the answer to _this_ comment, that is, why are we overloading the
> type of location with the delivery mode. On reflection, though, I  
> think
> I may understand a piece of this, so see if this makes sense:
>
> An effect of sending location by value is that the actual location  
> type
> may not be determined until the time of dereference. That is, the LIS
> might only have a geodetic location available when it sends a URI, but
> by the time the location recipient dereferences the URI, it may only
> have a civic address. Does that make sense? Is there any expectation
> that any location type preferences (i.e. geodetic vs
> civic) expressed in the HELD query be honored at dereference time? I
> suppose the dereferencer could assert entirely different preferences.
>
> [MB3] I think you meant to say "An effect of sending location by
> reference...(rather than value)..."

Yes, sorry.

>
> But, other than that, what you say makes sense. At the time the  
> location
> URI is provided, there is not necessarily a binding to a specific
> location type. The specific location type is determined at the time of
> dereference. And, yes, the dereference protocol allows the  
> dereferencer
> to specify the type of location they prefer. The use of the location  
> URI
> as defined in this base HELD spec is totally independent of the  
> specific
> type of location it might reference. Do you think we need to add
> something somewhere to say this?
> [/MB3]

I think it could help others avoid the confusion that I had. I'm not  
sure this will be obvious to everyone.

>
>
>>
>>>
>>>
>>> 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]
>
> Ah, maybe explaining that explicitly when you mention "XML schema
> constraints" would help.
>
> [MB3] Okay, I'll change that text to the following rather than what I
> originally suggested:
> "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 (since PIDF is already defined and registered
> separately).
> Thus, the "##other" namespace serves
> as a placeholder for the presence parameter in the schema."
> [/MB3]

Okay.


>
>
>
>>
>>
>>>
>>>
>>>
>>>
>>> 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'm still a little confused, so let me ask some architectural
> questions that go beyond this draft. Apologies for not having studied
> the dereferencing draft:
>
> HELD identifies the device whose location is of interest by the source
> IP address of the request. This has the consequence that a device can
> only query for its own location. But I assume that device
> dereferencing lbyr is usually _not_ the principal device; that is,
> dereferencing is usually done by a third part. Does the dereferencing
> draft somehow extend HELD to allow for third party queries?
>
> [MB3] Yes, the dereference draft does extend HELD to allow for
> third-party queries, making use of the "other identifiers" deemed  
> out of
> scope for this document (there's yet another document that extends  
> HELD
> to use other identifiers).  So, other identifiers are outside the  
> scope
> of HELD as defined in this base document and the details of  
> dereference
> are outside the scope, even though the dereferencing does make use of
> the HELDS: URI defined in this document. So, maybe modifying the NEW
> text I suggested above might 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, but are necessarily restricted in scope
>   in this document to the use for the base HELD protocol.
> [/MB3]

Okay.

>
>
>
>>
>>
>>
>> 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).
>
> Ah, I'm not sure we are talking about the same language. My comment
> was entirely aimed at the language defining "any", not the general
> language following the list of values. (although I do think your
> proposal improves the general section.)
>
> [MB3] I think the problem was because we had tacked on additional
> normative text to the any: in the list, without necessarily  
> considering
> the text we had that was applicable to any in the lower paragraphs,  
> thus
> causing some inconsistencies. [/MB3]
>
>>
>> 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]
>
> I almost wonder if some sort of table showing possible results for
> each combination of values might be useful here.
>
> [MB3] I'm not sure a table would help due to the numerous possible
> combinations and the fact that the order also matters. Although, if  
> you
> think it's useful and illustrative, then we could add something like  
> the
> following:
>
>   In summary, when the "exact" attribute is not used, the only
> advantage of specifying specific
>   locationTypes in the request is to ensure that one gets the  
> available
> locations in a specific order,
>   since the LIS SHOULD return all the available location types. For
> example, a location request for
>   "civic" could yield any of the following location types in the
> response:
>   - civic
>   - civic, geodetic
>   - civic, locationURI
>   - civic, geodetic, locationURI
>   - civic, locationURI, geodetic
>   - geodetic, locationURI (only if civic not available)
>   - locationURI, geodetic (only if civic not available)
>   - geodetic (only if civic not available)
>   - locationURI (only if civic not available)
>
>   For the above example, if the "exact" attribute was true, then the
> only possible response is a
>   "civic" location or an error message.
>
> [/MB3]

I think that something to that effect could help.

Thanks!

Ben.


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