[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] Comments on draft-barnes-ecrit-rough-loc-02
Richard, Matt,
This is my review of draft-barnes-ecrit-rough-loc-02. I haven't really done a proper review of this document before. So, even though I've been aware of it and the general principle, this is my first proper review.
This document is well written and mostly clear and easily understandable.
There are some issues that mean that this document could use some additional work.
The introductory text in this document implies larger scope than is actually delivered. In many cases, statements are prefaced with "if precise location information is available" or similar, but no guidance is given where the location information is not "precise".
As the document is read, I infer that the goal of the document is to describe how to provide degraded location information without resulting in routing failures for emergency calling. I understand that there might be a desire to weasel around this issue, but it is better to clearly define the scope of the document up front.
I don't think that you can avoid discussion of where location information crosses a service boundary. In the context of a more limited scope, it could be significantly easier to manage.
(As an aside: In reading this document from the perspective of its advertised scope, I believe that there are shortcomings in LoST with respect to low quality input location. A single LoST server is able to provide multiple mappings, but it provides no means to distinguish them. Furthermore, it is unable to provide a redirect to multiple servers where an ambiguity spans regions covered by different servers. This has only a peripheral impact on this document - the procedures described in the document would effectively work around this limitation.)
I don't know that filter is the right word to use for what this document describes. Filter, to me, implies that the information is refined somehow, where the opposite is true. "Mask" might be a better fit.
(Almost editorial comment) On mechanism, I think that there are two methods that could be used here. The document describes a more complex mechanism that is employed ahead of time. There are obvious benefits to this approach, but it might also be viable to apply the method after deriving location information. From my perspective, describing the method from the perspective of the initial request would also flow better. You then describe the assembly of the wide area filter/mask as an optimisation. By all means characterise the optimisation as important or even necessary.
It's unclear to me how two regions defined using civic addresses can be intersected. For that matter, I'm not sure that I know how to express a civic address region succinctly, but that's a LoST problem. I don't think that the algorithm as described in 3.2.2 is implementable.
On discussion of emergency and non-emergency services, I think that one point needs to be made clearer up front. The location reference is provided so that authorized services can retrieve location information suitable to their needs. This document assumes that emergency services will always be authorized. That's probably an assumption worth stating.
Following up on non-emergency, there is a suggestion that there could be another protocol for discovering what the authorization policy is for a given location reference. I'd prefer to see that this be left unstated. In the cases we're talking about, this is probably something that goes with the standard terms of service agreement between provider and their customers; I see little point in implying that there is a need for a protocol for this interaction. Also remove the unprovable statement: "Non-emergency LBSs will generally require more precise information than is required for emergency call routing."
In the security section you talk about repeated randomization. That's the subject of a note in <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-02#section-4.4.1>. There is a trade-off between using a fixed offset, which might be revealed when the location changes, and a randomized offset, which might reveal the original area if repeated requests are made while the target is stationary.
Purely editorial
"precise" isn't a terrible word, but it might be prudent to make it clear what you are talking about. Where you talk about "precise enough" or "precise information", you are actually referring to location information that has a region of uncertainty that is entirely contained with a region of interest (the service boundary).
<http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty>
Section 3 mentions two, but lists three.
s/course/coarse/ in one place
s/servuce/service/g
Section 3.2.1 is quite difficult to read on the first pass. Yes, it is succinct and correct, but it does suffer a little from being a little too terse. URI and URN are easily confused, so might I suggest that each is prefaced accordingly to distinguish them: "mapped/resulting URI" and "service URN" might be easier to understand. Expanding the algorithm a little might help readability as well.
Also, you mention iteration through the set of URI tuples (hypen or no-hypen) but don't mention that you are computing the intersection of the service regions that correspond to each URI in the tuple. Initially, it was confusing because my natural inclination was to think of the URI and service region as the tuple.
--Martin
------------------------------------------------------------------------------------------------
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]