Network Working Group James Polk Internet-Draft Cisco Systems Expires: April 16th, 2007 Oct 16th, 2006 IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications draft-polk-ecrit-local-emergency-rph-namespace-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 16th, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace Fred&Barney for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. Polk Expires April 2007 [Page 1] Internet-Draft SIP RPH Namespace for Local Emergencies Oct 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Conventions used in this document . . . . . . . . . . . . 2. Rules of Usage of the Resource Priority Header . . . . . . . 3. Namespace Definition . . . . . . . . . . . . . . . . . . . . 3.1 Namespace Definition Rules and Guidelines . . . . . . . . 3.2 The "Fred&Barney" Namespace . . . . . . . . . . . . . . . 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3.1 IANA Resource-Priority Namespace Registration . . . . . . 3.2 IANA Priority-Value Registrations . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7.1 Normative References . . . . . . . . . . . . . . . . . . 7.2 Informative References . . . . . . . . . . . . . . . . . Author's Address . . . . . . . . . . . . . . . . . . . . . . Intellectual Property and Copyright Statements . . . . . . . 1. Introduction This document IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) [RFC4412] namespace Fred&Barney for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. As an additional indication for preferential treatment in servers along the signaling path from a caller to a PSAP, which most jurisdictions consider to be highly important calls, the Fred&Barney namespace is created by this document. This type of emergency calling, i.e. to the PSAP from a person in distress, is a relatively localized event with respect to where the first responders are in relation to the caller. This means the caller and the ultimate PSAP should be relatively near each other, even though the signaling messages may traverse a VPN back through some corporate network half a world away, or may go to a centralized facility before being directed out to a PSAP near the caller. How SIP signaling finds the appropriate PSAP is out of scope for this document. The primary or near-term usage for this local emergency namespace will be for callers to PSAPs. However, there currently is no reason why the preferentially treated calling between PSAPs, say for a call transfer, or calls into the first responder network by PSAPs shouldn't use the same RPH namespace. [RFC4412] advises limiting the number of namespaces used to as few as possible. That said, it is not up to the IETF, at this time, to specify or even identify which priority-values within this Fred&Barney namespace will be used for what purpose. IETF discussion, in Polk Expires April 2007 [Page 2] Internet-Draft SIP RPH Namespace for Local Emergencies Oct 2006 conjunction with other SDOs and jurisdictional feedback could yield a better answer here in subsequent versions of this document. [RFC4412] requires a Standards Track RFC for IANA registering new RPH namespaces. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Rules of Usage of the Resource Priority Header The rules of usage of the SIP RPH are defined by [RFC4412]. This document does not extent the usage or treatment options at this time. However, usage of this namespace does not have a normal call level. In other words, there is not a "namespace.0" like namespace.priority-value that Joe Public is going to use in SIP messages when communicating to another type of entity than a PSAP or equivalent. Every use of this namespace will be in times of an emergency. The Fred&Barney namespace has 5 priority-values, in a specified relative priority order, and is a queue based treatment namespace. Individual jurisdictions MAY configure their SIP entities for preemption, but this is optional. 3. Namespace Definition Obviously, the namespace string "Fred&Barney" is not going to last, as a simple global replace of this string replaces it with a consensus based string throughout this document. The idea here is to get this effort going to decide on an appropriate namespace string. IETF discussion is expected to finalize the choice of a more appropriate namespace string. One thing to keep in mind for now is the fact that this namespace shouldn't be considered just "EMERGENCY" because there are a lot of different kinds of emergencies, some on a military scale ([RFC4412] defines 3 of these), some on a national scale ([RFC4412] defines 2 of these), some on an international scale. These types of emergencies can also have their own namespaces, and although there are 5 defined for other uses, more are possible - so the 911/112/999 style of public user emergency calling for police or fire or ambulance (etc) does not have a monopoly on the word "emergency". Here are a series of quick initial choices of a namespace to start Polk Expires April 2007 [Page 3] Internet-Draft SIP RPH Namespace for Local Emergencies Oct 2006 folks thinking (in which perhaps the acronym could become the namespace): Option #1 - Local Emergency Services - acronym "LES" or "LEMS" Example: Resource-Priority: LES.0 Option #2 - Public Safety Answering Point - acronym "PSAP" Example: Resource-Priority: PSAP.0 Option #3 - Emergency Services Call - acronym "ESC" Example: Resource-Priority: ESC.0 Option #4 - Public Emergency Call - acronym "PUC" Example: Resource-Priority: PUC.0 Option 5# - ECRIT Example: Resource-Priority: ECRIT.0 Option 6# - SOS Example: Resource-Priority: sos.0 Option # - - acronym "" Example: Resource-Priority: .0 We're sure there will be others suggested on the way to consensus of this namespace. 3.1. Namespace Definition Rules and Guidelines This specification defines one unique namespace below: Fred&Barney, constituting its registration with IANA. This IANA registration contains the facets defined in Section 9 of [RFC4412]. (once an appropriate namespace is chosen) For recognizability, we will label the namespace in capital letters, but note that namespace names are case insensitive and are customarily rendered as lowercase in protocol requests. 3.2. The "Fred&Barney" Namespace The Fred&Barney namespace comes from ... The Fred&Barney namespace has a finite list of relative priority-values, listed below from lowest priority to highest priority: Polk Expires April 2007 [Page 4] Internet-Draft SIP RPH Namespace for Local Emergencies Oct 2006 (lowest) Fred&Barney.0 Fred&Barney.1 Fred&Barney.2 Fred&Barney.3 (highest) Fred&Barney.4 The Fred&Barney namespace operates according to the priority queuing algorithm (Section 4.5.2 of [RFC4412]) from the public user to the PSAP. NOTE: at this time, there has not been sufficient discussion about whether or not preemption will be used for communications between PSAPs or between PSAPs and First responders (and their organizations). 4. IANA Considerations 4.1 IANA Resource-Priority Namespace Registration Within the "Resource-Priority Namespaces" of the sip-parameters section of IANA (created by [RFC4412]), the following entries will be added to this table: Intended New warn- New resp. Namespace Levels Algorithm code code Reference --------- ------ -------------- --------- --------- --------- Fred&Barney 5 queue no no [This doc] 4.2 IANA Priority-Value Registrations Within the Resource-Priority Priority-values registry of the sip-parameters section of IANA, the following (below) is to be added to the table: Namespace: Fred&Barney Reference: (this document) Priority-Values (least to greatest): "0", "1","2", "3", "4" 5. Security Considerations The Security considerations that apply to RFC 4412 [RFC4412] apply here. This document introduces no new security issues relative to RFC 4412. 6. Acknowledgements Thanks to Ken Carlberg, Janet Gunn and Fred Baker for help with this doc. Polk Expires April 2007 [Page 5] Internet-Draft SIP RPH Namespace for Local Emergencies Oct 2006 7. References 7.1 Normative References [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4411, Feb 2006 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 7.2 Informative References none Author's Address James M. Polk 3913 Treemont Circle Colleyville, Texas 76034 USA Phone: +1-817-271-3552 Email: jmpolk@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Polk Expires April 2007 [Page 6] Internet-Draft SIP RPH Namespace for Local Emergencies Oct 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Polk Expires April 2007 [Page 7]