Subject: [Ecrit] draft-ietf-ecrit-rough-loc-01

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 21 Feb 2010 15:24:15 +0200

Hi Richard, Hi Matt, 

preparing the PROTO writeup I noticed the following issues with the
document: 

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

I would create the following structure: 

   3. The Need for Location
   4. The Location Filter Concept
   4.1. Introducing Location Filters
   4.2. Constructing Location Filters
        (including civic address considerations)
   4.3.  Maintaining Location Filters
   4.4.  Applying Location Filters

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. 

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. 

* Implementation:

Section 3.2 provides a pseudo-algorithm for the location filter concept.

Have you tried to implement the proposed mechanism to increase our
confidence? 

* License: 

  == You're using the IETF Trust Provisions' Section 6.b License Notice
from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

* References: 

I don't think that this reference is mandatory and hence putting it into
the informative section would be just fine:

   [4]   Wolf, K., "Location-to-Service Translation Protocol (LoST)
         Extension: ServiceListBoundary",
         draft-ietf-ecrit-lost-servicelistboundary-01 (work in
         progress), November 2009.

There are a few references out of date, such as:

   [7]   Schulzrinne, H., "Location-to-URL Mapping Architecture and
         Framework", draft-ietf-ecrit-mapping-arch-04
<http://tools.ietf.org/html/draft-ietf-ecrit-mapping-arch-04>  (work in
         progress), March 2009.

The reference section should also point to the requirements document. 

* A few comments on the content: 

"
   In
   addition, when that location is provided to the endpoint, the
   endpoint is able to verify that the location is correct (to the
   extent of the endpoint's knowledge of its own location) prior to an
   emergency call, and is able to perform emergency call routing
   functions on its own, providing redundancy for network-provided
   functions.
"

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

" 
       The location SHOULD be sufficiently precise that a LoST request
       with the location and any service URN will return a unique URI
       mapping value.
"

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.  

* Editorial: 

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

This will save the RFC editor time. 

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

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. 

"At the same time,
   because endpoints can roam between networks, it is not generally
   possible to have strong client authentication for LCPs.
"

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

-- invalid vs. valid
"
   With each service-to-URI mapping, a LoST query provides a service
   boundary that represents the set of locations in which that mapping
   is valid. 
"

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. 

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

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"

* Acknowledgements

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

Ciao
Hannes