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@xxxxxxxx mailing lists by 2011-07-13. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf