idnits 2.17.1 draft-ietf-sip-rph-new-namespaces-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 21, 2008) is 5909 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) == Missing Reference: 'RFCXXXX' is mentioned on line 236, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James Polk 3 Internet-Draft Cisco Systems 4 Expires: Aug 21, 2008 February 21, 2008 5 Intended Status: Standards Track (as PS) 7 IANA Registration of New Session Initiation Protocol (SIP) 8 Resource-Priority Namespaces 9 draft-ietf-sip-rph-new-namespaces-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document creates additional Session Initiation Protocol 43 Resource-Priority namespaces, and places these namespaces in the 44 IANA register. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1 Conventions used in this document . . . . . . . . . . . . 3 50 2. New RPH Namespaces Created . . . . . . . . . . . . . . . . . 3 51 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 52 3.1 IANA Resource-Priority Namespace Registration . . . . . . . 5 53 3.2 IANA Priority-Value Registrations . . . . . . . . . . . . 6 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 55 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 6.1 Normative References . . . . . . . . . . . . . . . . . . 11 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 59 Intellectual Property and Copyright Statements . . . . . . . 11 61 1. Introduction 63 The US Defense Information Systems Agency (DISA) is rolling out 64 their Session Initiation Protocol (SIP) based architecture at this 65 time. This network will require more Resource-Priority 66 namespaces than were defined, and IANA registered, in RFC 4412 67 [RFC4412]. The purpose of this document is to define these 68 additional namespaces. Each will be preemption in nature, as 69 defined in RFC 4412, and will have the same 9 priority-values. 71 DISA has a requirement to be able to assign different 72 Resource-Priority namespaces to different units of differing sizes 73 throughout their networks. Examples of this may be 75 - as large as each branch of service (army, navy, air force, 76 marines, coast guard) 78 - some departments within the government (Homeland Security, 79 Commerce, Treasury) 81 - plus have temporary assignments to individual units of varying 82 sizes (from battle groups to patrol groups or platoons) 84 These temporary assignments might be combinations of smaller units 85 involving several branches of service operating as one unit (say, 86 one task force, which is separate than the branch of service), or a 87 single commando unit requiring special treatment for a short period 88 of time, making it appear separate from the branch of service they 89 are from. 91 Providing DISA with a pool of namespaces for fine grained 92 assignment(s) allows them the flexibility they need for their 93 mission requirements. One can imagine due to their sheer size and 94 separation of purpose, they can easily utilize a significant number 95 of namespaces within their networks. This is the reason for the 96 assignment of so many new namespaces, which seems to deviate from 97 guidance in RFC 4412 to have a few namespaces as possible. 99 This document makes no changes to SIP, just adds IANA registered 100 namespaces for its use. 102 1.1 Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described 107 in [RFC2119]. 109 2. New SIP Resource-Priority Namespaces Created 111 The following 50 SIP namespaces are created by this document: 113 dsn-000000 drsn-000010 rts-000020 crts-000000 114 dsn-000001 drsn-000011 rts-000021 crts-000001 115 dsn-000002 drsn-000012 rts-000022 crts-000002 116 dsn-000003 drsn-000013 rts-000023 crts-000003 117 dsn-000004 drsn-000014 rts-000024 crts-000004 118 dsn-000005 drsn-000015 rts-000025 crts-000005 119 dsn-000006 drsn-000016 rts-000026 crts-000006 120 dsn-000007 drsn-000017 rts-000027 crts-000007 121 dsn-000008 drsn-000018 rts-000028 crts-000008 122 dsn-000009 drsn-000019 rts-000029 crts-000009 124 Each namespace listed above is wholly different. However, according 125 to the rules of section 8 within RFC 4412, one or more sets can be 126 treated as if the same when configured as an aggregated grouping of 127 namespaces. 129 These aggregates of two or more namespaces, that are to be 130 considered equivalent during treatment, can be a set of any IANA 131 registered namespaces, not just adjacent namespaces. 133 Each namespace listed above will have the same 9 priority-levels: 135 .0 (lowest priority) 136 .1 137 .2 138 .3 139 .4 140 .5 141 .6 142 .7 143 .8 144 .9 (highest priority) 146 According to the rules established in RFC 4412 [RFC4412], 147 priority-values have a relative order for preferential treatment, 148 unless one or more consecutive groups of priority-values are to be 149 considered equivalent (i.e., first-received, first treated). 151 Thus, a message (or a call) with the following Resource-Priority 152 header value: 154 dsn-000001.8 156 for example, MUST NOT ever receive preferential treatment over a 157 message, for example, with this Resource-Priority header value: 159 dsn-000010.0 161 because they are two difference namespaces, unless the namespaces 163 dsn-000001 and dsn-000010 165 are configured as equivalent namespaces (according to section 8 of 166 RFC 4412). 168 The dash '-' character is just like any other character, and is not 169 to be considered a delimiter in any official way within any 170 namespace here. Other namespace definitions in the future could 171 change this. 173 As stated in Section 9 of RFC 4412 [RFC4412], an IANA registered 174 namespace SHOULD NOT change the number, and MUST NOT change the 175 relative priority order, of its assigned priority-values. 177 3. IANA Considerations 179 Abiding by the rules established within RFC 4412 [RFC4412], this is 180 a Standards-Track document registering new namespaces, their 181 associated priority-values and intended algorithms. 183 3.1 IANA Resource-Priority Namespace Registration 185 Within the "Resource-Priority Namespaces" registry in the 186 sip-parameters section of IANA, the following table lists the new 187 namespaces registered by this document (NOTE: 'RFCXXXX' is to be 188 replaced by this document's RFC number if this document is published 189 by the RFC-Editor): 191 Intended New warn- New resp. 192 Namespace Levels Algorithm code code Reference 193 ---------- ------ ------------ --------- --------- --------- 194 dsn-000000 10 preemption no no [RFCXXXX] 195 dsn-000001 10 preemption no no [RFCXXXX] 196 dsn-000002 10 preemption no no [RFCXXXX] 197 dsn-000003 10 preemption no no [RFCXXXX] 198 dsn-000004 10 preemption no no [RFCXXXX] 199 dsn-000005 10 preemption no no [RFCXXXX] 200 dsn-000006 10 preemption no no [RFCXXXX] 201 dsn-000007 10 preemption no no [RFCXXXX] 202 dsn-000008 10 preemption no no [RFCXXXX] 203 dsn-000009 10 preemption no no [RFCXXXX] 205 drsn-000000 10 preemption no no [RFCXXXX] 206 drsn-000001 10 preemption no no [RFCXXXX] 207 drsn-000002 10 preemption no no [RFCXXXX] 208 drsn-000003 10 preemption no no [RFCXXXX] 209 drsn-000004 10 preemption no no [RFCXXXX] 210 drsn-000005 10 preemption no no [RFCXXXX] 211 drsn-000006 10 preemption no no [RFCXXXX] 212 drsn-000007 10 preemption no no [RFCXXXX] 213 drsn-000008 10 preemption no no [RFCXXXX] 214 drsn-000009 10 preemption no no [RFCXXXX] 216 rts-000000 10 preemption no no [RFCXXXX] 217 rts-000001 10 preemption no no [RFCXXXX] 218 rts-000002 10 preemption no no [RFCXXXX] 219 rts-000003 10 preemption no no [RFCXXXX] 220 rts-000004 10 preemption no no [RFCXXXX] 221 rts-000005 10 preemption no no [RFCXXXX] 222 rts-000006 10 preemption no no [RFCXXXX] 223 rts-000007 10 preemption no no [RFCXXXX] 224 rts-000008 10 preemption no no [RFCXXXX] 225 rts-000009 10 preemption no no [RFCXXXX] 227 crts-000000 10 preemption no no [RFCXXXX] 228 crts-000001 10 preemption no no [RFCXXXX] 229 crts-000002 10 preemption no no [RFCXXXX] 230 crts-000003 10 preemption no no [RFCXXXX] 231 crts-000004 10 preemption no no [RFCXXXX] 232 crts-000005 10 preemption no no [RFCXXXX] 233 crts-000006 10 preemption no no [RFCXXXX] 234 crts-000007 10 preemption no no [RFCXXXX] 235 crts-000008 10 preemption no no [RFCXXXX] 236 crts-000009 10 preemption no no [RFCXXXX] 238 3.2 IANA Priority-Value Registrations 240 Within the "Resource-Priority Priority-values" registry in the 241 sip-parameters section of IANA, the list of priority-values for each 242 of the 40 newly created namespaces from section 3.1 of this 243 document, prioritized least to greatest, is registered by the 244 following (to be replicated similar to the following format): 246 Namespace: dsn-000000 247 Reference: RFCXXXX (this document) 248 Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5", 249 "6", "7", "8", "9" 251 4. Security Considerations 253 This document has the same Security Considerations as RFC 4412. 255 5. Acknowledgements 257 To Jeff Hewett for his helpful guidance in this effort. Thanks to 258 Janet Gunn, John Rosenberg, Joel Halpern, Michael Giniger, Henning 259 Schulzrinne and Keith Drage for their comments. 261 6. References 263 6.1 Normative References 265 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 266 Priority for the Session Initiation Protocol (SIP)", RFC 267 4411, Feb 2006 269 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 270 Requirement Levels", RFC 2119, March 1997 272 Author's Address 274 James Polk 275 3913 Treemont Circle 276 Colleyville, Texas 76034 277 USA 279 Phone: +1-817-271-3552 280 Fax: none 281 Email: jmpolk@cisco.com 283 Full Copyright Statement 285 Copyright (C) The IETF Trust (2008). 287 This document is subject to the rights, licenses and restrictions 288 contained in BCP 78, and except as set forth therein, the authors 289 retain all their rights. 291 This document and the information contained herein are provided on 292 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 293 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 294 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 295 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 296 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 297 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 298 FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed 304 to pertain to the implementation or use of the technology described 305 in this document or the extent to which any license under such 306 rights might or might not be available; nor does it represent that 307 it has made any independent effort to identify any such rights. 308 Information on the procedures with respect to rights in RFC 309 documents can be found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use 314 of such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository 316 at http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org. 324 Acknowledgment 326 Funding for the RFC Editor function is provided by the IETF 327 Administrative Support Activity (IASA).