Re: [Ecrit] FW: Gen-ART LC review ofdraft-ietf-ecrit-location-hiding-req-01

["Hannes Tschofenig" <[e-mail]>]

Hi Ben, 

Thanks for your review. 

Please find some comments below:


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of Hannes Tschofenig
>Sent: 12 May, 2009 19:14
>To: 'ECRIT'
>Subject: [Ecrit] FW: Gen-ART LC review 
>ofdraft-ietf-ecrit-location-hiding-req-01
>
>FYI 
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On 
>Behalf Of 
>>Ben Campbell
>>Sent: 08 May, 2009 01:16
>>To: [e-mail]; [e-mail]; 
>>[e-mail]; [e-mail]; 
>>[e-mail]; General Area Review Team
>>Cc: Cullen Jennings; [e-mail]; [e-mail]
>>Subject: Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-01
>>
>>I have been selected as the General Area Review Team 
>(Gen-ART) reviewer 
>>for this draft (for background on Gen-ART, please see 
>>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>>
>>Please resolve these comments along with any other Last Call comments 
>>you may receive.
>>
>>Document: draft-ietf-ecrit-location-hiding-req-01
>>Reviewer: Ben Campbell
>>Review Date: 20090507
>>IETF LC End Date: 20090511
>>IESG Telechat date: (if known)
>>
>>Summary:
>>
>>This document is almost ready for publication as an informational RFC.
>>There are some minor clarity issues where the reader is left to infer 
>>some things that could be more explicit.
>>
>>Major issues:
>>
>>None
>>
>>
>>
>>Minor issues:
>>
>>-- 1.1, last paragraph:
>>
>>Can you expand on how withholding information information needed for 
>>call routing concretely differs from withholding information from 
>>emergency personnel? I assume there is more to this than the 
>intent of 
>>the ISP. Also, by saying an ISP is "not interested", I think 
>the point 
>>is to say that they have legal obligations to disclose to emergency 
>>personnel, regardless of any interest otherwise, right?

I updated the text. 

To answer your question: the regulator is the problem. They often do not
clearly describe how the responsibilities are shared. 
Not providing location info to the PSAP is typically a problem from a law
point of view. 

>>
>>-- 1.2, first paragraph:
>>
>>I think this leaves out what I assume to be the actual problem 
>>statement, which is we need a way that an ISP/IAP can hide location 
>>info from the user agent of the VSP in such a fashion that it 
>is still 
>>available for PSAP routing, correct? I can infer that pretty easily, 
>>but I don't see where it is explicitly stated in one place.
>>
>>Is there a case where an ISP is simply unable to provide location 
>>information? I assume that would be out of scope for this 
>document, but 
>>it should be stated as such.

I updated the text to make it more clear. 

Technically, there are challenges but none that cannot be addressed. 
Needless to say that the additional functionality costs money. The costs
vary when it comes to the accuracy requirements. This document does not talk
about accuracy requirements. 


>>
>>
>>
>>-- 1.3, fourth paragraph:
>>
>>This paragraph could be more clear--how does the PSAP having 
>>credentials meet a requirement to _hide_ information? I infer the 
>>assumption is that the caller does _not_ have the necessary 
>>credentials. If so, it would be better to state it explicitly


I extended the paragraph to make the credential story more concrete. 


>>
>>-- Fifth paragraph:
>>
>>is compatibility with LoST a requirement?

We use LoST as a mechanism to provide location based routing. 

I changed the wording of the text. 


>>
>>-- Req-B
>>
>>Is it appropriate for this document to put requirements on the ISP/ 
>>IAP? Or do you mean to say they MUST be _able_ to support this, while 
>>hiding information location from the VSP and/or UA?

A lot of the emergency services work relies on assumptions of what various
parties provide or do not provide. 

For this specific requirement the group thought it would be important that
the ISP/IAP allows either the end point or the VSP to do some form of
emergency call routing. 


>>
>>-- Req-C
>>
>>I don't really understand what is being said here. Is the 
>point to say 
>>that they must be able to validate that the URI identifies a "bona 
>>fide" emergency service contact, and that a call to that URI actually 
>>routes to the right place? How does this interact with the later 
>>requirement that the entities need not be SIP aware?
>>

Thanks for raising this issue. 

This requirement actually relates to a security threat we identified quite
early with the work in the ECRIT group. 
See Section 5.1 of http://www.ietf.org/rfc/rfc5069.txt. 



>>-- Req-D
>>
>>this is stated as a requirement on the ISP rather than a statement 
>>about the solution. I _think_ you are saying there is a 
>requirement to 
>>be _able_  to provide location info to the PSAP while withholding it 
>>from the caller. Is that correct?.
>>Also how does "by value or by reference" interact with the previous 
>>statement concerning LoST requiring LbyV?

I changed the wording based on your suggestion. 


>>
>>-- Req-5
>>
>>How does the requirement that the ISP/IAP not need to know 
>SIP interact 
>>with the statement in Req-D that the ISP must be able to 
>determine if a 
>>call is being routed to a bona-fide location service?
>>Also, does Req-5 imply a requirement to work with non-SIP VoIP 
>>services?

I changed the working to make it more clear:
"
The solution SHOULD work without the ISP/IAP having to support SIP and
without the need to utilize SIP between the endpoint and the VSP. 
"


>>
>>-- Req-6
>>
>>What does it mean for a PSAP boundary to have holes?

I added text and an informative reference to
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-specifying-holes-01.txt
. 


>>
>>-- Req 12:
>>
>>"Minimal impact" is vague--can you add clarifying text to make this 
>>more concrete?

During the discussions we noticed that some solutions would require
procedures that are totally different compared to the normal handling of
emergency calls when no location hiding is performed. 

I added some text. 

>>
>>-- Req 15: 
>>
>>Is that really a requirement, or just an observation of fact?
>>
Changed the wording. 



>>-- Security Considerations:
>>
>>I'm a little skeptical of this statement that this does not raise 
>>additional considerations. For example, would you consider 
>that a human 
>>might be endangered because an ISP wanted to reserve location 
>>information as a "for pay" service a security consideration, 
>in that it 
>>requires the solution to be more fail-safe than other 
>protocols? On the 
>>other hand, is the need to keep the UA from inferring 
>location when an 
>>ISP wants to hide it a security consideration?


I at least did not know what to write into the security consideration
section. 


>>
>>Nits/editorial comments:
>>
>>-- Abstract, paragraph 2:
>>
>>It's not clear to me that the document described 
>architectural impacts. 
>>It refers to architecture, but I don't see explicit statements about 
>>how the architecture breaks if the ISP is not willing to disclose.
>>

Fixed. 

>>-- 1.1, list item "3."
>>
>>Please expand VSP on first use.
>>

Fixed. 


>>-- Req-A:
>>
>>I don't think the requirement is to be able to withold location from 
>>"any entity it wishes", since that would include the PSAP, etc.

Fixed. 

>>
>>-- Req-2: "jurisdiction of the PSAP"
>>
>>Geographical jurisdiction?
>>
Fixed. 


>>-- Req-10:  The solution MUST allow the end host to determine PSAP/ 
>>ESRP URLs prior to the call, for all emergency services.
>>
>>Who is the "end host"?

The end host is the end point, such as a PC, laptop or a mobile phone. 

>>
>>-- 3.3, first bullet:
>>
>>Is it appropriate to have "MUST"s in a section on "desirable 
>>properties"?

Hmmm. Not sure. 

>>
>>-- Third bullet:
>>
>>That's an implementation detail. I think you mean to say something to 
>>the effect of the presence of NATs SHOULD not break the mechanism.


Fixed. 


Thanks again for your review comments. They helped to improve the quality of
the document.	


Here is the updated document: 
http://www.tschofenig.priv.at/svn/draft-schulzrinne-ecrit-location-hiding-re
quirements/draft-ietf-ecrit-location-hiding-req-02.txt

Ciao
Hannes

>>
>>
>>
>>
>>
>>
>>-- idnits reports the following (which I include without prejudice):
>>
>>idnits 2.11.11
>>
>>tmp/draft-ietf-ecrit-location-hiding-req-01.txt:
>>
>>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>>   http://trustee.ietf.org/license-info)
>>    
>>---------------------------------------------------------------
>>-------------
>>
>>   ** It looks like you're using RFC 3978 boilerplate.  You 
>>should update this
>>      to the boilerplate described in the IETF Trust License 
>>Policy document
>>      (see http://trustee.ietf.org/license-info) which is 
>>required from
>>      December 16, 2008.  Version 1.34 of xml2rfc can be used 
>>to produce
>>      documents with boilerplate according to the mentioned 
>>Trust License
>>      Policy document.
>>
>>   -- Found old boilerplate from RFC 3978 Section 5.1 on line 22.
>>
>>   -- Found old boilerplate from RFC 3978 Section 5.5 updated by RFC
>>4748 on
>>      line 377.
>>
>>   -- Found old boilerplate from RFC 3979 Section 5 paragraph 
>>1 on line 388.
>>
>>   -- Found old boilerplate from RFC 3979 Section 5 paragraph 
>>2 on line 395.
>>
>>   -- Found old boilerplate from RFC 3979 Section 5 paragraph 
>>3 on line 401.
>>
>>_______________________________________________
>>Ietf mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/ietf
>>
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ecrit
>