idnits 2.17.1 draft-ietf-dime-diameter-cmd-iana-00.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 (June 3, 2009) is 5440 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-17 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 June 3, 2009 7 Expires: December 5, 2009 9 Updated IANA Considerations for Diameter Command Code Allocations 10 draft-ietf-dime-diameter-cmd-iana-00.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 December 5, 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 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. RFC 3588 87 illustrates the conditions that lead to the need to define a new 88 Diameter application or a new command code. Depending on the scope 89 of the Diameter extension IETF actions are necessary. Although 90 defining new Diameter applications does not require IETF consensus, 91 defining new Diameter commands requires IETF consensus per RFC 3588. 92 This has lead to questionable design decisions by other Standards 93 Development Organizations which chose to define new applications on 94 existing commands rather than asking for assignment of new command 95 codes for the pure purpose of avoiding bringing their specifications 96 to the IETF. In some cases interoperability problems were causes as 97 an effect of the poor design caused by overloading existing commands. 99 This document aligns the extensibility rules of Diameter application 100 with the Diameter commands offering ways to delegate work on Diameter 101 to other SDOs to extend Diameter in a way that does not lead to poor 102 design choices. 104 This is achieved by splitting the command code space into an IANA 105 administered code space, and a vendors-specific code space with 106 different rules of allocation as per [RFC5226]. 108 A revision of RFC 3588 is currently in development in the IETF DIME 109 WG [I-D.ietf-dime-rfc3588bis]. and when approved will obsolete RFC 110 3588 as well as this document. This document has as a goal providing 111 in advance the change in the command codes allocation policy, so that 112 interoperability problems as the ones described above are avoided as 113 soon as possible. 115 2. Conventions used in this document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 3. Security Considerations 123 This document modifies the IANA allocation of Diameter Command Codes 124 in relationship to RFC 3588. This process change itself does not 125 raise security concerns, but the command codes space is split into a 126 standards commands space and a vendor-specific command codes space, 127 the later being allocated on a First Come, First Served basis by IANA 128 at the request of vendors or other standards organizations. Whenever 129 work gets delegated to organizations outside the IETF there is always 130 the chance that fewer security reviews are conducted and hence the 131 quality of the resulting protocol document is weaker compared to the 132 rather extensive reviews performed in the IETF. The members of the 133 DIME working group are aware of the tradeoff between better 134 specification quality and the desire to offload work (e.g., to reduce 135 the workload in the IETF) to other organizations. Other 136 organizations are therefore made responsible for the quality of the 137 specifications they produce. 139 4. IANA Considerations 141 This section describes changes to the IANA consideration sections 142 outlined in RFC 3588 regarding the allocation of Command Codes by 143 IANA. 145 The Command Code namespace is used to identify Diameter commands. 146 The values 0-255 (0x00-0xff) are reserved for RADIUS backward 147 compatibility, and are defined as "RADIUS Packet Type Codes" in 148 [RADTYPE]. Values 256 - 8,388,607 (0x100 to 0x7fffff) are for 149 permanent, standard commands, allocated by IETF Review [RFC5226]. 150 [RFC3588] defines the Command Codes 257, 258, 271, 274-275, 280 and 151 282. See Section 3.1 in [RFC3588] for the assignment of the 152 namespace in this specification. 154 The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved 155 for vendor-specific command codes, to be allocated on a First Come, 156 First Served basis by IANA [RFC5226]. The request to IANA for a 157 Vendor-Specific Command Code SHOULD include a reference to a publicly 158 available specification which documents the command in sufficient 159 detail to aid in interoperability between independent 160 implementations. If the specification cannot be made publicly 161 available, the request for a vendor-specific command code MUST 162 include the contact information of persons and/or entities 163 responsible for authoring and maintaining the command. 165 The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 166 0xffffff) are reserved for experimental commands. As these codes are 167 only for experimental and testing purposes, no guarantee is made for 168 interoperability between Diameter peers using experimental commands, 169 as outlined in [RFC3692]. 171 5. Acknowledgements 173 The content of this document is the result of the work in the IETF 174 Diameter Maintenance and Extensions (dime) working group. We would 175 therefore like to thank all the working group members who were 176 involved in that discussion. While it appears to be a fairly small 177 change in the allocation policy the effect on implementations is 178 rather dramatic. 180 6. References 182 6.1. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 188 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 190 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 191 Considered Useful", BCP 82, RFC 3692, January 2004. 193 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 194 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 195 May 2008. 197 6.2. Informative References 199 [I-D.ietf-dime-rfc3588bis] 200 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 201 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-17 202 (work in progress), May 2009. 204 [RADTYPE] "IANA, RADIUS Types, 205 http://www.iana.org/assignments/radius-types". 207 Authors' Addresses 209 Dan Romascanu 210 Avaya 211 Industrial Park Atidim, Bldg#3 212 Tel Aviv 61581 213 Israel 215 Phone: +972-3-645-8414 216 Email: dromasca@avaya.com 218 Hannes Tschofenig 219 Nokia Siemens Networks 220 Linnoitustie 6 221 Espoo 02600 222 Finland 224 Phone: +358 (50) 4871445 225 Email: Hannes.Tschofenig@gmx.net 226 URI: http://www.tschofenig.priv.at