idnits 2.17.1 draft-ietf-sip-rph-new-namespaces-03.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 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 323. 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 (March 10, 2008) is 5892 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 237, 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: Sept 10, 2008 March 10, 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-03.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 Sept 10, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document creates additional Session Initiation Protocol (SIP) 43 Resource-Priority namespaces to meet the requirements of the US 44 Defense Information Systems Agency, and places these namespaces in 45 the IANA registry. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1 Conventions used in this document . . . . . . . . . . . . 3 51 2. New RPH Namespaces Created . . . . . . . . . . . . . . . . . 3 52 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 53 3.1 IANA Resource-Priority Namespace Registration . . . . . . . 5 54 3.2 IANA Priority-Value Registrations . . . . . . . . . . . . 6 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 58 6.1 Normative References . . . . . . . . . . . . . . . . . . 11 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 60 Intellectual Property and Copyright Statements . . . . . . . 11 62 1. Introduction 64 The US Defense Information Systems Agency (DISA) is rolling out 65 their Session Initiation Protocol (SIP) based architecture at this 66 time. This network will require more Resource-Priority 67 namespaces than were defined, and IANA registered, in RFC 4412 68 [RFC4412]. The purpose of this document is to define these 69 additional namespaces. Each will be preemption in nature, as 70 defined in RFC 4412, and will have the same 9 priority-values. 72 DISA has a requirement to be able to assign different 73 Resource-Priority namespaces to different units of differing sizes 74 throughout their networks. Examples of this may be 76 - as large as each branch of service (army, navy, air force, 77 marines, coast guard) 79 - some departments within the government (Homeland Security, 80 Commerce, Treasury) 82 - plus have temporary assignments to individual units of varying 83 sizes (from battle groups to patrol groups or platoons) 85 These temporary assignments might be combinations of smaller units 86 involving several branches of service operating as one unit (say, 87 one task force, which is separate than the branch of service), or a 88 single commando unit requiring special treatment for a short period 89 of time, making it appear separate from the branch of service they 90 are from. 92 Providing DISA with a pool of namespaces for fine grained 93 assignment(s) allows them the flexibility they need for their 94 mission requirements. One can imagine due to their sheer size and 95 separation of purpose, they can easily utilize a significant number 96 of namespaces within their networks. This is the reason for the 97 assignment of so many new namespaces, which seems to deviate from 98 guidance in RFC 4412 to have a few namespaces as possible. 100 This document makes no changes to SIP, just adds IANA registered 101 namespaces for its use. 103 1.1 Conventions used in this document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 106 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described 108 in [RFC2119]. 110 2. New SIP Resource-Priority Namespaces Created 112 The following 50 SIP namespaces are created by this document: 114 dsn-000000 drsn-000010 rts-000020 crts-000000 115 dsn-000001 drsn-000011 rts-000021 crts-000001 116 dsn-000002 drsn-000012 rts-000022 crts-000002 117 dsn-000003 drsn-000013 rts-000023 crts-000003 118 dsn-000004 drsn-000014 rts-000024 crts-000004 119 dsn-000005 drsn-000015 rts-000025 crts-000005 120 dsn-000006 drsn-000016 rts-000026 crts-000006 121 dsn-000007 drsn-000017 rts-000027 crts-000007 122 dsn-000008 drsn-000018 rts-000028 crts-000008 123 dsn-000009 drsn-000019 rts-000029 crts-000009 125 Each namespace listed above is wholly different. However, according 126 to the rules of section 8 within RFC 4412, one or more sets can be 127 treated as if the same when configured as an aggregated grouping of 128 namespaces. 130 These aggregates of two or more namespaces, that are to be 131 considered equivalent during treatment, can be a set of any IANA 132 registered namespaces, not just adjacent namespaces. 134 Each namespace listed above will have the same 9 priority-levels: 136 .0 (lowest priority) 137 .1 138 .2 139 .3 140 .4 141 .5 142 .6 143 .7 144 .8 145 .9 (highest priority) 147 According to the rules established in RFC 4412 [RFC4412], 148 priority-values have a relative order for preferential treatment, 149 unless one or more consecutive groups of priority-values are to be 150 considered equivalent (i.e., first-received, first treated). 152 Thus, a message (or a call) with the following Resource-Priority 153 header value: 155 dsn-000001.8 157 for example, MUST NOT ever receive preferential treatment over a 158 message, for example, with this Resource-Priority header value: 160 dsn-000010.0 162 because they are two difference namespaces, unless the namespaces 164 dsn-000001 and dsn-000010 166 are configured as equivalent namespaces (according to section 8 of 167 RFC 4412). 169 The dash '-' character is just like any other character, and is not 170 to be considered a delimiter in any official way within any 171 namespace here. Other namespace definitions in the future could 172 change this. 174 As stated in Section 9 of RFC 4412 [RFC4412], an IANA registered 175 namespace SHOULD NOT change the number, and MUST NOT change the 176 relative priority order, of its assigned priority-values. 178 3. IANA Considerations 180 Abiding by the rules established within RFC 4412 [RFC4412], this is 181 a Standards-Track document registering new namespaces, their 182 associated priority-values and intended algorithms. 184 3.1 IANA Resource-Priority Namespace Registration 186 Within the "Resource-Priority Namespaces" registry in the 187 sip-parameters section of IANA, the following table lists the new 188 namespaces registered by this document (NOTE: 'RFCXXXX' is to be 189 replaced by this document's RFC number if this document is published 190 by the RFC-Editor): 192 Intended New warn- New resp. 193 Namespace Levels Algorithm code code Reference 194 ---------- ------ ------------ --------- --------- --------- 195 dsn-000000 10 preemption no no [RFCXXXX] 196 dsn-000001 10 preemption no no [RFCXXXX] 197 dsn-000002 10 preemption no no [RFCXXXX] 198 dsn-000003 10 preemption no no [RFCXXXX] 199 dsn-000004 10 preemption no no [RFCXXXX] 200 dsn-000005 10 preemption no no [RFCXXXX] 201 dsn-000006 10 preemption no no [RFCXXXX] 202 dsn-000007 10 preemption no no [RFCXXXX] 203 dsn-000008 10 preemption no no [RFCXXXX] 204 dsn-000009 10 preemption no no [RFCXXXX] 206 drsn-000000 10 preemption no no [RFCXXXX] 207 drsn-000001 10 preemption no no [RFCXXXX] 208 drsn-000002 10 preemption no no [RFCXXXX] 209 drsn-000003 10 preemption no no [RFCXXXX] 210 drsn-000004 10 preemption no no [RFCXXXX] 211 drsn-000005 10 preemption no no [RFCXXXX] 212 drsn-000006 10 preemption no no [RFCXXXX] 213 drsn-000007 10 preemption no no [RFCXXXX] 214 drsn-000008 10 preemption no no [RFCXXXX] 215 drsn-000009 10 preemption no no [RFCXXXX] 217 rts-000000 10 preemption no no [RFCXXXX] 218 rts-000001 10 preemption no no [RFCXXXX] 219 rts-000002 10 preemption no no [RFCXXXX] 220 rts-000003 10 preemption no no [RFCXXXX] 221 rts-000004 10 preemption no no [RFCXXXX] 222 rts-000005 10 preemption no no [RFCXXXX] 223 rts-000006 10 preemption no no [RFCXXXX] 224 rts-000007 10 preemption no no [RFCXXXX] 225 rts-000008 10 preemption no no [RFCXXXX] 226 rts-000009 10 preemption no no [RFCXXXX] 228 crts-000000 10 preemption no no [RFCXXXX] 229 crts-000001 10 preemption no no [RFCXXXX] 230 crts-000002 10 preemption no no [RFCXXXX] 231 crts-000003 10 preemption no no [RFCXXXX] 232 crts-000004 10 preemption no no [RFCXXXX] 233 crts-000005 10 preemption no no [RFCXXXX] 234 crts-000006 10 preemption no no [RFCXXXX] 235 crts-000007 10 preemption no no [RFCXXXX] 236 crts-000008 10 preemption no no [RFCXXXX] 237 crts-000009 10 preemption no no [RFCXXXX] 239 3.2 IANA Priority-Value Registrations 241 Within the "Resource-Priority Priority-values" registry in the 242 sip-parameters section of IANA, the list of priority-values for each 243 of the 40 newly created namespaces from section 3.1 of this 244 document, prioritized least to greatest, is registered by the 245 following (to be replicated similar to the following format): 247 Namespace: dsn-000000 248 Reference: RFCXXXX (this document) 249 Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5", 250 "6", "7", "8", "9" 252 4. Security Considerations 254 This document has the same Security Considerations as RFC 4412. 256 5. Acknowledgements 258 To Jeff Hewett for his helpful guidance in this effort. Thanks to 259 Janet Gunn, John Rosenberg, Joel Halpern, Michael Giniger, Henning 260 Schulzrinne and Keith Drage for their comments. 262 6. References 264 6.1 Normative References 266 [RFC4412] Schulzrinne, H., Polk, J., "Communications Resource 267 Priority for the Session Initiation Protocol (SIP)", RFC 268 4411, Feb 2006 270 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 271 Requirement Levels", RFC 2119, March 1997 273 Author's Address 275 James Polk 276 3913 Treemont Circle 277 Colleyville, Texas 76034 278 USA 280 Phone: +1-817-271-3552 281 Fax: none 282 Email: jmpolk@cisco.com 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2008). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on 293 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 294 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 295 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 296 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 297 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 298 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 299 FOR A PARTICULAR PURPOSE. 301 Intellectual Property 303 The IETF takes no position regarding the validity or scope of any 304 Intellectual Property Rights or other rights that might be claimed 305 to pertain to the implementation or use of the technology described 306 in this document or the extent to which any license under such 307 rights might or might not be available; nor does it represent that 308 it has made any independent effort to identify any such rights. 309 Information on the procedures with respect to rights in RFC 310 documents can be found in BCP 78 and BCP 79. 312 Copies of IPR disclosures made to the IETF Secretariat and any 313 assurances of licenses to be made available, or the result of an 314 attempt made to obtain a general license or permission for the use 315 of such proprietary rights by implementers or users of this 316 specification can be obtained from the IETF on-line IPR repository 317 at http://www.ietf.org/ipr. 319 The IETF invites any interested party to bring to its attention any 320 copyrights, patents or patent applications, or other proprietary 321 rights that may cover technology that may be required to implement 322 this standard. Please address the information to the IETF at 323 ietf-ipr@ietf.org. 325 Acknowledgment 327 Funding for the RFC Editor function is provided by the IETF 328 Administrative Support Activity (IASA).