idnits 2.17.1 draft-ietf-dime-diameter-cmd-iana-01.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: ---------------------------------------------------------------------------- No issues found here. 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 -- The document date (July 13, 2009) is 5400 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) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-34) exists of draft-ietf-dime-rfc3588bis-18 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dime D. Romascanu 3 Internet-Draft Avaya 4 Updates: rfc3588 H. Tschofenig 5 (if approved) Nokia Siemens Networks 6 Intended status: Standards Track July 13, 2009 7 Expires: January 14, 2010 9 Updated IANA Considerations for Diameter Command Code Allocations 10 draft-ietf-dime-diameter-cmd-iana-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 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 January 14, 2010. 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The Diameter Base specification, described in RFC 3588, provides a 49 number of ways to extend Diameter, with new Diameter commands, i.e. 50 messages used by Diameter applications, and applications as the most 51 extensive enhancements. RFC 3588 illustrates the conditions that 52 lead to the need to define a new Diameter application or a new 53 command code. Depending on the scope of the Diameter extension IETF 54 actions are necessary. Although defining new Diameter applications 55 does not require IETF consensus, defining new Diameter commands 56 requires IETF consensus per RFC 3588. This has lead to questionable 57 design decisions by other Standards Development Organizations which 58 chose to define new applications on existing commands rather than 59 asking for assignment of new command codes for the pure purpose of 60 avoiding bringing their specifications to the IETF. In some cases 61 interoperability problems were causes as an effect of the poor design 62 caused by overloading existing commands. 64 This document aligns the extensibility rules of Diameter application 65 with the Diameter commands offering ways to delegate work on Diameter 66 to other SDOs to extend Diameter in a way that does not lead to poor 67 design choices. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions used in this document . . . . . . . . . . . . . . 5 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 75 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 The Diameter Base specification, described in RFC 3588 [RFC3588], 84 provides a number of ways to extend Diameter, with new Diameter 85 commands, i.e. messages used by Diameter applications, and 86 applications as the most extensive enhancements. RFC3588 illustrates 87 the conditions, which require the definition of a new Diameter 88 application or a new command. Depending on the scope of the Diameter 89 extension IETF actions are necessary. Although defining new Diameter 90 applications does not require IETF consensus, defining new Diameter 91 commands requires IETF consensus per RFC 3588. This has lead to 92 questionable design decisions by other Standards Development 93 Organizations which chose to define new applications on existing 94 commands rather than asking for assignment of new command codes for 95 the pure purpose of avoiding bringing their specifications to the 96 IETF. In some cases interoperability problems were causes as an 97 effect of the poor design caused by overloading existing commands. 99 This document aligns the extensibility rules for Diameter command 100 codes with those defined for Diameter application identifiers and 101 offers a consistent way to delegate work on Diameter to other SDOs to 102 extend Diameter in a way that does not lead to poor design choices. 104 This is achieved by splitting the command code space into ranges and 105 providing different allocation policies to them: the first range is 106 reserved for RADIUS backward compatibility, allocation of a command 107 code in the second number range requires IETF review, the third range 108 is utilized by vendor-specific command codes, and finally the last 109 range is for experimental commands. Section 4 provides more details 110 about the command code number ranges and the different allocation 111 policies are described in [RFC5226]. 113 A revision of RFC 3588 is currently in development in the IETF DIME 114 WG [I-D.ietf-dime-rfc3588bis] and when approved will obsolete RFC 115 3588 as well as this document. This document has as a goal providing 116 in advance the change in the command codes allocation policy, so that 117 interoperability problems as the ones described above are avoided as 118 soon as possible. 120 2. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Security Considerations 128 This document modifies the IANA allocation of Diameter Command Codes 129 in relationship to RFC 3588. This process change itself does not 130 raise security concerns, but the command codes space is split into a 131 standards commands space and a vendor-specific command codes space, 132 the later being allocated on a First Come, First Served basis by IANA 133 at the request of vendors or other standards organizations. Whenever 134 work gets delegated to organizations outside the IETF there is always 135 the chance that fewer security reviews are conducted and hence the 136 quality of the resulting protocol document is weaker compared to the 137 rather extensive reviews performed in the IETF. The members of the 138 DIME working group are aware of the tradeoff between better 139 specification quality and the desire to offload work (e.g., to reduce 140 the workload in the IETF) to other organizations. Other 141 organizations are therefore made responsible for the quality of the 142 specifications they produce. 144 4. IANA Considerations 146 This section describes changes to the IANA consideration sections 147 outlined in RFC 3588 regarding the allocation of Command Codes by 148 IANA. 150 The Command Code namespace is used to identify Diameter commands. 151 The values 0-255 (0x00-0xff) are reserved for RADIUS backward 152 compatibility, and are defined as "RADIUS Packet Type Codes" in 153 [RADTYPE]. Values 256 - 8,388,607 (0x100 to 0x7fffff) are for 154 permanent, standard commands, allocated by IETF Review [RFC5226]. 155 [RFC3588] defines the Command Codes 257, 258, 271, 274-275, 280 and 156 282. See Section 3.1 in [RFC3588] for the assignment of the 157 namespace in this specification. 159 The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved 160 for vendor-specific command codes, to be allocated on a First Come, 161 First Served basis by IANA [RFC5226]. The request to IANA for a 162 Vendor-Specific Command Code SHOULD include a reference to a publicly 163 available specification which documents the command in sufficient 164 detail to aid in interoperability between independent 165 implementations. If the specification cannot be made publicly 166 available, the request for a vendor-specific command code MUST 167 include the contact information of persons and/or entities 168 responsible for authoring and maintaining the command. 170 The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 171 0xffffff) are reserved for experimental commands. As these codes are 172 only for experimental and testing purposes, no guarantee is made for 173 interoperability between Diameter peers using experimental commands, 174 as outlined in [RFC3692]. 176 5. Acknowledgements 178 The content of this document is the result of the work in the IETF 179 Diameter Maintenance and Extensions (dime) working group. We would 180 therefore like to thank all the working group members who were 181 involved in that discussion. While it appears to be a fairly small 182 change in the allocation policy the effect on implementations is 183 rather dramatic. 185 We would like to thank Mark Jones for his review comments. 187 6. References 189 6.1. Normative References 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 195 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 197 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 198 Considered Useful", BCP 82, RFC 3692, January 2004. 200 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 201 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 202 May 2008. 204 6.2. Informative References 206 [I-D.ietf-dime-rfc3588bis] 207 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 208 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-18 209 (work in progress), July 2009. 211 [RADTYPE] "IANA, RADIUS Types, 212 http://www.iana.org/assignments/radius-types". 214 Authors' Addresses 216 Dan Romascanu 217 Avaya 218 Industrial Park Atidim, Bldg#3 219 Tel Aviv 61581 220 Israel 222 Phone: +972-3-645-8414 223 Email: dromasca@avaya.com 225 Hannes Tschofenig 226 Nokia Siemens Networks 227 Linnoitustie 6 228 Espoo 02600 229 Finland 231 Phone: +358 (50) 4871445 232 Email: Hannes.Tschofenig@gmx.net 233 URI: http://www.tschofenig.priv.at