Subject: RE: [Geopriv] GC Comments on draft-ietf-geopriv-http-location-delivery-01.txt

From: "Mary Barnes" <[email-masked]>
Date: Sat, 29 Sep 2007 15:37:56 -0500

Hi Guy,

Again, apologies for never having responded to these comments.   Responses are embedded below [MB].  

Thanks,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 24, 2007 3:20 PM
To: Barnes, Mary (RICH2:AR00); [email-masked]
Subject: RE: [Geopriv] GC Comments on draft-ietf-geopriv-http-location-delivery-01.txt

Hi Mary, Hi geopriv,

Please find below a few comments after reviewing this document. They are tagged as "Editorial" or "Technical".

>From a general point of view, I think the basic functions for location acquisition are well captured with this draft.

Since a lot of the comments have been provided already by other reviewers, my list is rather short.

Note well: My comments are influenced by the nature of my interests: Emergency services.

Section by section comments:

Abstract:
c1. <Editorial> The last sentence doesn't read right. Either add "the" before "session-layer" or an "s" at "layer". I would replace the semi-colon by a period after "layer".
[MB] Agreed. I'll break that into two sentences (i.e., replace the semi-colon). 

Section 7 - Protocol Paramaters
c2. <Technical> Table 1: The "expires" parameter should be labeled "conditional" instead of "mandatory" as it is only relevant in presence of the LocationURI parameter. If accepted, the term "conditional" should be added to the paragraph just above the table.
[MB] I'll just note that it is optional (I'm reluctant to add that "conditional" concept although it applies based on past experiences with tables that try to include too much info - there's one of those in SIP that always causes grief) and update the text appropriately (i.e., I think it's more important the text be accurate), so I'll add something like the following to section 6.5.1:
OLD:
   The "expires" attribute indicates the time at which the Location URI
   provided by the LIS will expire.  This attribute is included in the
   "locationResponse" message only.

NEW:
   The "expires" attribute is optional and is only included in a "locationResponse" message
   when a Location URI is included. The "expires" attribute indicates the time at which the 
   Location URI provided by the LIS will expire. 
[/MB]
 
Section 7.1 - "responseTime" Parameter
c3. <Editorial> 1st para., 1st sentence: Replace "attribute" by "parameter".
[MB] Okay.

c4. <Editorial> "If this parameter is absent, then the LCS MUST return the most precise LI it is capable of determining". I find this statement a bit confusing. Should I read this as, when the parameter is absent, the LCS will provide the most precise LI available at this very moment (not waiting for any LI computing at all) so possibly a coarse location? This is what I want but I'm not sure the text exactly says that (it may be completely the reverse actually).
[MB] If I've accurately interpreted the conclusion to the responseTime debate, it should be the "most precise at that point in time".  Is everyone okay with adding that clarification to the text? [/MB]

Section 7.2.1 - "exact" Attribute
My assumption here is that the device does not have prior knowledge of which application the LI will be eventually used for.
[MB] Again, based on my understanding of the conclusion/consensus to the responseTime debate, I think the device does have prior knowledge of which appliation the LI will be eventually used for (at least in the case of Emergency Services), per the addition of that service type to the responseTime. [/MB]

c5. <Technical> Should a statement be added to cover the following case: When only one specific LocationType is requested (exact=true), the LCS SHOULD return location information in THE form that is suited for routing and responding to an emergency call in its jurisdiction even if different than the one requested?
[MB] That's been done with the -02 changes. [/MB]

Alternatively, should a caveat be added to the use of this attribute stating it could impede the routing of emergency calls?

Section 7.3 - "code" Parameter
c6. <Editorial> 2nd par., 1st sentence: I suggest replacing "error" by "code". This would allow including "success" in the list of valid responses (success is not an error code).
[MB] Per the -02, the error processing has been separated from a normal response, thus "success" has been removed. [/MB]

The assumption for my comments in this section hereinafter is that all defined error codes will result in no LI being provided to the Device.

c7. <Technical> Should the timeout error code by accompanied with an "expected time" for a successful response?

What I would like to avoid is having a Device location-less when this information is required for emergency situations.
[MB] I'm hoping that the resolution to "responseTime" and having an indicator for emergency situations resolves this concern.  If not, please let us know. [/MB]

c8. <Technical> Considering comment #c5 above, would it be seen helpful to have the cannotProvideLiType error response by accompanied with a list of available LocationType(s)? At least, this would give a hint to the device as to what to do next.
[MB] I think this comment relates to a point of discussion in Chicago where we had been proposing to include a list of locationTypes included in a response.  There did not seem to be interest in doing that and if we were to do that, I think it would facilitate the functionality you're asking for. However, it would seem that this functionality is only useful in the case of "exact".  And, it's not clear to me, in that case, why  knowing what ones are available would be useful. It would seem that if that information is useful, then a device would just request all the types that it might be able to use and not use "exact". Or perhaps I'm missing your point altogether and we should discuss this one further?  [/MB]

