Subject: [Geopriv] Review: draft-ietf-geopriv-http-location-delivery-01.txt

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Jul 2007 15:07:42 -0700

Draft: draft-ietf-geopriv-location-delivery-01.txt
Reviewer: Shida Schubert
Review Date: 2007.07.16

Technical Comments:
----------------------------------------
T1. Terminology: LCS
 - Does LCS really capable of determining the location 
   of the target device? I see it more as an entity 
   that knows about the location of the device and 
   able to deliver it to the device upon request. I 
   thought LCS is a subset of LS. Or is LCS an entity 
   that has characteristics of both LG/LS? If so may 
   be it's good to state that so people that are used 
   to GEOPRIV terminology can easily figure out what 
   LCS is responsible for and capable of.

T2. <retransmission-allowed> is "no"
 - I don't recall what the outcome of the debate we 
   had on whether the value of "retransmission-allowed" 
   applies to its usage in routing the call. 
 - If the outcome was so that it applies to its usage 
   in LoST, then I see the normative statement of it 
   default to "no" with SHALL strength problematic.

T3. Location URI
 >> Section 6.3, 2nd para, 2nd sentence
 - The draft seems to bind the location URI to be 
   referencing a LO in the LCS. I don't see this to 
   be true necessarily. It's possible that LCS is 
   non-accessible globally but LS which stores 
   the location for retrieval via reference is. I 
   think all you need to emphasize really is that 
   location URI is addressable globally.
   
T4. responseTime parameter
 >> Section 7.1
 - I feel that responseTime parameter will heavily 
   depend on the underlying protocol. If the value 
   is greater than the timeout value of the underlying 
   protocol it won't really work. May be some text 
   along the line which speaks about this should be 
   added?

T5. locationType parameter
 >> section 7.2
 - Although when "any" is requested all forms of LI 
   is to be provided with "SHOULD" strength, it contradicts
   this statement by the last statement in this paragraph
   "MAY alternatively or additionally return a location URI."
 - In terminology section you clearly states that LI covers 
   both by-reference and by-value.
 
T6. locationType parameter
 >> section 7.2 "locationURI"
 - Do we need a way to request what type of location information 
   is going to be available via locationURI? 
 - Do we need an ability to request a profile for geodetic location 
   type?

T7. locationType parameter
 >> Section 7.2 
 - What happens when multiple location types are requested all 
   of which are flagged with exact=true and LCS is able to 
   return some of the exact requested location type but not all?
 - I am assuming the request should still result in successful 
   response.
 - If not "cannnotProvideLiType" should specify which location 
   type it could not provide the response to.

T8. HTTP Bindings
 >> Section 8, 5th paragraph
 - I am confused, the paragraph talks about the use of TLS with 
   a "MUST" but it also talks about how HTTP without an S is supported.
   Am I missing something here?
 
T9. HTTP Bindings
 >> Section 8, 5th paragraph talks about how Device MUST fail a 
   request if server auth fails in case of an emergency, considering 
   we are envisioning the use of HELD at the boot-time, I don't know 
   how we the device will ever know if the location acquisition is 
   conducted at the emergency or not. I feel that some location is 
   better than nothing and device SHOULD not fail a request even 
   if server auth fails.

Clarifications Desired:
----------------------------------------
C1. Abstract: 3rd sentence
 - It's unclear what you are trying to deliver by the
   statement below. The location URI is not specified 
   anywhere, and it's unclear even when one knows 
   what location-URI that it is the only solution within 
   the document to support mobile/nomadic devices.

   "The protocol supports mobile and nomadic devices 
    through Location URIs."

   > I would remove the text from the abstract or 
     elaborate the text so it's more clear. 
   > Also I am aware of what location URI represents, 
     but is this term specified anywhere? If not I 
     recommend it be added in the terminology section 
     for those don't know the term. It's explanation 
     comes much later in the draft although its usage 
     is quite frequent until its definition is provided.

C2. Section 1: para 1, 3rd sentence.
 - service is not defined here? The provider of the 
   service is specified but not the service itself? 
   > Is location the service you are implying here?

C3. Overall: LS and LCS?
 - Reading the document, I had a hard time distinguishing 
   the difference between the LS and LCS. They seem to 
   represent the same logical entity. If so it may be good 
   to specify, if not may be explain where LS would fit 
   in the diagram in section 4. I am assuming logically 
   LCS and LS is different in a sense that LCS is a subset 
   of LS which gets LI from LG just like LS but provides LI
   only to the target that LI represents. Where LS can 
   provide LI to non-target. 

C4: Section 5, 2nd para, 1st sentence.
 - Can Device request LCS to create PIDF-LO? I am assuming 
   it can request PIDF-LO but not the creation of it? 

C5: LCS seems to take the role of LG and LCS, in which 
   case I think this should be clarified. 

C6: Location Request and Location Response
 - Section 6.2, 6.3 describes a bit about the messages 
   what's confusing is the literal purpose of the message 
   is also the name of the message, which I see to be a 
   benefit but can seem confusing when the following terms 
   are used interchangeably in the draft. The use of the 
   terms I feel should be consistent so it's used in the 
   proper context.
  
   "location request" 
    > Assuming you're referring to the request which 
      is asking for a location.
   "locationRequest"
    > Assuming you're referring to the XML element. 
   "location request message"
    > Same as below.
   "Location Request message"
    > The actual message used to request location that carries 
      "locationRequest" element and its values.

C7: HTTP response code
 - Section 9, 3rd paragraph
   "The HTTP status code SHOULD have the same
   first digit as any "locationResponse" or "error" body included"
   - I am assuming this text is just not fixed. I don't see any 
     code point in the "code" defined, so this makes no sense.

Editorial Comments:
----------------------------------------	
E1. Section 1: 2nd sentence.
 - LCP needs to be expanded. 
  FIX: LCP >> Location Configuration Protocol (LCP)

E2. Section 1: 2nd sentence. 
 - Too many such as
  FIX: such as such as >> such as 

 I hope it helps.

Thanks & Regards

--
Shida Sven Schubert           
[email-masked]	PHONE: (604) 762-5606 

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

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 17:07:01 -0500

Hi Shida,

Thanks for your detailed review.  Responses and a couple questions for
WG embedded below [MB].

Mary

-----Original Message-----
From: Shida Schubert [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 5:08 PM
To: [email-masked]
Cc: Barnes, Mary (RICH2:AR00); Winterbottom, James; Thomson, Martin;
[email-masked]
Subject: Review: draft-ietf-geopriv-http-location-delivery-01.txt

Technical Comments:
----------------------------------------
T1. Terminology: LCS
 - Does LCS really capable of determining the location 
   of the target device? I see it more as an entity 
   that knows about the location of the device and 
   able to deliver it to the device upon request. I 
   thought LCS is a subset of LS. Or is LCS an entity 
   that has characteristics of both LG/LS? If so may 
   be it's good to state that so people that are used 
   to GEOPRIV terminology can easily figure out what 
   LCS is responsible for and capable of.
[MB] The current definition is based on the one in the L7 LCP
requirements document (which was added after the -00 version of this
document), with some editorial liberties (splitting the 2nd sentence
into multiple sentences for clarity). 
I think the phrase "determines" is used liberally.  It's not entirely
clear to me the relation between LCS and LG/LS. An initial version of
this doc had the LG and LS as part of the LCS in Figure 1.  But, we
decided to remove all references to LG/LS from this doc, consistent with
L7 LCP requirements document. 
[/MB]

T2. <retransmission-allowed> is "no"
 - I don't recall what the outcome of the debate we 
   had on whether the value of "retransmission-allowed" 
   applies to its usage in routing the call. 
 - If the outcome was so that it applies to its usage 
   in LoST, then I see the normative statement of it 
   default to "no" with SHALL strength problematic.
[MB] Either way,  it's not clear to me why a "default" of no is a
problem?  That still certainly allows specific applications to set it
otherwise. [/MB]

T3. Location URI
 - The draft seems to bind the location URI to be 
   referencing a LO in the LCS. I don't see this to 
   be true necessarily. It's possible that LCS is 
   non-accessible globally but LS which stores 
   the location for retrieval via reference is. I 
   think all you need to emphasize really is that 
   location URI is addressable globally.
[MB]  I see your point.  It is stated earlier that the Location URI is
globally addressable.  The intent of this text is around ensuring the
privacy of the device/target, thus the need for the location URI that is
globally addressable not containing that does not contain an indentifer
that can be correlated with a specific user. [/MB]

 - I feel that responseTime parameter will heavily 
   depend on the underlying protocol. If the value 
   is greater than the timeout value of the underlying 
   protocol it won't really work. May be some text 
   along the line which speaks about this should be 
   added?
[MB] This relates to the current discussion of the responseTime in
general.  The conclusion of those dicussions should be able to address
your concern (i.e, adding some clarifying text) [/MB]

 - Although when "any" is requested all forms of LI 
   is to be provided with "SHOULD" strength, it contradicts
   this statement by the last statement in this paragraph
   "MAY alternatively or additionally return a location URI."
 - In terminology section you clearly states that LI covers 
   both by-reference and by-value.
[MB] That latter statement was added for clarification based on previous
feedback that the document wasn't entirely clear that LI covers both
by-reference and by-value:
http://www1.ietf.org/mail-archive/web/geopriv/current/msg03721.html
If others also feel that it confuses rather than clarifies, please let
me know. 
[/MB]
 
 - Do we need a way to request what type of location information 
   is going to be available via locationURI? 
 - Do we need an ability to request a profile for geodetic location 
   type?
[MB] IMHO, that would add unnecessary complexity, but welcome other
opinions.  [/MB]

 - What happens when multiple location types are requested all 
   of which are flagged with exact=true and LCS is able to 
   return some of the exact requested location type but not all?
 - I am assuming the request should still result in successful 
   response.
[MB] No. The current wording is that if all the locations cannot be
returned when exact=true, then the request is not successful. [/MB]

 - If not "cannnotProvideLiType" should specify which location 
   type it could not provide the response to.
[MB] This is related to the proposal to expand the response to include
the types of locations returned and not returned. I'll take this comment
as supporting the proposal. [/MB]

T8. HTTP Bindings
 - I am confused, the paragraph talks about the use of TLS with 
   a "MUST" but it also talks about how HTTP without an S is supported.
   Am I missing something here?
[MB] No. I just think the HTTP usage is general.  We can change it if it
seems problematic or confusing. [/MB]
 
T9. HTTP Bindings
   request if server auth fails in case of an emergency, considering 
   we are envisioning the use of HELD at the boot-time, I don't know 
   how we the device will ever know if the location acquisition is 
   conducted at the emergency or not. I feel that some location is 
   better than nothing and device SHOULD not fail a request even 
   if server auth fails.
[MB] I didn't think the use of HELD was restricted to boot-time, so that
there might still be cases where it might be known (although, I honestly
haven't followed the emergency work closely enough to know whether this
is actually true).  Anyone else have a better view here?  [/MB]

Clarifications Desired:

     but is this term specified anywhere? If not I 
     recommend it be added in the terminology section 
     for those don't know the term. It's explanation 
     comes much later in the draft although its usage 
     is quite frequent until its definition is provided.
[MB] I think that's a good point.  I'll make that change unless someone
has more detail we can add. [/MB]

   > Is location the service you are implying here?
[MB]  This should be "server" rather than "service". [/MB]

C3. Overall: LS and LCS?
[MB] Per responses to Barbara, the LS term will be removed as this doc
will talk only about LCS, per the L7 LCP requirements doc. [/MB]

C4: Section 5, 2nd para, 1st sentence.
 - Can Device request LCS to create PIDF-LO? I am assuming 
   it can request PIDF-LO but not the creation of it? 
[MB] The device requests the PIDF-LO, but not explicit request the
creation of one from the protocol perspective.  [/MB]

C5: LCS seems to take the role of LG and LCS, in which 
   case I think this should be clarified. 
[MB] Per response to Barbara, terminology will be clarified and use of
LG removed.[/MB] 

   "location request" 

[MB] Since those sections are intended to describe the functionality of
the messages themselves, I'll qualify the phrase "location
request/response" with "message" to be explicit. [/MB]

C7: HTTP response code
[MB] Yep. This is a leftover from the previous version. [/MB]

Editorial Comments:
[MB] Agreed. 

[MB] Agreed. 

 I hope it helps.

Thanks & Regards

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 23 Jul 2007 17:27:49 -0500

The question about what an LCS (or my preferred term LIS - which is
widely used and understood outside the IETF... and can also be
pronounced) is relative to an LS (or LG) has come up a few times.

My view has been that the object model has the LCS being decomposed into
the LS and one or more LGs. The LS does the client interaction and the
LG(s) responsibility is the network specific location generation work.

I suppose from that perspective, the HELD spec can really just talk
about LS - since it's specifically the server function that is being
discussed. However, it is also correct to talk about the LCS (or LIS, as
I'd prefer) in this context since it's just referring to the aggregate
function.

AFAIK, we have not specified an LS-LG interface, though I'd suggest that
HELD with client identity extensions can quite happily fulfil this role.
This would permit centralised LS supporting multiple remote LGs.

Cheers,
Martin

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: Tuesday, 24 July 2007 8:07 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Thomson, Martin
Subject: [Geopriv] RE:
Review:draft-ietf-geopriv-http-location-delivery-01.txt

Hi Shida,

Mary

-----Original Message-----
From: Shida Schubert [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2007 5:08 PM
To: [email-masked]
Cc: Barnes, Mary (RICH2:AR00); Winterbottom, James; Thomson, Martin;

Technical Comments:

T3. Location URI

 

T8. HTTP Bindings
 
T9. HTTP Bindings

Clarifications Desired:

C3. Overall: LS and LCS?

  
   "location request" 

C7: HTTP response code

Editorial Comments:

 I hope it helps.

Thanks & Regards

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Shida Schubert <[email-masked]>
Date: Mon, 23 Jul 2007 16:44:59 -0700

Richard,

 Thanks for going through my long, oddly formatted comments.
You will find my comments inline..
> problem?  That still certainly allows specific applications to set it
 I think the debate was whether "retransmission-allowed" set to no
implies that target location can't be used for LoST query. If the 
outcome of the
debate was in fact, "YES you can't use location information with
retransmission-allowed set to no for LoST query" then, unless the 
location information
derived from HELD is not intended to be used in emergency call, you 
should have the
default to say "yes". Otherwise I guess phone-BCP should state what 
value should be
set in case of emergency.

 Does anybody remember what the outcome of the debate was?

> your concern (i.e, adding some clarifying text) [/MB]
 Okay.
> [MB] IMHO, that would add unnecessary complexity, but welcome other
 I don't have a strong opinion on this.
> as supporting the proposal. [/MB]
 Sounds good. I think that would be good.
 Client can simply only ask for location type that was indicated as 
"Supported/Returned"
> seems problematic or confusing. [/MB]
 It's okay. It just seemed inconsistent with what the draft starts of 
saying is supported(HTTP/HTTPS) and
what normative text says(HTTPS only)..
> is actually true).  Anyone else have a better view here?  [/MB]
 Sorry, my comment wasn't very clear here.
  > I understand HELD is not used only at the boot-time, never the less
     if the server auth fails it is saying that location-acquisition is 
not possible. I think
     since the draft claims the mandatory support of HTTP/HTTPS, the 
fail-over to
     HTTP should be possible in this case, location acquisition due to 
TLS failure
     shouldn't stop UA from obtaining a location to complete an 
emergency call.

  > I understand the emergency is not the only use-cases, and may be 
this draft
     is not the right place to specify what needs be done in case of 
emergency.
     May be some text is needed in phoneBCP.
  
 Regards
  Shida

---

From: "Richard Barnes" <[email-masked]>
Date: Mon, 23 Jul 2007 20:03:15 -0500

For the record, Mary and I are *not* related (as far as I know).
--Richard