idnits 2.17.1 draft-polk-ecrit-local-emergency-rph-namespace-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Unrecognized Status in 'Intended Status: Standards Track (as PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 19, 2009) is 5516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT Working Group James Polk 3 Internet-Draft Cisco Systems 4 Expires: August 19, 2009 Feb 19, 2009 5 Intended Status: Standards Track (as PS) 6 Updates: RFC4412 (if published as an RFC) 8 IANA Registering a SIP Resource Priority Header 9 Namespace for Local Emergency Communications 10 draft-polk-ecrit-local-emergency-rph-namespace-04 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 20, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. 47 Abstract 49 This document creates and IANA registers the new Session Initiation 50 Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for 51 local emergency usage to a public safety answering point (PSAP), 52 between PSAPs, and between a PSAP and first responders and their 53 organizations. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Rules of Usage of the Resource Priority Header . . . . . . . 3 59 3. "esnet" Namespace Definition . . . . . . . . . . . . . . . . 5 60 3.1 Namespace Definition Rules and Guidelines . . . . . . . . 6 61 3.2 The "esnet" Namespace . . . . . . . . . . . . . . . . . . 6 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 4.1 IANA Resource-Priority Namespace Registration . . . . . . 7 64 4.2 IANA Priority-Value Registrations . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1 Normative References . . . . . . . . . . . . . . . . . . 7 69 7.2 Informative References . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 71 Intellectual Property and Copyright Statements . . . . . . . 8 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 74 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 75 "OPTIONAL" in this document are to be interpreted as described 76 in [RFC2119]. 78 1. Introduction 80 This document creates and IANA registers the new Session Initiation 81 Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for 82 local emergency usage. The SIP Resource-Priority header is defined 83 in RFC 4412 [RFC4412]. This new namespace within the public safety 84 answering point (PSAP) network ("ESInet"). This new namespace can 85 be used for inbound calls to PSAPs, between PSAPs, and between a 86 PSAP and first responders and their organizations. 88 Within controlled environments, such as an IMS infrastructure or 89 Emergency Services network (ESInet), where misuse can be reduced to 90 a minimum where possible, this namespace is to be to provide an 91 explicit priority indication facilitates treatment of emergency SIP 92 messages according to local policy. This indication is used to 93 differentiate SIP requests, or dialogs, from other requests or 94 dialogs that do not have the need for priority treatment. 96 It can also be imagined that Voice Service Providers (VSP) directly 97 attached to an ESInet can have a trust relationship with the ESInet 98 such that within these networks, SIP requests (thereby the session 99 they establish) make use of this "esnet" namespace for appropriate 100 treatment. 102 Usage of the "esnet" namespace is to be defined in a future 103 document(s). This document merely creates the namespace, per the 104 rules within [RFC4412] necessitating a Standards Track RFC for 105 IANA registering new RPH namespaces and their relative 106 priority-value order. [RFC4412] further states that modifying the 107 order or the number of priority-values to a registered namespace 108 SHOULD NOT occur, due to interoperability issues with dissimilar 109 implementations. 111 From this fact about RFC 4412, and the possibility that within 112 emergency services networks, a Multilevel Precedence and Preemption 113 (MLPP)-like behavior can be achieved - ensuring more important calls 114 are established or retained, the "esnet" namespace is given 5 115 priority-levels. MLPP-like SIP signaling is not defined in this 116 document for 911/112/999 style emergency calling, but it is not 117 prevented either. 119 Within the ESINet, there will be emergency calls requiring different 120 treatments, according to the type of call. Does a citizen's call to 121 a PSAP require the same, a higher or a lower relative priority than 122 a PSAP's call to a police department, or the police chief? What 123 about either relative to a call from within the ESINet to a 124 federal government's department of national security, such as the US 125 Department of Homeland Security? For this reason, the "esnet" 126 namespace is given multiple priority levels. 128 This document does not define any of these behaviors, outside of 129 reminding readers that the rules of RFC 4412 apply - though examples 130 of usage are included for completeness. This document IANA 131 registers the "esnet" RPH namespace for use within emergency 132 services networks, not just of those from citizens to PSAPs. 134 2. Rules of Usage of the Resource Priority Header 136 This document updates the behaviors of the SIP Resource Priority 137 header, defined in [RFC4412], during the treatment options 138 surrounding this new "esnet" namespace only. The usage of the 139 "esnet" namespace does not have a normal, or routine call level. 140 Every use of this namespace will be in times of an emergency, where 141 at least one end of the signaling is with a local emergency 142 organization. 144 The "esnet" namespace has 5 priority-values, in a specified relative 145 priority order, and is a queue-based treatment namespace [RFC4412]. 146 Individual jurisdictions MAY configure their SIP entities for 147 preemption treatment, but this is optional, and a local policy 148 decision. 150 Conceivably, this could be an example of a generic network diagram 151 where the "esnet" namespace is used: 153 |<-"esnet" namespace->| 154 | *WILL* be used | 155 "esnet" namespace | ,-------. 156 usage out of scope | ,' `. 157 |<------------>|<---"esnet" namespace ---->| / \ 158 +----+ | can be used +-----+ | ESINet | 159 | UA |--- | --------------------|Proxy|-+ ------ | 160 +----+ \ | / +-----+ | | 161 \ ,-------+ ,-------. | | +------+ | 162 +----+ ,' `. ,' `. | | |PSAP-1| | 163 | UA |--- / User \ / Service \ | | +------+ | 164 +----+ ( Network +---+ Network )| | | 165 \ / \ / | | +------+ | 166 +----+ /`. ,' `. .+-----+ | |PSAP-2| | 167 | UA |---- '-------' '-------' |Proxy|-+ +------+ | 168 +----+ | +-----+ | | 169 | | | | 170 +----+ | +-----+ | +------+ | 171 | UA |--- | --------------------|Proxy|-+ |PSAP-3| | 172 +----+ \ | / +-----+ | +------+ | 173 \ ,-------+ ,-------. | | | 174 +----+ ,' `. ,' `. | | | 175 | UA |--- / User \ / Service \ | | +------+ | 176 +----+ ( Network +---+ Network )| | |PSAP-4| | 177 \ / \ / | | +------+ | 178 +----+ /`. ,' `. .+-----+ | | 179 | UA |---- '-------' '-------' |Proxy|-+ ANY can | 180 +----+ | +-----+ | xfer/call | 181 | | \ | | | / 182 `. | | | ,' 183 '-|-|-|-' 184 | | | 185 Police <--------------+ | | 186 Fire <----------+ | 187 Federal Agency <-------+ 189 Figure 1: Where 'esnet' Namespace Can or Will be used 191 In Figure 1., the "esnet" namespace is intended for usage within the 192 ESInet on the right side of the diagram. How it is utilized is out 193 of scope for this document. Adjacent VSPs to the ESInet MAY have a 194 trust relationship that includes allowing this neighboring VSP to 195 use the "esnet" namespace to differentiate SIP requests and dialogs 196 within the VSP network. How this namespace is utilized is out of 197 scope for this document. Because the more important usage of the 198 "esnet" namespace occurs within the ESInet, the edge proxy, called 199 an Emergency Services Routing Proxy (ESRP) can modify or delete this 200 namespace. This is a normative change to the allowed behavior within 201 [RFC4412], but MUST only be considered valid in this usage at the 202 ESInet boundary for this one RP namespace (and associated 203 priority-value). The exact mapping between the sides of the ESRP at 204 the ESInet boundary are out of scope of this document. 206 3. "esnet" Namespace Definition 208 One thing to keep in mind for now is the fact that this namespace 209 is not to be considered just "EMERGENCY" because there are a lot of 210 different kinds of emergencies, some on a military scale ([RFC4412] 211 defines 3 of these), some on a national scale ([RFC4412] defines 2 212 of these), some on an international scale. These types of 213 emergencies can also have their own namespaces, and although there 214 are 5 defined for other uses, more are possible - so the 911/112/999 215 style of public user emergency calling for police or fire or 216 ambulance (etc) does not have a monopoly on the word "emergency". 218 Therefore, the namespace "esnet" has been chosen, as it is most 219 recognizable as that of citizen's call for help from a public 220 authority type of organization. This namespace will also be used 221 for communications between emergency authorities, and MAY be used 222 for emergency authorities calling public citizens. An example of 223 the later is a PSAP operator calling back someone who previously 224 called 9111/112/999 and the communication was terminated before it 225 should have been (in the operator's judgment). 227 Here is an example of a Resource-Priority header using the esnet 228 namespace: 230 Resource-Priority: esnet.0 232 3.1. Namespace Definition Rules and Guidelines 234 This specification defines one unique namespace for emergency 235 calling scenarios, "esnet", constituting its registration with IANA. 236 This IANA registration contains the facets defined in Section 9 of 237 [RFC4412]. 239 3.2. The "esnet" Namespace 241 Per the rules of [RFC4412], each namespace has a finite set of 242 relative priority-value(s), listed (below) from lowest priority to 243 highest priority. In an attempt to not limit this namespace's use 244 in the future, more than one priority-value is assigned to the 245 "esnet" namespace. This document does not RECOMMEND which 246 priority-value is used where. That is for another document to 247 specify. This document does RECOMMEND the choice within a national 248 jurisdiction be coordinated by all sub-jurisdictions to maintain 249 uniform SIP behavior throughout an emergency calling system. 251 The relative priority order for the "esnet" namespace is as follows: 253 (lowest) esnet.0 254 esnet.1 255 esnet.2 256 esnet.3 257 (highest) esnet.4 259 The "esnet" namespace will be assigned into the priority queuing 260 algorithm (Section 4.5.2 of [RFC4412]) from the public user to the 261 PSAP. This does not limit its usage to only the priority queue 262 algorithm; meaning the preemption algorithm can be used where the 263 local jurisdiction preferred to preempt normal calls in lieu of 264 completing emergency calls. This document is not RECOMMENDING this 265 usage, merely pointing out those behaviors are a matter of local 266 policy. 268 NOTE: at this time, there has not been sufficient discussion about 269 whether or not preemption will be used for communications between 270 PSAPs or between PSAPs and First responders (and their 271 organizations). 273 4. IANA Considerations 275 4.1 IANA Resource-Priority Namespace Registration 277 Within the "Resource-Priority Namespaces" of the sip-parameters 278 section of IANA (created by [RFC4412]), the following entries will 279 be added to this table: 281 Intended New warn- New resp. 282 Namespace Levels Algorithm code code Reference 283 --------- ------ -------------- --------- --------- --------- 284 esnet 5 queue no no [This doc] 286 4.2 IANA Priority-Value Registrations 288 Within the Resource-Priority Priority-values registry of the 289 sip-parameters section of IANA, the following (below) is to be added 290 to the table: 292 Namespace: esnet 293 Reference: (this document) 294 Priority-Values (least to greatest): "0", "1","2", "3", "4" 296 5. Security Considerations 298 The Security considerations that apply to RFC 4412 [RFC4412] apply 299 here. 301 The implications of using this header-value incorrectly can cause a 302 large impact on a network - given that this indication is to give 303 preferential treatment of marked traffic great preference within the 304 network than other traffic. This document does not indicate this 305 marking is intended for use by endpoints, yet protections need to be 306 taken to prevent granting preferential treatment to unauthorized 307 users not calling for emergency help. 309 A simple means of preventing this usage is to not allow marked 310 traffic preferential treatment unless the destination is towards the 311 local/regional ESInet. 911/112/999 type of calling is fairly local 312 in nature, with a finite number of URIs that are considered valid. 314 6. Acknowledgements 316 Thanks to Ken Carlberg, Janet Gunn, Fred Baker and Keith Drage for 317 help and encouragement with this effort. Thanks to Henning 318 Schulzrinne, Ted Hardie, Hannes Tschofenig, Brian Rosen and Marc 319 Linsner for constructive comments. 321 7. References 323 7.1 Normative References 325 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 326 Requirement Levels", RFC 2119, March 1997 328 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 329 Priority for the Session Initiation Protocol (SIP)", RFC 330 4411, Feb 2006 332 7.2 Informative References 334 none 336 Author's Address 338 James Polk 339 3913 Treemont Circle 340 Colleyville, Texas 76034 341 USA 343 Phone: +1-817-271-3552 344 Email: jmpolk@cisco.com