Subject: [Ecrit] Comments for draft-ietf-ecrit-phonebcp-00.txt

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Nov 2006 14:57:37 +0100

Hi all,

I went through the document and it looks good. I still have a few comments:

* In the introduction you point to the difference to ETS. Why is this 
necessary? Why don't you mention authority-to-citizen communication?

* I don't think that the message steps listed in the introduction are 
helpful unless you mention that this is just an example. Why don't you 
point to the framework document instead?

* Terminology section: You might want to state that the RFC 2119 
language refers to the implementation/usage at SIP end points and at SIP 
proxies and not to a protocol specification.

* Section 4 leaves the Geopriv L7 LCP as a place holder. I see this 
being a problem for finishing the document given that it might take some 
time to finish the Geopriv work on this subject. I don't have a good 
idea how to resolve it.

* The following sentence is repeated:
"
    For devices that operate on a network where the network operator
    controls the specification of every device connected to that network
    that could be used for emergency calls, the method by which location
    is determined need not be an IETF standard, but can be any method
    that achieves the desired result.
"
I suspect what you would like to say is that in an environment where a 
network operator cannot control all the end points you have to either 
support many protocols in the access network or at the end points.

* Could you explain this statement: "Self Reported location is generally 
unacceptable in emergency calls, ..."?

*  You write:
    "
     It is essential for the location to be
    determined BEFORE any VPN tunnels are established.
    "

It would be good to refer to tunnels with examples to VPN tunnels or 
mobility specific tunnels (e.g., MIP).

* Regarding the time limits indicated in Section 4, it would be good to 
provide references (if you know some of them).

* Please double-check the terminology used in Section 5 with the terms 
introduced in Section 3.6  of 
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-12.txt

* Please provide a reference regarding the following statement:
"
    Note: It is undesirable to have a single "button" emergency call user
    interface element.  These mechanisms have a very high false call
    rate.  PSAPs prefer devices to use their local emergency call
    dialstring.
"

* The following paragraph is still an open issue:
"
    [I-D.schulzrinne-sipping-service] introduces a universal emergency
    service URN scheme.  On the wire, emergency calls SHOULD include this
    type of URI as a Route header [RFC3261].  The scheme includes a
    single emergency URN (urn:service:sos) and responder specific ones
    (urn:service:sos.police).  Using the service:sos URN scheme,
    emergency calls can be recognized as such throughout the Internet.
"

* You write: "Devices MUST use the service:sos URN scheme to mark 
emergency calls."
In the next paragraph you also consider the case where end hosts does 
not understand emergency calls:

"
    To determine which calls are emergency calls, some entity needs to
    map a user entered dialstring into this URN scheme.  A user may
    "dial" 1-1-2, but the call would be sent to urn:service:sos.  This
    mapping is SHOULD performed at the endpoint device, but MAY be
    performed at an intermediate entity (such as a SIP proxy server).
"

The problem with the end host not understanding emergency calls should 
be highlighted. If the end host does not understand emergency calls (and 
thereby does not understand the service URN) the aspects listed in 
Section 6.5 are not relevant either.

* Section 6 is quite difficult to read. Wouldn't it be useful to cluster 
the description in three cases:
   1) End host obtains location information and performs the resolution 
to a PSAP URI
   2) End host obtains location information and the proxy performs the 
resolution to a PSAP URI
   3) The proxy obtains location information and performs the resolution 
to a PSAP URI

Additionally, it might be worth mentioning unauthenticated emergency 
calls. You briefly mention 'uninitialized devices' which already goes 
(conceptually) in this direction.

Ciao
Hannes

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