Re: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-03.txt

["Richard L. Barnes" <[e-mail]>]

Hey all,

As promised in Maastricht, here's an update to rough-loc.  The diff  
looks kind of big and scary, but it's mostly just reformatting and  
clarification.  The changes in this draft were mainly in response to  
reviews by Hannes and Martin.  My responses to their comments are  
included below, with my comments in [RLB:...] brackets.

More review and comment would definitely be welcome, but I generally  
think this is getting pretty mature.

--Richard



===== Hannes Tschofenig =====

* Document structure:

I don't understand why "Location filtering" is a sub-section of
"Determining sufficient location precision". Section "Civic address
considerations" is the only sub-section and this typically does not look
good.

[RLB: Re-organized with the following structure:
    3.  Location Precision  
Requirements  . . . . . . . . . . . . . . .  5
    4.  Location  
Filtering . . . . . . . . . . . . . . . . . . . . . .  5
      4.1.  Filter Region for a Known  
Location . . . . . . . . . . . .  6
      4.2.  Constructing a Location  
Filter . . . . . . . . . . . . . .  8
      4.3.  Civic Address Considerations . . . . . . . . . . . . . . .  
11
      4.4.  Maintaining Location Filters . . . . . . . . . . . . . . .  
12
      4.5.  Applying Location Filters  . . . . . . . . . . . . . . . .  
12
]

I wonder whether is so clear to the reader why the LIS has to create the
location filter in a way that it has to consider all the emergency
services.

[RLB: Added a paragraph to clarify]


The description of the non-emergency services use case is a bit
confusing, I believe. We focused with our discussion on the emergency
services case.

[RLB: Revised this to bring it more in line with the new location- 
conveyance; see if it meets your concerns.]


Section 3.2 provides a pseudo-algorithm for the location filter concept.
Have you tried to implement the proposed mechanism to increase our
confidence?

[RLB: No, but it seems pretty straightforward.  Do you think it looks  
incorrect?]



* References:

[RLB: Following fixes:
-- -servicelistboundary from normative to informative
-- -mapping-arch replaced by RFC 5582
-- Added reference to draft-ietf-ecrit-location-hiding-req in  
introduction
]


I don't think we expect the human to check the location.
The advantage of having location information at the end host is to allow
him to
* learn about the available emergency service numbers available to that
specific region, and (as discussed more extensively end of last year) to
* route the emergency call directly to the PSAP (potentially without any
involvement of the VSP/ASP).

[RLB: Added a couple of sentences to the introduction clarifying this.]



You should better say "any emergency service URN" since non-emergency
service URNs may be treated entirely different. The same is true for
item 2 in your list.

[RLB: Done: s/service URN/emergency service URN/g]



* Editorial:

Please look at the subject headings and use capitalized characters.
Example: s/Location filtering/Location Filtering

[RLB: Done.]


s/"A filter
   can used to determine whether a location is usable for emergency call
   routing in the following way:"/"A filter
   can be used to determine whether a location is usable for emergency
call
   routing in the following way:"

[RLB: Done.]


Please replace the term "Target" with the term "Device" in the security
consideration section based on the discussions we had in the lo-sec
document.

[RLB: Done]


I would write "operationally difficult" rather than "not generally
possible".

[RLB: Done]


Don't talk about "valid" as there is a special semantic attached to that
word.

Instead, the response to the LoST query contains a <serviceBoundary>
element that can be used by the recipient as a hint to skip subsequent
queries for the same Service URN when the location falls within the
indicated service boundary.

[RLB: What semantic do you understand for "valid"?  I'm pretty sure  
that the usage here (i.e., "mapping is valid" == "PSAP information is  
correct for service URN location") is consistent with the usage in RFC  
5222 and RFC 5582.  See, e.g., Section 5.2 of 5222.  (Even if the  
<serviceBoundary> doesn't contain *all* possible locations, it is at  
least a set where the same mapping is valid, which is good enough for  
our purposes.) Keep in mind that this is separate from the *address*  
validation function in LoST, which deals addresses, not mappings.]


"
A consequence of this is that given a set of service
   boundaries for different services, the intersection of those service
   boundaries is the region in which two mappings are valid.
"

This sentence is a bit wrong. At least you shouldn't say "two mappings"
in the later part of the sentence when you start generically.

[RLB: Changed "two mappings" to "all of the corresponding mappings"]


s/"then the
   intersection is the are where both of these mappings are valid"/then
the
   intersection is the area where both of these mappings are valid"

[RLB: Done]


* Acknowledgements

Weren't there more reviewers? Not many people are listed.

[RLB: I added you and Martin :) ]


===== Martin Thomson =====

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

[RLB: That's in part because it depends a lot on the positioning  
mechanism.  If you've got a generic IP-geo table, for example, you  
could just compare the location values in the table against the filter  
regions and see if they fit.  (If so, you're good to go; otherwise,  
there's a possibility of routing errors.)  With a system that  
gradually converges, you could use the location filter as a trigger  
for when to terminate the process and return a value (when you're  
sufficiently within a filter region).  We tried to state this briefly  
with the phrase "These cases may arise when computing precise location  
is an expensive or time-consuming operation (e.g., in the case of  
wireless triangulation), and location is needed quickly", but we can  
add some more text to clarify if you think it's necessary.   
Suggestions welcome :) ]


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.

[RLB: Added a paragraph to the introduction to clarify]


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.

[RLB: Not clear what to do with this.  Suggested text?]


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

[RLB: Agreed; IIRC, there was some discussion of this during the  
development of LoST, but no real resolution.  Also agree that this  
document is not the right place to solve them.]


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.

[RLB: "Mask" doesn't seem right either, since you're not chopping off  
parts of the input location (as you would with, say, a bit mask).   
Maybe something like "partition"?]


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

[RLB: That's a really good idea. I've re-factored the requirements and  
filtering sections and added a quick section on single-point  
filtering. ]


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.

[RLB: It is implementable *iff* one has a mechanism for intersecting  
civic boundaries.  Which is jurisdiction-specific, as noted.]


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

[RLB: Added a paragraph discussing authorization, with a reference to  
draft-barnes-policy-uri as a way for clients to find out about  
authorization policy.  Changed "will generally" to "may" in the  
problem sentence.]


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.

[RLB: That's true, but all the fuzzing in this document is by  
reference to draft-ietf-geopriv-policy.  Do you think there's a need  
for text in this document?]


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>

[RLB: That is exactly what I intended.  Added text and an informative  
reference to the Terminology section]


Section 3 mentions two, but lists three.
s/course/coarse/ in one place
s/servuce/service/g

[RLB: Think these are fixed now]


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.

[RLB: Think these should be overcome by revised description of the  
algorithm]