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

From: g.caron@bell.ca
Date: Mon Oct 01 2007 - 10:01:57 EDT

Thanks Mary.

See some replies inserted below.

Guy Caron
-----Message d'origine-----
De : Mary Barnes [mailto:mary.barnes@nortel.com]
Envoyé : 29 septembre 2007 16:38
À : Caron, Guy (A162859); geopriv@ietf.org
Objet : RE: [Geopriv] GC Comments on draft-ietf-geopriv-http-location-delivery-01.txt

Hi Guy,

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

Thanks,
Mary.

-----Original Message-----
From: g.caron@bell.ca [mailto:g.caron@bell.ca]
Sent: Tuesday, July 24, 2007 3:20 PM
To: Barnes, Mary (RICH2:AR00); geopriv@ietf.org
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]
 
[GC] I'm fine with the new text. Thanks.

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]
[GC] Conclusion on responseTime was reached after those comments were provided. Point taken though. While is may fall outside the topic of this thread, I wonder how UAs will learn what the application may require. For ES, interpreting the dialstring may be the approach but for pizza delivery how would that work?

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]
[GC] I've reread section 6.2.1 on the "exact" attribute and did not find anything that equates to this. Here is an example usecase I was trying to cover: UA requests locationtType= "geodetic" and exact="true" but the local ES jurisdiction supports only civic. In this case, I would like the LIS to supply civic anyway. Of course, if the expected behaviour of the UA when those return codes are received is to retry with more relax rules then, my concerns disappear. Where this should be specified?

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

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]
[GC] Well, if I got this right, the consensus was around providing an ES-specific "svc" tag in the responseTime parameter of the locationRequest. If the timeout and cannotProvideLiType error codes can still apply with the tag then, I think my concern still stands.

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]
[GC] This comment was provided in conjunction with the proposed caveat to in comment c5 which is indeed around the use of the "exact" attribute. I agree though that if the "exact" attribute fails to return an LI, requesting all types should do it too especially since the distinction of civic formats has disappeared.

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]
[GC] RFC2119 does not define "MUST implement" so, I'm not sure what it implies exactly.

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

That's it.

Best regards!

Guy Caron

-----Message d'origine-----
De : Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Envoyé : 12 juillet 2007 13:17 À : i-d-announce@ietf.org Cc : geopriv@ietf.org 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 i-d-announce-request@ietf.org 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:
        mailserv@ietf.org.
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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Mon, 1 Oct 2007 10:01:57 -0400

This archive was generated by hypermail 2.1.8 : Mon Oct 01 2007 - 10:02:10 EDT