If you insist on that scope
I was in the believe that the scope is restricted only to PSAP-to-first
Responder, and PSAP-to-PSAP communication.
Then you can throw it away.
I certainly don't see it being used by an emergency calling UA, but in a 3GPP
like solution to emergency calling, there is no reason why it cannot be used by
the first network operator provided entity that identifies an emergency call. I
agree it is not applicable to the IETF solution, but then you have no network
operator to provide you with priority in the first place.
If a network operator want to provide priority in their equipment after point
of entry to the network, to an emergency call, then RPH is the sensible way of
doing it, and not forcing them to recognize multiple different parameters to
identify that priority is needed.
You seem to be back in cloud cuckoo land where you believe all emergency calls
are handled by the IETF ECRIT solution.
Keith
-----Original Message-----
From: ecrit-bounces(_at_)ietf(_dot_)org
[mailto:ecrit-bounces(_at_)ietf(_dot_)org] On Behalf Of
Hannes Tschofenig
Sent: 13 July 2011 10:21
To: ietf(_at_)ietf(_dot_)org IETF; ecrit(_at_)ietf(_dot_)org
Subject: Re: [Ecrit] Last Call: <draft-polk-local-emergency-rph-namespace-
01.txt> (IANA Registering a SIP Resource Priority Header Field Namespace
for Local Emergency Communications) to Proposed Standard
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
_______________________________________________
Ecrit mailing list
Ecrit(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf