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@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of
> Hannes Tschofenig
> Sent: 13 July 2011 10:21
> To: ietf@ietf.org IETF; ecrit@ietf.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@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may
> be
> > sent to iesg@ietf.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@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit