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

["Mary Barnes" <[e-mail]>]

Yes, I do need to revise the document based on Ben's review and what we
finally agreed. However, I was waiting to make those changes, as I had
assumed there would be a security directorate review coming in.  And, I
see your other email on that right now. So, should I wait for the sec
review?  

Mary. 

-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
Sent: Friday, May 23, 2008 9:46 PM
To: Barnes, Mary (RICH2:AR00)
Cc: General Area Review Team; Robert Sparks; Ben Campbell; Jon Peterson;
James Winterbottom; Martin Thomson; Barbara Stark
Subject: Re: Gen-ART LC review of
draft-ietf-geopriv-http-location-delivery-07


I have not gone through all these in detail but it sounds like we
probably need a slightly revised draft? If folks agree on that, would it
be possible to get that out by  next Wednesday? If we miss that, it will
likely need to slide out to the following IESG call.

Thanks, Cullen

On May 16, 2008, at 12:58 PM, Ben Campbell wrote:

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