Section 9 - HTTP Binding
c9. <Technical> "This binding MUST use TLS...".Shall I risk asking to soften this requirement a bit to a "RECOMMEND"? My motivation is that, under very specific implementation of trusted network nodes and private, secure network links, TLS may not be required. Consider an Enterprise running its LCS over its private LAN. Here is suggested wording: "This binding MUST use a secure mean of transporting data between the endpoint and the LCS. The use TLS is RECOMMENDED."
[MB] My understanding is that the MUST is a MUST implement and certainly doesn't preclude the situation you describe.  I don't have problem with the rewording you suggest, if that doesn't cause anyone else grief (i.e., I do think your suggestion captures the spirit of the MUST implement).   Although, the caveat is that my experience with the security sections (and this text being okay) might be dated (i.e., it's been a couple years since I got a doc approved with similar wording. [/MB]

Section 10.2 - Transaction Layer Security c10. <Technical> Same comment as #c9 above for the HTTP binding.
[MB] Ditto, my comment above.  I can make the proposed change, unless someone sees an issue. [/MB]

Section Appendix A - HELD Compliance to IETF LCP requirements c11. <Editorial> The whole appendix seems to refer to an older version of the LCP requirements document (prior to -02). The requirements' text should be updated.
[MB] This has been addressed in the -02. [/MB]

That's it.

Best regards!

Guy Caron

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] Envoyé : 12 juillet 2007 13:17 À : [email-masked] Cc : [email-masked] Objet : [Geopriv] I-DACTION:draft-ietf-geopriv-http-location-delivery-01.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

	Title		: HTTP Enabled Location Delivery (HELD)
	Author(s)	: M. Barnes
	Filename	: draft-ietf-geopriv-http-location-delivery-01.txt
	Pages		: 37
	Date		: 2007-7-12
	
A Layer 7 Location Configuration Protocol (L7 LCP) is described that
   is used for retrieving location information from a server within an
   access network.  The protocol includes options for retrieving
   location information either by-value or by-reference.  The protocol
   supports mobile and nomadic devices through Location URIs.  The
   protocol is an application-layer protocol that is independent of
   session-layer; an HTTP, web services binding is specified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt

To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-geopriv-http-location-delivery-01.txt".

A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-geopriv-http-location-delivery-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Sat, 29 Sep 2007 16:09:14 -0500

Inline.

Text sections not commented on have been trimmed

Cheers
James

> c3. <Editorial> 1st para., 1st sentence: Replace "attribute" by
[AJW] Technically attribute is correct.

> c4. <Editorial> "If this parameter is absent, then the LCS MUST return
the
> most precise LI it is capable of determining". I find this statement a
bit
> confusing. Should I read this as, when the parameter is absent, the
LCS
> will provide the most precise LI available at this very moment (not
> waiting for any LI computing at all) so possibly a coarse location?
This
> is what I want but I'm not sure the text exactly says that (it may be
> completely the reverse actually).
> [MB] If I've accurately interpreted the conclusion to the responseTime
> debate, it should be the "most precise at that point in time".  Is
> everyone okay with adding that clarification to the text? [/MB]

[AJW] That is not the intent no. The LIS will determine and provide the
most accurate location that it can, and that may require a wait.

> 
> Section 9 - HTTP Binding
> c9. <Technical> "This binding MUST use TLS...".Shall I risk asking to
> soften this requirement a bit to a "RECOMMEND"? My motivation is that,
> under very specific implementation of trusted network nodes and
private,
> secure network links, TLS may not be required. Consider an Enterprise
> running its LCS over its private LAN. Here is suggested wording: "This
> binding MUST use a secure mean of transporting data between the
endpoint
> and the LCS. The use TLS is RECOMMENDED."
> [MB] My understanding is that the MUST is a MUST implement and
certainly
> doesn't preclude the situation you describe.  I don't have problem
with
> the rewording you suggest, if that doesn't cause anyone else grief
(i.e.,
> I do think your suggestion captures the spirit of the MUST implement).
> Although, the caveat is that my experience with the security sections
(and
> this text being okay) might be dated (i.e., it's been a couple years
since
> I got a doc approved with similar wording. [/MB]
>
[AJW] I would prefer that we explicitly say MUST implement if we are
going to change wording here.

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