Subject: [Ecrit] Review of draft-ietf-ecrit-phonebcp-02.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 28 Oct 2007 12:35:08 +0100

Hi Brian,

I read through the most recent phone BCP draft:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt

The document is getting close to WGLC, I believe. Thank you for working 
so hard on the draft update.

There are only a couple of editorial and terminology issues. In some 
other cases the usage of RFC 2119
language is not required since there is no protocol impact. I will 
provide these detailed comments to
you at the next week's emergency services workshop.

I also made a few comments on the framework document that have impact 
for this document as well.
For example, I noted that requirements like the following one are not 
really in the scope of our work:
"

   ED-10 Devices SHOULD NOT have one button emergency calling
   initiation.

"

A few selected technical issues:

   ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to
   civic) from the form of location the determination mechanism
   supplied.

You cannot put a "MUST NOT" requirement here since we need this translation 
in case we receive location information from DHCP and use it with 
SIP Location Conveyance. In some sense this contradicts requirement ED-39. 

   AN-4 Access networks supporting copper, fiber or other hard wired IP
   packet service SHOULD support location configuration.  If the network
   does not support location configuration, it MUST require every device
   that connects to the network to support end system measured location.

I am not sure what this sentence means but I thought we concluded that end hosts
have to support a range of location configuration protocols and networks have to 
at least support one of them. This sentence sounds different to me. 

   ED-19/SP-13 Where proxies provide location on behalf of endpoints,
   the proxy MUST provide a mechanism to supply emergency dial strings
   to the device if the device recognizes them, or the proxy MUST track
   the location of the device with sufficient accuracy and timeliness to
   be able to recognize the local dial string at the time of an
   emergency call.

The environments where proxies add location on behalf of the end points are 
exactly those where the proxy has a relationship to the access network. 
Hence, the proxy can also detect the visited emergency dial string. 

We NEVER EVER agreed that the proxy supplies emergency dial strings to the device. 
I know that there was once a draft about this subject and I saw this issue 
showing up in various presentations but we don't need it. 
As such, I suggest to delete this sentence rather quickly. 

   ED-25 Software which uses LCPs SHOULD locate and use the actual
   hardware network interface.

Not so sure what this should tell us.

   AN-15 Placement of NAT devices should consider the effect of the NAT
   on the LCP.

We have to consider this already for the design of the LCP.We don't need 
to repeat it here.

   ED-35 If a UA has more than one location available to it, it MUST
   choose one location to use to route the call towards the PSAP.

Shouldn't we just point to the PIDF-LO profile document?

   SP-20 Proxies handling emergency calls MUST insert a default location
   if the call does not contain a location.

Proxies should only add a default location if the they are unable to 
determine the location of the end point.
I would add this qualification.

   AN-23/SP-21 Default locations MUST be marked with method=Default and
   an appropriate provided-by in the PIDF-LO.

So far, there is no method field indicating "default" in
http://www.iana.org/assignments/method-tokens
We would have to add it.

   ED-40/AN-24 To prevent against spoofing of the DHCP server, elements
   implementing DHCP for location configuration SHOULD use [RFC3118].

Delete this since the DHCP document already says it. Additionally, 
you should consider that RFC 3118 is largely a theoretical aspect, 
i.e., not deployable. 

Delete the section about "uninitialized devices" per decision at the 
last IETF meeting.

9.1.  Use of TLS

I think you might want to capture some of the discussions we had around 
* TLS session resumption 
* TLS session resumption without server side state 
* TLS Ciphersuite usage to ensure proper performance

There is some repetition between Section 9.2 and Section 8 when it comes 
to the service URN usage.
Maybe there is room for simplification

Regarding ED-77:

   ED-77 In its response to the test, the PSAP MAY include a text body
   (text/plain) indicating the identity of the PSAP, the requested
   service, and the location reported with the call. 

I recall in one of the document reviews that someone spotted a security 
vulnerability, namely that an adversary would use emergency call test 
mechanisms to determine the location of someone else. 
Do you think that this could be a problem?  

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit