[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit