RFC 5719 - Updated IANA Considerations for Diameter Command Code Allocations 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5719
タイトル : RFC 5719 - 直径コマンドコードの割り当てに関するIANAの考慮事項を更新しました
翻訳編集 : 自動生成

[要約] RFC 5719は、Diameterコマンドコードの割り当てに関するIANAの考慮事項を更新するためのものです。その目的は、Diameterプロトコルの拡張性と互換性を向上させることです。

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

直径コマンドコードの割り当てに関する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で説明されている直径のベース仕様は、最も広範な拡張機能として、新しい直径コマンド（つまり、直径アプリケーションで使用されるメッセージ）とアプリケーションを備えた直径を拡張するいくつかの方法を提供します。RFC 3588は、新しい直径アプリケーションまたは新しいコマンドコードを定義する必要性につながる条件を示しています。直径拡張の範囲に応じて、IETFアクションが必要です。新しい直径アプリケーションを定義してもIETFコンセンサスは必要ありませんが、新しい直径コマンドを定義するには、RFC 3588ごとに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.

このドキュメントは、直径アプリケーションの拡張性ルールを直径コマンドと並べることで、他のSDOに直径の作業を委任する方法を提供して、設計の選択肢が低い方法で直径を延長します。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5719で取得できます。

著作権表示

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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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

1. はじめに

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]に記載されている直径ベース仕様は、最も広範な機能強化として、新しい直径コマンド（つまり、直径アプリケーションで使用されるメッセージ）とアプリケーションを使用して、直径を拡張するいくつかの方法を提供します。[RFC3588]は、新しい直径アプリケーションまたは新しいコマンドの定義が必要な条件を示しています。直径拡張の範囲に応じて、IETFアクションが必要です。新しい直径アプリケーションを定義してもIETFコンセンサスは必要ありませんが、新しい直径コマンドを定義するには、RFC 3588ごとにIETFコンセンサスが必要です。新しいコマンドコードの割り当てを求めるよりも - 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.

このドキュメントは、直径コマンドコードの拡張性ルールを直径アプリケーション識別子用に定義されたコマンドコードと並べ、直径の作業を他のSDOに委任するための一貫した方法を提供して、設計の選択の低下につながる方法で直径を拡張します。

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].

これは、コマンドコードスペースを範囲に分割し、さまざまな割り当てポリシーを提供することで達成されます。最初の範囲は、半径の後方互換性のために予約されています。 - 固有のコマンドコード、そして最後に最後の範囲は実験コマンド用です。セクション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.

RFC 3588の改訂は現在、IETF DIME WG [RFC3588BIS]で開発中です。承認されると、RFC 3588とこのドキュメントが廃止されます。このドキュメントの目標は、上記のような相互運用性の問題ができるだけ早く回避されるように、コマンドコードの割り当てポリシーの変更を事前に提供することです。

2. Conventions Used in This Document

2. このドキュメントで使用されている規則

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].

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

3. Security Considerations

3. セキュリティに関する考慮事項

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との関係における直径コマンドコードのIANA割り当てを変更します。このプロセスの変更自体はセキュリティ上の懸念を高めませんが、コマンドコードスペースは標準コマンドコードスペースとベンダー固有のコマンドコードスペースに分割されます。ベンダーまたはその他の標準組織の要請で、最初に来て、IANAが最初に務めた。IETF以外の組織に作業が委任されると、セキュリティレビューが異なる方法で実施され、それらのレビューの基準とスタイルがIETFで実行されたレビューとは異なる可能性が常にあります。DIMEワーキンググループのメンバーは、さまざまなセキュリティと品質のレビュープロセスを使用することに伴うリスクと、他の組織に作業をオフロードしたいという要望（IETFのワークロードを減らすなど）を認識しています。したがって、他の組織は、生成する仕様の品質について責任を負います。

4. IANA Considerations

4. IANAの考慮事項

This section describes changes to the IANA Considerations sections outlined in RFC 3588 regarding the allocation of command codes by IANA.

このセクションでは、IANAによるコマンドコードの割り当てに関するRFC 3588で概説されているIANAの考慮事項セクションの変更について説明します。

The command code namespace is used to identify Diameter commands. The values 0 - 255 (0x00 - 0xff) are reserved for RADIUS backward 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.

コマンドコード名空間は、直径コマンドを識別するために使用されます。値0-255（0x00-0xff）は、半径の後方互換性のために予約されており、[radtype]の「半径パケットタイプコード」として定義されます。値256-8,388,607（0x100-0x7fffff）は、IETFレビュー[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.

値8,388,608-16,777,213（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].

値16,777,214および16,777,215（ヘキサデシマル値0xffffffe -0xffffff）は、実験コマンドのために予約されています。これらのコードは実験目的とテスト目的のみを目的としているため、[RFC3692]で概説されているように、実験コマンドを使用して直径ピア間の相互運用性を保証することはできません。

5. Acknowledgements

5. 謝辞

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.

彼のレビューコメントについてマークジョーンズに感謝したいと思います。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[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月。

6.2. Informative References

6.2. 参考引用

[RADTYPE] IANA, "Radius Types", <http://www.iana.org>.

[radtype] iana、 "radius型"、<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

ダン・ロマスカヌ・アヴァヤ工業団地Atidim、Bldg＃3 Tel Aviv 61581イスラエル

   Phone: +972-3-645-8414
   EMail: dromasca@avaya.com

Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland

Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド

   Phone: +358 (50) 4871445
   EMail: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at