Subject: [Geopriv] Some more HELD comments

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 24 Mar 2008 14:34:58 -0400

I've carefully read the document again.  I think it could be sent
onward.  I do think it could be improved somewhat.  Please understand
that I would have no reservations about progressing the document with
NONE of these suggestions implemented.  Every time you read a document,
new things spring out at you.  These are just polishing the apple.

Section 4
   The HELD protocol facilitates retrieval of location directly in the
   form of a PIDF-LO document (by value) and indirectly as a Location
   URI (by reference).  The policy that describes to whom, and how, LI
   is granted is outside the scope of this document and may be specified
   in separate specifications as required.

This wording seems to me to invite controversy, since no such document
is referenced.  Would it not be better to say that HELD is an LCP, and
thus the device is acquiring its own location, and thus the security
implications are minor (with maybe a reference to the security of HELD
itself)?  The term "LI is granted", specifically, doesn't clearly imply
who is granting LI - the LIS or the device.  I read it as the LIS.

   For the HELD protocol requests, the LIS uses the source IP address of
   the request sent from the Device as the identifier in determining the
   location of the device.  The use of additional identifiers for the
   HELD protocol is outside the scope of this document.

This is awkward wording for a topic that has a long history.  If you
didn't know it, it just reads weird (why do I say use IP address and
then say other identifiers are out of scope?).  Suggest:

  The LIS must identify which device in order to reply with the 
  appropriate LI.  For that, it needs an identifier.    This document 
  defines the use of the IP address of the device as the identifier.  
  Other identifiers are possible, but are beyond the scope of this 
  document.

A real nit, but you probably should move the text in the end of the
second paragraph of 5.2 into the appropriate sections of 5.3 and 5.4, or
5.3 should talk about errors.  I'd prefer, since the text is short
enough, that you just delete the sentence in 5.2, add the word
"successful" in the first sentence of 5.3 and be done.

The formatting in table 1 is unfortunate.  Perhaps you could force the
code and message lines to be two lines

Could you consider rewriting 6.1 as follows:
   The "responseTime" attribute MAY be included in a location request
   message.  The "responseTime" attribute includes a time value
   indicating to the LIS how long the Device is prepared to wait for a
   response.  The time value in the "responseTime" attribute is normally
   expressed as a non-negative integer in units of milliseconds.    
   
   In some circumstances, the requestor doesn't have a good value of
   responseTime, but can tell the LIS why it wants location.  
   In the case of emergency calls, the purpose of obtaining the LI
   could be either for routing a call to the appropriate PSAP or
   indicating the location to which responders should be dispatched.
   The protocol defines a mechanism for specifying a purpose instead of
   time in milliseconds and defines some values.  The values defined 
   for emergency calls, emergencyRouting and emergencyDispatch, 
   will likely be governed by jurisdictional policies, and should be 
   configurable on the LIS.

   The time value is indicative only and the LIS is under no obligation 
   to strictly adhere to the time limit implied; any enforcement of 
   the time limit is left to the requesting Device.  The LIS should 
   provide the most accurate LI that can be determined within the 
   specified time.

In 6.2, could we consider adding a line in the "any" description:
"If the LIS believes that the target is mobile, that is, its location
may change over relatively short periods of time (several minutes), it
SHOULD return a URI."

The LIS ought to know if the device is mobile.  

In 6.5.2 do you think it would be valuable to say 'The "expires"
parameter does not define the length of time a location received by
dereferencing the URI will be valid; it defines the time the URI itself
is valid."

I was confused by the text in 6.6 that describes how values for
retransmission-allowed and retention-expiry are constructed.  I would
have thought that a LIS could reasonably implement the rule-maker's
preferences.  The text implies it cannot; it must retransmission-allowed
to no, and must set retention-expiry to 24 hours.  If this was not the
intention, we need some clarifying text "In the absence of explicit
rule-maker instructions..."

Just a suggestion: to move the document forward before the arguing about
HELD vs HTTP schemes is finished, you could just delete section 8 & 12.5
with no loss of functionality in HELD as an LCP, and add it to the
dereference draft, where you really use it.

In 10.1, shouldn't you add a new step between 2 and 3 "3. The LIS must
be able to identify the device by its identifier (IP Address)."  Adding
that would require minor tweaking of the following paragraph.

Again, I don't think any of these suggestions are important enough to
hold off progressing the document.

Brian
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 24 Mar 2008 16:45:21 -0500

Brian,

Thanks for your detailed review. My responses are embedded below [MB].

Mary.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Rosen, Brian
Sent: Monday, March 24, 2008 1:35 PM
To: [email-masked]
Subject: [Geopriv] Some more HELD comments

Section 4

[MB] I see your point (this is day one text) and given this text is in
the protocol overview section, with the previous Intro and Overview and
Scope sections providing appropriate background material, I would
suggest rewording that paragraph as follows:
   A device uses the HELD protocol to retrieve its location either
directly in the 
   form of a PIDF-LO document (by value) and indirectly as a Location
URI (by reference).  
   The security necessary to ensure the accuracy, privacy and
confidentiality of the 
   device's location is described in the Security Considerations
(section 10). 
[/MB]

[MB] I guess I've read the weird text too many times to see the lack of
clarity that you're seeing. The wording has evolved based on continued
working group feedback.  The wording you suggest is similar to what we
had in the -02:
  "With this approach, the LIS needs to uniquely identify the Device
within the access network.  
   The source IP address of the request message is sufficient in most
cases.  Once the Device   
   is identified, the LIS uses network domain-specific information to
determine the location of 
   the Device."
Then in the -03, we moved that text into the overview and scope section,
reworded as follows:
       "The HELD protocol uses the IP address of the Device as an
identifier  
       in determining the location of the device.  This identifier is  
       revealed to the LIS through the source address in requests sent
by  
       the Device.  The use of additional identifiers for the HELD
protocol  
       is outside the scope of this document."
and then in the -04 we moved it back into this protocol overview section
reworded as (based on the feedback to combine the first two sentences):
       "The LIS uses the source IP address of the request sent from the
Device as  
       the identifier in determining the location of the device.  The
use of  
       additional identifiers for the HELD protocol is outside the scope
of  
       this document."
And what's there now was based on feedback that the text needed to be
split into multiple paragraphs. 

I do agree with your rewording for the last sentence and maybe this
comprise will work for that first sentence in order to capture past
concerns that have been raised:
  The LIS requires an identifier for the device in order to determine
the 
  appropriate location to include in the location response message.   
  In this document, the IP address of the device, as reflected by the
source IP 
  address in the location request message, is used as the identifier.  
  Other identifiers are possible, but are beyond the scope of this
  document.
[/MB]

[MB] Yep. I'll do that.  [/MB]

The formatting in table 1 is unfortunate.  Perhaps you could force the
code and message lines to be two lines
[MB] I'll try to do that. [/MB]

[MB] Cullen also had comments on this section in terms of finding the
appropriate text for the purpose, so I do agree, we may need some
clarification, I'm concerned that having the first paragraph as you've
suggested might lead some folks to not read the subsequent paragraph
(you know the idea that if a concept isn't in the first or last
paragraphs, it's missed).  Also, I have a concern with the beginning of
the second paragraph as it reads as if there might be circumstances
beyond emergency services where one might specify purposes. As the
protocol is defined right now, the purpose is not extensible. So, I
would prefer to be explicit that the only case we're discussing is
emergency services.  I'm also concerned as the new text doesn't include
what the LIS should do if there is no responseTime attribute. Basically,
you've removed all the concepts that were in the old last paragraph or
are you suggesting there is no change at all to that last paragraph? 

So, at a minimum, I would go ahead and split the first paragraph into
two, leaving all the details for the purposes to its own paragraph,
similar to your suggestion:

   The "responseTime" attribute MAY be included in a location request
   message.  The "responseTime" attribute contains either a time value
   indicating to the LIS how long the Device is prepared to wait for a
   response or a purpose for which the Device needs the location.

   In the case of emergency services, the purpose for obtaining the LI
   could be either for routing a call to the appropriate PSAP or
   indicating the location to which responders should be dispatched.
   The values defined for the purpose, "emergencyRouting" and
   "emergencyDispatch", will likely be governed by jurisdictional
   policies, and should be configurable on the LIS.

[/MB]

The LIS ought to know if the device is mobile.  
[MB] Okay, I will add that sentence just before the last sentence for
the "any" description, unless someone has a strong disagreement. [/MB]

In 6.5.2 do you think it would be valuable to say 'The "expires"
parameter does not define the length of time a location received by
dereferencing the URI will be valid; it defines the time the URI itself
is valid."
[MB] Good point. I will add that clarification. [/MB]

I was confused by the text in 6.6 that describes how values for
retransmission-allowed and retention-expiry are constructed.  I would
have thought that a LIS could reasonably implement the rule-maker's
preferences.  The text implies it cannot; it must retransmission-allowed
to no, and must set retention-expiry to 24 hours.  If this was not the
intention, we need some clarifying text "In the absence of explicit
rule-maker instructions..."
[MB] Per James W.'s comments, I was going to delete this text, so
hopefully that will avoid confusion in this document and just have the
reference to GEOPRIV PIDF-LO Usage Clarification, Considerations and
Recommendations document (draft-ietf-geopriv-pidf-lo-profile).  [/MB]

Just a suggestion: to move the document forward before the arguing about
HELD vs HTTP schemes is finished, you could just delete section 8 & 12.5
with no loss of functionality in HELD as an LCP, and add it to the
dereference draft, where you really use it.
[MB] I'm hoping that the debate was concluded at IETF-70 and that by
defining the schema as helds, Eric's concerns are addressed.  I do agree
that we could move the registration to the dereference draft (or it's
own document), but at this point I'm hoping that the issue is
resolved.[/MB]

In 10.1, shouldn't you add a new step between 2 and 3 "3. The LIS must
be able to identify the device by its identifier (IP Address)."  Adding
that would require minor tweaking of the following paragraph.
[MB] Is this really an "accuracy" issue or is a Privacy and
Confidentiality issue (per section 10.2)? [/MB]

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 28 Mar 2008 11:25:54 -0400

>Confidentiality issue (per section 10.2)? [/MB]

I think it's both.  To get the right location, you need the right
identifier.  That's why it belongs in 10.1.  If a VPN gave you the wrong
identifier, you get the wrong location.

It's also a privacy issue because if you can spoof an IP address, you can
get some one else's location.