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

From: Brian Rosen ^lt;>
Date: Mon Oct 01 2007 - 10:49:11 EDT

> 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]
I read it as ResponseTime as set to a very large number, not zero. I think
the best answer is that the text should say it's implementation dependent,
but if that is not acceptable, it should say it's treated as ResponseTime is
zero or large.


> 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?
I think this is not a good idea. The user asked for something specific; you
give it to him. If anything, you might make exact="false" say that what is
returned must be suitable for emergency calls.

I do recognize that there is the problem that if you specify locationType,
get it, and then try and use it for emergency call, it will fail. The
suggestion above (exact="false") is a way to avoid the problem. It may be
worth having a warning if you set exact="true" and specify a locationType
not supported by the local emergency call service.

> 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.
If you use the distinguished values in ResponseTime, the only error you can
get is cannotProvideLiType; you can't get the timeout error. I think it is
proper that you get the cannotProvideLiType.

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

The document should specify MUST IMPLEMENT. See RFC3261 for an example:
   Proxy servers, redirect servers, and registrars MUST implement TLS,
   and MUST support both mutual and one-way authentication.

Geopriv mailing list
Received on Mon, 1 Oct 2007 10:49:11 -0400

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