Re: 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 i...@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-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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
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-boun...@ietf.org [mailto:ecrit-boun...@ietf.org] On Behalf Of Hannes Tschofenig Sent: 13 July 2011 10:21 To: ietf@ietf.org IETF; ec...@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 i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
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
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 i...@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may be sent to i...@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
