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

Date: Mon Oct 01 2007 - 13:01:06 EDT

Brian, see inline...

Guy Caron
-----Message d'origine-----
De : Brian Rosen []
Envoyé : 1 octobre 2007 10:49
À : Caron, Guy (A162859);;
Objet : RE: [Geopriv] GC Comments ondraft-ietf-geopriv-http-location-delivery-01.txt

> 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.
[GC] I don't think is should be left as "implementation dependent" if ubiquitous UA-to-LIS interoperability is a goal here. I think this spec should define exactly what the expected behaviour here is.


> 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.
[GC] This may be a way out if the setting of the "exact" attribute is always controlled by a human that understands what it does. Is it the assumption here?

> 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.
[GC] Fine. Maybe the spec should be clear on the non-applicability of the timeout code then. I agree that cannotProvideLiType should be returnable in this case but my concern still remains if no LI is provided in that case. Is it another case of trying with more relax rules here again? If so, let's say so.

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

[GC] If this means that not using TLS makes the implementation non-standard, then, I prefer "RECOMMENDS". If it means that the HELD-enabled LIS must at least support an implementation with HTTPS but could support HTTP as well, then I'm ok.

Geopriv mailing list
Received on Mon, 1 Oct 2007 13:01:06 -0400

This archive was generated by hypermail 2.1.8 : Mon Oct 01 2007 - 13:01:32 EDT