Subject: [Ecrit] FW: Review Request for Rough Location Document

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 11 Jan 2010 10:56:56 +0200

Henning did a detailed review of the rough location document. 

Thanks, Henning!

Ciao
Hannes

PS: I removed the scanned document with Henning's mark-up (because of
size restrictions on this mailing list). 

>-----Original Message-----
>From: ext Henning Schulzrinne [mailto:[email-masked]] 
>Sent: 10 January, 2010 04:47
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]; [email-masked]; Stark, Barbara; ext 
>Richard Barnes; Roger Marshall; Marc Linsner
>Subject: Re: Review Request for Rough Location Document
>
>Hannes,
>
>I've done a quick pass though the document. Judging from the 
>assortment of typos still left, the number of people who have 
>read this document seems very small :-)
>
>I'm including my usual red-pen mark-up. Please let me know if 
>you cannot read the mark-up. Some general stylistic and 
>technical remarks, in no	 particular order:
>
>- The highly-parenthetical style makes reading tedious. 
>Consider rewriting sentences to flow more naturally, with more 
>conjunctions and "glue".
>
>- It's mentioned in passing, but I think it should be 
>emphasized that the rough location returned can be either a 
>single point or some other area (polygon). The document 
>sometimes seems to assume one, sometimes the other, and it 
>isn't always clear where the distinction matters.
>
>- I was unable to understand the civic location description. 
>Consider rewriting the section, and at least providing an example.
>
>- The privacy motivation in the introduction seems 
>disingenuous. We all know that the primary motivation is 
>business, not privacy. I can kind of follow the privacy issue 
>discussion in the security considerations, although I would 
>reorganize the description by starting with the problem of 
>identifier trustworthiness. I think it would be more honest to 
>have the e.g., in the introduction refer to business reasons 
>or at least provide a reference to the security considerations 
>section for an explanation, since not providing location to 
>the device itself for privacy reasons is rather 
>counter-intuitive, given that most privacy laws stipulate 
>access to your own information as a fundamental tenet of good 
>privacy practices.
>
>- Out-of-area PSAPs may well need access to precise location 
>information if they serve as backup PSAPs. This is the common 
>model, e.g., for statewide emergencies.
>
>- I found Section 3.1 et seq. very hard to follow. I don't 
>think adding more text helps - it would likely just add 
>confusion. If I understand the concept correctly, the 
>mechanism is relatively simple: You overlay all the service 
>areas for the different service URNs for the whole area served 
>by a location provider, as if you were drawing them all on a 
>single piece of paper, with the same color pen. Since the 
>service regions are polygons, these contiguous regions will 
>also be polygons. These regions have the property that all 
>points within the region return the same service URL for all 
>possible (emergency) service URNs.
>
>I'm not sure how this would translate to civic addresses.
>
>The figure (Fig. 1) is not helpful at all.
>
>In summary, I think this draft needs at least one more revision.
>
>Henning
>
>