idnits 2.17.00 (12 Aug 2021) /tmp/idnits33390/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Mar 24, 2009) is 4806 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: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ECRIT Working Group James Polk 2 Internet-Draft Cisco Systems 3 Expires: September 24, 2009 Mar 24, 2009 4 Intended Status: Standards Track (as PS) 6 IANA Registering a SIP Resource Priority Header 7 Namespace for Local Emergency Communications 8 draft-ietf-ecrit-local-emergency-rph-namespace-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with 13 the provisions of BCP 78 and BCP 79. This document may contain 14 material from IETF Documents or IETF Contributions published or made 15 publicly available before November 10, 2008. The person(s) 16 controlling the copyright in some of this material may not have 17 granted the IETF Trust the right to allow modifications of such 18 material outside the IETF Standards Process. Without obtaining an 19 adequate license from the person(s) controlling the copyright in 20 such materials, this document may not be modified outside the IETF 21 Standards Process, and derivative works of it may not be created 22 outside the IETF Standards Process, except to format it for 23 publication as an RFC or to translate it into languages other than 24 English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 9, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your 53 rights and restrictions with respect to this document. 55 Legal 57 This documents and the information contained therein are provided on 58 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 59 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 60 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 61 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 62 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 63 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 64 FOR A PARTICULAR PURPOSE. 66 Abstract 68 This document creates and IANA registers the new Session Initiation 69 Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for 70 local emergency usage to a public safety answering point (PSAP), 71 between PSAPs, and between a PSAP and first responders and their 72 organizations. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 77 2. Rules of Usage of the Resource Priority Header . . . . . . . 4 78 3. "esnet" Namespace Definition . . . . . . . . . . . . . . . . 6 79 3.1 Namespace Definition Rules and Guidelines . . . . . . . . 6 80 3.2 The "esnet" Namespace . . . . . . . . . . . . . . . . . . 6 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 4.1 IANA Resource-Priority Namespace Registration . . . . . . 7 83 4.2 IANA Priority-Value Registrations . . . . . . . . . . . . 7 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 7.1 Normative References . . . . . . . . . . . . . . . . . . 8 88 7.2 Informative References . . . . . . . . . . . . . . . . . 8 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 92 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described 94 in [RFC2119]. 96 1. Introduction 98 This document creates and IANA registers the new Session Initiation 99 Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for 100 local emergency usage. The SIP Resource-Priority header is defined 101 in RFC 4412 [RFC4412]. This new namespace is to be used within 102 public safety answering point (PSAP) networks. This new namespace 103 can be used for inbound calls towards PSAPs, between PSAPs, and 104 between a PSAP and first responders or their organizations. 106 Within controlled environments, such as an IMS infrastructure or 107 Emergency Services network (ESInet), where misuse can be reduced to 108 a minimum because these types of networks have great controls in 109 place, this namespace can be to provide an explicit priority 110 indication that facilitates differing treatment of emergency SIP 111 messages according to local policy, or more likely, a contractual 112 agreement between the network organizations. This indication is 113 used to differentiate SIP requests, or dialogs, from other requests 114 or dialogs that do not have the need for priority treatment. 116 It can also be imagined that Voice Service Providers (VSP) directly 117 attached to an ESInet can have a trust relationship with the ESInet 118 such that within these networks, SIP requests (thereby the session 119 they establish) make use of this "esnet" namespace for appropriate 120 treatment. 122 Usage of the "esnet" namespace is to be defined in a future 123 document(s). This document merely creates the namespace, per the 124 rules within [RFC4412], necessitating a Standards Track RFC for 125 IANA registering new RPH namespaces and their relative 126 priority-value order. 128 There is a possibility that within emergency services networks, a 129 Multilevel Precedence and Preemption (MLPP)-like behavior can be 130 achieved (likely without the 'preemption' part, which will always be 131 a matter of local policy, and not defined here) - ensuring more 132 important calls are established or retained, the "esnet" namespace 133 is given 5 priority-levels. MLPP-like SIP signaling is not defined 134 in this document for 911/112/999 style emergency calling, but it is 135 not prevented either. 137 Within the ESINet, there will be emergency calls requiring different 138 treatments, according to the type of call. Does a citizen's call to 139 a PSAP require the same, a higher or a lower relative priority than 140 a PSAP's call to a police department, or the police chief? What 141 about either relative to a call from within the ESINet to a 142 federal government's department of national security, such as the US 143 Department of Homeland Security? For this reason, the "esnet" 144 namespace is given multiple priority levels. 146 This document does not define any of these behaviors, outside of 147 reminding readers that the rules of RFC 4412 apply - though examples 148 of usage are included for completeness. This document IANA 149 registers the "esnet" RPH namespace for use within emergency 150 services networks, not just of those from citizens to PSAPs. 152 2. Rules of Usage of the Resource Priority Header 154 This document updates the behaviors of the SIP Resource Priority 155 header, defined in [RFC4412], during the treatment options 156 surrounding this new "esnet" namespace only. The usage of the 157 "esnet" namespace does not have a 'normal', or routine call level, 158 given the environment this is to be used within (i.e., within an 159 ESInet). That is for local jurisdictions to define within their 160 respective parts of the ESInet- which could be islands of local 161 administration. 163 RFC4412 states that modifying the relative priority ordering or the 164 number of priority-values to a registered namespace is not 165 recommended across the same administrative domain, due to 166 interoperability issues with dissimilar implementations. 168 Every use of this namespace will be in times of an emergency, where 169 at least one end of the signaling is within a local emergency 170 organization. 172 The "esnet" namespace has 5 priority-values, in a specified relative 173 priority order, and is a queue-based treatment namespace [RFC4412]. 174 Individual jurisdictions MAY configure their SIP entities for 175 preemption treatment, but this is optional, and a local policy 176 decision. 178 Conceivably, this could be an example network diagram where the 179 "esnet" namespace is used: 181 |<-"esnet" namespace->| 182 | *WILL* be used | 183 "esnet" namespace | ,-------. 184 usage out of scope | ,' `. 185 |<------------>|<---"esnet" namespace ---->| / \ 186 +----+ | can be used +-----+ | ESINet | 187 | UA |--- | --------------------|Proxy|-+ ------ | 188 +----+ \ | / +-----+ | | 189 \ ,-------+ ,-------. | | +------+ | 190 +----+ ,' `. ,' `. | | |PSAP-1| | 191 | UA |--- / User \ / Service \ | | +------+ | 192 +----+ ( Network +---+ Network )| | | 193 \ / \ / | | +------+ | 194 +----+ /`. ,' `. .+-----+ | |PSAP-2| | 195 | UA |---- '-------' '-------' |Proxy|-+ +------+ | 196 +----+ | +-----+ | | 197 | | | | 198 +----+ | +-----+ | +------+ | 199 | UA |--- | --------------------|Proxy|-+ |PSAP-3| | 200 +----+ \ | / +-----+ | +------+ | 201 \ ,-------+ ,-------. | | | 202 +----+ ,' `. ,' `. | | | 203 | UA |--- / User \ / Service \ | | +------+ | 204 +----+ ( Network +---+ Network )| | |PSAP-4| | 205 \ / \ / | | +------+ | 206 +----+ /`. ,' `. .+-----+ | | 207 | UA |---- '-------' '-------' |Proxy|-+ ANY can | 208 +----+ | +-----+ | xfer/call | 209 | | \ | | | / 210 `. | | | ,' 211 '-|-|-|-' 212 | | | 213 Police <--------------+ | | 214 Fire <----------+ | 215 Federal Agency <-------+ 217 Figure 1: Where 'esnet' Namespace Can or Will be used 219 In Figure 1., the "esnet" namespace is intended for usage within the 220 ESInet on the right side of the diagram. How it is specifically 221 utilized is out of scope for this document, and left to local 222 jurisdictions to define. Adjacent VSPs to the ESInet MAY have a 223 trust relationship that includes allowing this/these neighboring 224 VSP(s) to use the "esnet" namespace to differentiate SIP requests 225 and dialogs within the VSP's network. The exact mapping between the 226 internal and external sides of the edge proxy at the ESInet 227 boundaries is out of scope of this document. 229 To be clear, the use of an edge proxy in any network, the rules 230 within the document that create a (i.e., each) namespace apply, and 231 because the "esnet" namespace is allowed to be modified or deleted 232 at the edge proxy of the ESInet does not allow any edge proxy to 233 modify or delete any other Resource-Priority namespace. This 234 document's target market is for the "esnet" namespace only. 236 3. "esnet" Namespace Definition 238 One thing to keep in mind for now is the fact that this namespace 239 is not to be considered just "EMERGENCY" because there are a lot of 240 different kinds of emergencies, some on a military scale ([RFC4412] 241 defines 3 of these), some on a national scale ([RFC4412] defines 2 242 of these), some on an international scale. These types of 243 emergencies can also have their own namespaces, and although there 244 are 5 defined for other uses, more are possible - so the 911/112/999 245 style of public user emergency calling for police or fire or 246 ambulance (etc) does not have a monopoly on the word "emergency". 248 Therefore, the namespace "esnet" has been chosen, as it is most 249 recognizable as that of citizen's call for help from a public 250 authority type of organization. This namespace will also be used 251 for communications between emergency authorities, and MAY be used 252 for emergency authorities calling public citizens. An example of 253 the later is a PSAP operator calling back someone who previously 254 called 9111/112/999 and the communication was terminated before it 255 should have been (in the operator's judgment). 257 Here is an example of a Resource-Priority header using the esnet 258 namespace: 260 Resource-Priority: esnet.0 262 3.1. Namespace Definition Rules and Guidelines 264 This specification defines one unique namespace for emergency 265 calling scenarios, "esnet", constituting its registration with IANA. 266 This IANA registration contains the facets defined in Section 9 of 267 [RFC4412]. 269 3.2. The "esnet" Namespace 271 Per the rules of [RFC4412], each namespace has a finite set of 272 relative priority-value(s), listed (below) from lowest priority to 273 highest priority. In an attempt to not limit this namespace's use 274 in the future, more than one priority-value is assigned to the 275 "esnet" namespace. This document does not RECOMMEND which 276 priority-value is used where. That is for another document to 277 specify. This document does RECOMMEND the choice within a national 278 jurisdiction is coordinated by all sub-jurisdictions to maintain 279 uniform SIP behavior throughout an emergency calling system. 281 The relative priority order for the "esnet" namespace is as follows: 283 (lowest) esnet.0 284 esnet.1 285 esnet.2 286 esnet.3 287 (highest) esnet.4 289 The "esnet" namespace will be assigned into the priority queuing 290 algorithm (Section 4.5.2 of [RFC4412]) from the public user to the 291 PSAP. This does not limit its usage to only the priority queue 292 algorithm; meaning the preemption algorithm is a policy decision for 293 local jurisdictions. This document is not RECOMMENDING this 294 usage, merely pointing out those behaviors is a matter of local 295 policy. 297 The rules originated in RFC 4412 remain with regard to an RP actor, 298 who understands more than one namespace, MUST maintain its locally 299 significant relative priority order. 301 NOTE: at this time, there has not been sufficient discussion about 302 whether or not preemption will be used for communications between 303 PSAPs or between PSAPs and First responders (and their 304 organizations). 306 4. IANA Considerations 308 4.1 IANA Resource-Priority Namespace Registration 310 Within the "Resource-Priority Namespaces" of the sip-parameters 311 section of IANA (created by [RFC4412]), the following entries will 312 be added to this table: 314 Intended New warn- New resp. 315 Namespace Levels Algorithm code code Reference 316 --------- ------ -------------- --------- --------- --------- 317 esnet 5 queue no no [This doc] 319 4.2 IANA Priority-Value Registrations 321 Within the Resource-Priority Priority-values registry of the 322 sip-parameters section of IANA, the following (below) is to be added 323 to the table: 325 Namespace: esnet 326 Reference: (this document) 327 Priority-Values (least to greatest): "0", "1","2", "3", "4" 329 5. Security Considerations 331 The Security considerations that apply to RFC 4412 [RFC4412] apply 332 here. 334 The implications of using this header-value incorrectly can cause a 335 large impact on a network - given that this indication is to give 336 preferential treatment of marked traffic great preference within the 337 network than other traffic. This document does not indicate this 338 marking is intended for use by endpoints, yet protections need to be 339 taken to prevent granting preferential treatment to unauthorized 340 users not calling for emergency help. 342 A simple means of preventing this usage into an ESInet is to not 343 allow "esnet" marked traffic to get preferential treatment unless 344 the destination is towards the local/regional ESInet. This is not a 345 consideration for internetwork traffic within the ESInet, or 346 generated out of the ESInet. 911/112/999 type of calling is fairly 347 local in nature, with a finite number of URIs that are considered 348 valid. 350 6. Acknowledgements 352 Thanks to Ken Carlberg, Janet Gunn, Fred Baker and Keith Drage for 353 help and encouragement with this effort. Thanks to Henning 354 Schulzrinne, Ted Hardie, Hannes Tschofenig, Brian Rosen, Janet Gunn 355 and Marc Linsner for constructive comments. 357 7. References 359 7.1 Normative References 361 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 362 Requirement Levels", RFC 2119, March 1997 364 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 365 Priority for the Session Initiation Protocol (SIP)", RFC 366 4411, Feb 2006 368 7.2 Informative References 370 none 372 Author's Address 374 James Polk 375 3913 Treemont Circle 376 Colleyville, Texas 76034 377 USA 378 Phone: +1-817-271-3552 379 Email: jmpolk@cisco.com