Reading through the document I fail to see the clearly stated restriction that
this is not to be used between the emergency caller's UA and the VSP/ASP's
network (for VSP/ASP routed calls) or between the UA and the PSAP (for directly
routed calls).
I was in the believe that the scope is restricted only to PSAP-to-first
Responder, and PSAP-to-PSAP communication.
It might also be useful to add that this document did not make it through the
ECRIT working group. The document type is Standards Track and might give the
impression that there is wide consensus behind the document -- but there isn't.
IETF last calls may add a lot of value but I do not see that anyone had pointed
to the various discussions in the ECRIT mailing list on that topic.
I was always of the impression that the mechanism does not lead to any useful
outcome. See previous discussions:
Hannes: http://www.ietf.org/mail-archive/web/ecrit/current/msg05940.html
Henning: http://www.ietf.org/mail-archive/web/ecrit/current/msg05941.html
JamesW: http://www.ietf.org/mail-archive/web/ecrit/current/msg05945.html
For those who have not followed the work I would like to point out that we have
an "marking" (or call it indication) of an emergency call already, it is called
a Service URN - RFC 5031. How many times do we need to again identify that a
call (or a message) is an emergency call?
The document interestingly talks about closed networks or controlled
environments where this is supposed to be used. I don't believe it is useful to
do so because this leaves the door open to use the mechanism anywhere. Often,
these networks are not as closed as we think.
This new namespace can be included in SIP requests to provide an
explicit priority indication within controlled environments, such as
an IMS infrastructure or Emergency Services network (ESInet) where
misuse can be reduced to a minimum because these types of networks
have great controls in place.
Btw, what are these >>great<< controls?
My comments are addressed if the document (in the introduction) makes it clear
that UAs' MUST NOT include this RP namespace in an outgoing emergency call
because there is already the Service URN marking that classifies the call as an
emergency call.
We had already agreed on this a long time ago, see
http://www.ietf.org/mail-archive/web/ecrit/current/msg05960.html. Still, the
text in the introduction and in the security consideration is very fuzzy and in
my view intentionally does not make the case clear to leave it up to
interpretation.
It is ironic that this document manages to get finished before the major work
of the ECRIT group, namely PhoneBCP, and ECRIT framework, get completed. (Or
the SIPCORE SIP location conveyance for that matter as well.)
Why would someone want to go with their work through a working group when they
can get a Standards Track document faster and easier?
Ciao
Hannes
On Jun 16, 2011, at 12:26 AM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Registering a SIP Resource Priority Header Field Namespace for
Local Emergency Communications'
<draft-polk-local-emergency-rph-namespace-01.txt> as a Proposed
Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2011-07-13. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
This document creates the new Session Initiation Protocol (SIP)
Resource Priority header field namespace "esnet" for local emergency
usage to a public safety answering point (PSAP), between PSAPs, and
between a PSAP and first responders and their organizations, and
places this namespace in the IANA registry.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf