Internet Engineering Task Force (IETF) D. Romascanu
Request for Comments: 5719 Avaya
Updates: 3588 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 January 2010
Internet Engineering Task Force (IETF) D. Romascanu
Request for Comments: 5719 Avaya
Updates: 3588 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 January 2010
Updated IANA Considerations for Diameter Command Code Allocations
更新了Diameter命令代码分配的IANA注意事项
Abstract
摘要
The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
RFC 3588中描述的Diameter base规范提供了许多扩展Diameter的方法，其中新的Diameter命令（即Diameter应用程序使用的消息）和应用程序是最广泛的增强功能。RFC 3588说明了导致需要定义新直径应用程序或新命令代码的条件。根据直径扩展的范围，IETF行动是必要的。尽管定义新的Diameter应用程序不需要IETF共识，但根据RFC 3588定义新Diameter命令需要IETF共识。这导致其他标准开发组织的设计决策有问题，他们选择在现有命令上定义新的应用程序，而不是要求分配新的命令代码，纯粹是为了避免将其规范提交给IETF。在某些情况下，互操作性问题是由于现有命令过载而导致的糟糕设计造成的。
This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices.
本文档将Diameter应用程序的可扩展性规则与Diameter命令相一致，提供了将Diameter上的工作委托给其他SDO的方法，以便以不会导致糟糕的设计选择的方式扩展Diameter。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5719.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5719.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . . 5
The Diameter Base specification, described in [RFC3588], provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. [RFC3588] illustrates the conditions that require the definition of a new Diameter application or a new command. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations (SDOs), which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of poor the design caused by overloading existing commands.
[RFC3588]中描述的Diameter Base规范提供了许多扩展Diameter的方法，其中新的Diameter命令（即Diameter应用程序使用的消息）和应用程序是最广泛的增强功能。[RFC3588]说明了需要定义新直径应用程序或新命令的条件。根据直径扩展的范围，IETF行动是必要的。尽管定义新的Diameter应用程序不需要IETF共识，但根据RFC 3588定义新Diameter命令需要IETF共识。这导致其他标准开发组织（SDO）的设计决策有问题，他们选择在现有命令上定义新的应用程序，而不是要求分配新的命令代码，纯粹是为了避免将其规范提交给IETF。在某些情况下，互操作性问题是由于现有命令过载导致的设计不佳造成的。
This document aligns the extensibility rules for Diameter command codes with those defined for Diameter application identifiers and offers a consistent way to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices.
本文档将Diameter命令代码的可扩展性规则与Diameter应用程序标识符的可扩展性规则相一致，并提供了一种一致的方式，将Diameter上的工作委托给其他SDO，以便以一种不会导致糟糕的设计选择的方式扩展Diameter。
This is achieved by splitting the command code space into ranges and providing different allocation policies to them: the first range is reserved for RADIUS backward compatibility, allocation of a command code in the second number range requires IETF review, the third range is utilized by vendor-specific command codes, and finally the last range is for experimental commands. Section 4 provides more details about the command code number ranges, and the different allocation policies are described in [RFC5226].
这是通过将命令代码空间拆分为多个范围并向其提供不同的分配策略来实现的：第一个范围是为RADIUS向后兼容性保留的，第二个数字范围内的命令代码分配需要IETF审查，第三个范围由供应商特定的命令代码使用，最后一个范围是实验命令。第4节提供了有关命令代码范围的更多详细信息，不同的分配策略在[RFC5226]中进行了描述。
A revision of RFC 3588 is currently in development in the IETF DIME WG [RFC3588bis]; when approved, it will obsolete RFC 3588 as well as this document. A goal of this document is to provide in advance the change in the command codes allocation policy, so that interoperability problems like the ones described above are avoided as soon as possible.
IETF DIME工作组[RFC3588bis]目前正在开发RFC 3588的修订版；经批准后，将淘汰RFC 3588以及本文件。本文档的目标是提前提供命令代码分配策略的更改，以便尽快避免上述互操作性问题。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document modifies the IANA allocation of Diameter command codes in relationship to RFC 3588. This process change itself does not raise security concerns, but the command code space is split into a standard command code space and a vendor-specific command code space, the latter being allocated on a First Come, First Served basis by IANA at the request of vendors or other standards organizations. Whenever work gets delegated to organizations outside the IETF, there is always the chance that security reviews will be conducted in different manner and that the criteria and style of those reviews will be different than the reviews performed in the IETF. The members of the DIME working group are aware of the risks involved in using different security and quality review processes and of the desire to offload work (e.g., to reduce the workload in the IETF) to other organizations. Other organizations are therefore made responsible for the quality of the specifications they produce.
本文件修改了与RFC 3588相关的Diameter命令代码的IANA分配。此流程更改本身不会引起安全问题，但命令代码空间被分为标准命令代码空间和供应商特定的命令代码空间，后者由IANA根据供应商或其他标准组织的要求以先到先得的方式分配。每当将工作委托给IETF以外的组织时，总是有可能以不同的方式进行安全审查，并且这些审查的标准和风格将不同于IETF中执行的审查。DIME工作组成员了解使用不同安全和质量审查流程所涉及的风险，以及将工作（例如，减少IETF中的工作量）转移给其他组织的愿望。因此，其他组织对其生产的规格的质量负责。
This section describes changes to the IANA Considerations sections outlined in RFC 3588 regarding the allocation of command codes by IANA.
本节描述了RFC 3588中概述的有关IANA分配命令代码的IANA注意事项部分的更改。
The command code namespace is used to identify Diameter commands. The values 0 - 255 (0x00 - 0xff) are reserved for RADIUS backward
命令代码命名空间用于标识Diameter命令。值0-255（0x00-0xff）保留用于向后半径
compatibility and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256 - 8,388,607 (0x100 - 0x7fffff) are for permanent, standard commands allocated by IETF Review [RFC5226]. [RFC3588] defines the command codes 257, 258, 271, 274, 275, 280, and 282; see Section 3.1 in [RFC3588] for the assignment of the namespace in that specification.
兼容性和在[RADTYPE]中定义为“RADIUS数据包类型代码”。值256-8388607（0x100-0x7fffff）用于IETF Review[RFC5226]分配的永久性标准命令。[RFC3588]定义命令代码257、258、271、274、275、280和282；有关该规范中名称空间的分配，请参见[RFC3588]中的第3.1节。
The values 8,388,608 - 16,777,213 (0x800000 - 0xfffffd) are reserved for vendor-specific command codes, to be allocated on a First Come, First Served basis by IANA [RFC5226]. The request to IANA for a vendor-specific command code SHOULD include a reference to a publicly available specification that documents the command in sufficient detail to aid in interoperability between independent implementations. If the specification cannot be made publicly available, the request for a vendor-specific command code MUST include the contact information of persons and/or entities responsible for authoring and maintaining the command.
值8388608-16777213（0x800000-0xfffffd）保留给供应商特定的命令代码，由IANA按照先到先得的原则分配[RFC5226]。向IANA请求特定于供应商的命令代码时，应包括对公开可用规范的引用，该规范详细记录了命令，以帮助独立实现之间的互操作性。如果规范无法公开，则供应商特定命令代码的请求必须包括负责编写和维护命令的人员和/或实体的联系信息。
The values 16,777,214 and 16,777,215 (hexadecimal values 0xfffffe - 0xffffff) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands, as outlined in [RFC3692].
值16777214和16777215（十六进制值0xfffffe-0xffffff）保留用于实验命令。由于这些代码仅用于实验和测试目的，因此无法保证使用实验命令的Diameter对等机之间的互操作性，如[RFC3692]所述。
The content of this document is the result of the work in the IETF Diameter Maintenance and Extensions (DIME) working group. We would therefore like to thank all the working group members who were involved in that discussion. While it appears to be a fairly small change in the allocation policy, the effect on implementations is rather dramatic.
本文件内容是IETF直径维护和扩展（DIME）工作组工作的结果。因此，我们要感谢参与这一讨论的所有工作组成员。虽然这似乎是分配策略中的一个相当小的变化，但对实现的影响相当显著。
We would like to thank Mark Jones for his review comments.
我们要感谢马克·琼斯的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RADTYPE] IANA, "Radius Types", <http://www.iana.org>.
[RADTYPE]IANA，“半径类型”<http://www.iana.org>.
[RFC3588bis] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, September 2009.
[RFC3588bis]Fajardo，V.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基础协议”，正在进行的工作，2009年9月。
Authors' Addresses
作者地址
Dan Romascanu Avaya Industrial Park Atidim, Bldg#3 Tel Aviv 61581 Israel
以色列特拉维夫3号楼阿蒂迪姆工业园Dan Romascanu Avaya 61581
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
Phone: +972-3-645-8414
EMail: dromasca@avaya.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at