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

From: Mary Barnes ^lt;mary.barnes@nortel.com>
Date: Mon Jul 23 2007 - 18:07:01 EDT

Hi Shida,

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


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

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

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

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

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.
[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:
If others also feel that it confuses rather than clarifies, please let
me know.
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
[MB] IMHO, that would add unnecessary complexity, but welcome other
opinions. [/MB]

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
[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
>> 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?
[MB] No. I just think the HTTP usage is general. We can change it if it
seems problematic or confusing. [/MB]
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.
[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:
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.
[MB] I think that's a good point. I'll make that change unless someone
has more detail we can add. [/MB]

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?
[MB] This should be "server" rather than "service". [/MB]

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

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

[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
 - 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.
[MB] Yep. This is a leftover from the previous version. [/MB]

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

E2. Section 1: 2nd sentence.
 - Too many such as
  FIX: such as such as >> such as
[MB] Agreed.

 I hope it helps.

Thanks & Regards

Shida Sven Schubert           
shida@ntt-at.com	PHONE: (604) 762-5606 
Geopriv mailing list
Received on Mon, 23 Jul 2007 17:07:01 -0500

This archive was generated by hypermail 2.1.8 : Mon Jul 23 2007 - 18:07:19 EDT