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

From: Ben Campbell <[email-masked]>
Date: Tue, 6 May 2008 17:01:48 -0500

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

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?

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

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

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

Section 4.3.1: Should there be normative advice in this section?

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?

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?

6.5.2: Can you give any guidance about useful value ranges for  
"expires"? I assume very short expirations would not be useful.

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?

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?

-- Nits and Editorial Comments:

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.

Section 12.5: URI Scheme Syntax says "See section" with no section  
number.

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

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 9 May 2008 14:02:05 -0500

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:[email-masked]] 
Sent: Tuesday, May 06, 2008 5:02 PM
To: Barnes, Mary (RICH2:AR00); [email-masked];
[email-masked]; [email-masked]; 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).

Summary:

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]

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

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]

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

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.

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]

---

From: Ben Campbell <[email-masked]>
Date: Fri, 9 May 2008 15:34:57 -0500

Further comments inline:

Thanks!

Ben.

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

> reviewer

That helps, thanks.

> configured

In the context of how the LIS and ASP relate, I think your previous  
response solves the problem. I'm more concerned now about making sure  
the draft is precise on what the relationship between the LIS and the  
access network really needs to be, and what the network operator must  
do to make all this work safely. This really fits more into some of my  
later comments.

> the
> cause

That helps, thanks.

> that

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

> dereferencing

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.

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

> to

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?

>   does not understand, except the document element.

Thanks, that helps.

>  The "expires" parameter is RECOMMENDED not to exceed 24 hours.

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.

>    as a placeholder for the presence parameter in the schema."

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.

>  intended to limit the applicability of the HELD: URI to other  

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.

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

[...]

> a couple MAYs and the last paragraph explains the reason for the

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

[...]

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 14 May 2008 11:24:42 -0500

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:[email-masked]] 
Sent: Friday, May 09, 2008 3:35 PM
To: Barnes, Mary (RICH2:AR00)
Cc: General Area Review Team; Robert Sparks; Jon Peterson; Cullen
Jennings; [email-masked]; [email-masked];
Stark, Barbara
Subject: Re: Gen-ART LC review of
draft-ietf-geopriv-http-location-delivery-07

Further comments inline:

Thanks!

Ben.

> Comments:
----snipped by mary for [MB2] responses

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

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

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

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

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]

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

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

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

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

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]

[...]

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

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.

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

[...]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 14 May 2008 13:30:05 -0500

On May 14, 2008, at 11:24 AM, Mary Barnes wrote:

> does

Works for me.

>   [I-D.winterbottom-geopriv-location-deref].

Yes, that works.

> ignore

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.

> asserting
> little

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.

> just specify that it should be in 10s of minutes rather than a few.

I don't see a reason to change the granularity of the value-- 
suggesting a minimum of several minutes is fine, I think.

> explicitly use it per the examples. [/MB2]

Ah, maybe explaining that explicitly when you mention "XML schema  
constraints" would help.

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

> have",

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

> the end of the first (really just leaving that first sentence).

I almost wonder if some sort of table showing possible results for  
each combination of values might be useful here.

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 16 May 2008 14:40:56 -0500

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:[email-masked]] 
Sent: Wednesday, May 14, 2008 1:30 PM
To: Barnes, Mary (RICH2:AR00)
Cc: General Area Review Team; Robert Sparks; Jon Peterson; Cullen

On May 14, 2008, at 11:24 AM, Mary Barnes wrote:

> I've snipped the things with which we have agreement to keep the 
> thread a bit shorter.
>
> Mary.
>

> ----snipped by mary for [MB3] responses
>
>
>>
>>

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

> serve as a LIS and just tunnels those requests, many devices will get 

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]

> things. I've also added an additional statement about this point.

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)..."
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]

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

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

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

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

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 May 2008 14:58:52 -0500

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

> second

Okay.

> me
> type

Yes, sorry.

> something somewhere to say this?

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

>>> XML

Okay.

>>> relevant

Okay.

>   "civic" location or an error message.

I think that something to that effect could help.

Thanks!

Ben.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 23 May 2008 19:45:31 -0700

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:

>>>> can't do an either/or.  If you want either/or, then you may also  
>>>> get
>>>> a
>>>

---

From: "Mary Barnes" <[email-masked]>
Date: Sat, 24 May 2008 13:26:14 -0500

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:[email-masked]] 
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:

>>>> [email-masked]; [email-masked]; General 
>>>> Area Review Team
>>>> I have a few questions and comments that should be considered prior

>>>> Part of the issue is this text was carefully crafted as a result of

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

>>> 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.
>>>
>>> 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).
>>
>>>> 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?
>>>> 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 
>>> 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?
>>>

>> 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 
>> 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]
>
>>>> XML schema Section 7 for a location response message due to XML 
>>>> schema constraints."
>>>>
>>>> XML schema Section 7 for a location response message due to XML 
>>>> schema constraints related to the PIDF namespace.  Thus, the 
>>>> "##other"
>>>> namespace serves

>> schema Section 7 for a location response message, due to XML schema 
>> constraints (since PIDF is already defined and registered 
>> separately).
>>>> 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

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

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

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

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

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

>>>> 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.
>>>
>>> [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).
>>
>> 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 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
>>> 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.
>>>
>>> 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.
>>> (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]
>>
>> 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:
>>
>> advantage of specifying specific  locationTypes in the request is to 
>> ensure that one gets the available locations in a specific order,  
>> example, a location request for  "civic" could yield any of the 
>> following location types in the
>> response:
>>  - civic
>>  - civic, geodetic
>>  - civic, locationURI
>> only possible response is a  "civic" location or an error message.
>>
>> [/MB3]
>