[要約] RFC 7423は、Diameterプロトコルのアプリケーション設計ガイドラインを提供するものであり、Diameterアプリケーションの設計と実装に関するベストプラクティスを示しています。目的は、Diameterベースのアプリケーションの効率的な開発と相互運用性の向上です。
Internet Engineering Task Force (IETF) L. Morand, Ed.
Request for Comments: 7423 Orange Labs
BCP: 193 V. Fajardo
Category: Best Current Practice Fluke Networks
ISSN: 2070-1721 H. Tschofenig
November 2014
Diameter Applications Design Guidelines
Diameterアプリケーションの設計ガイドライン
Abstract
概要
The Diameter base protocol provides facilities for protocol extensibility enabling the definition of new Diameter applications or modification of existing applications. This document is a companion document to the Diameter base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/ defining Diameter applications or creating generic Diameter extensions.
Diameter基本プロトコルは、新しいDiameterアプリケーションの定義または既存のアプリケーションの変更を可能にするプロトコル拡張性のための機能を提供します。このドキュメントは、Diameterを拡張するためのルールをさらに説明および明確化する、Diameter基本プロトコルの関連ドキュメントです。さらに、このドキュメントは、Diameterアプリケーション設計者がDiameterアプリケーションを再利用/定義するか、一般的なDiameter拡張を作成するためのガイドラインを提供します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc7423.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7423で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Reusing Existing Diameter Applications . . . . . . . . . . . 6
4.1. Adding a New Command . . . . . . . . . . . . . . . . . . 7
4.2. Deleting an Existing Command . . . . . . . . . . . . . . 8
4.3. Reusing Existing Commands . . . . . . . . . . . . . . . . 8
4.3.1. Adding AVPs to a Command . . . . . . . . . . . . . . 8
4.3.2. Deleting AVPs from a Command . . . . . . . . . . . . 10
4.3.3. Changing the Flag Settings of AVP in Existing
Commands . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Reusing Existing AVPs . . . . . . . . . . . . . . . . . . 11
4.4.1. Setting of the AVP Flags . . . . . . . . . . . . . . 11
4.4.2. Reuse of AVP of Type Enumerated . . . . . . . . . . . 12
5. Defining New Diameter Applications . . . . . . . . . . . . . 12
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Defining New Commands . . . . . . . . . . . . . . . . . . 12
5.3. Use of Application Id in a Message . . . . . . . . . . . 13
5.4. Application-Specific Session State Machines . . . . . . . 14
5.5. Session-Id AVP and Session Management . . . . . . . . . . 14
5.6. Use of Enumerated Type AVPs . . . . . . . . . . . . . . . 15
5.7. Application-Specific Message Routing . . . . . . . . . . 17
5.8. Translation Agents . . . . . . . . . . . . . . . . . . . 18
5.9. End-to-End Application Capabilities Exchange . . . . . . 18
5.10. Diameter Accounting Support . . . . . . . . . . . . . . . 19
5.11. Diameter Security Mechanisms . . . . . . . . . . . . . . 21
6. Defining Generic Diameter Extensions . . . . . . . . . . . . 21
7. Guidelines for Registrations of Diameter Values . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 25
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
The Diameter base protocol [RFC6733] is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This protocol provides the ability for Diameter peers to exchange messages carrying data in the form of Attribute-Value Pairs (AVPs).
Diameter基本プロトコル[RFC6733]は、ローカルアクセスとローミングの両方の状況でのネットワークアクセスやIPモビリティなどのアプリケーションに認証、承認、アカウンティング（AAA）フレームワークを提供することを目的としています。このプロトコルは、Diameterピアが属性値ペア（AVP）の形式でデータを運ぶメッセージを交換する機能を提供します。
The Diameter base protocol provides facilities to extend Diameter (see Section 1.3 of [RFC6733]) to support new functionality. In the context of this document, extending Diameter means one of the following:
Diameter基本プロトコルは、Diameter（[RFC6733]のセクション1.3を参照）を拡張して新しい機能をサポートする機能を提供します。このドキュメントのコンテキストでは、Diameterの拡張は次のいずれかを意味します。
1. The addition of new functionality to an existing Diameter application without defining a new application.
1. 新しいアプリケーションを定義せずに、既存のDiameterアプリケーションに新しい機能を追加する。
2. The addition of new functionality to an existing Diameter application that requires the definition of a new application.
2. 新しいアプリケーションの定義を必要とする既存のDiameterアプリケーションへの新機能の追加。
3. The definition of an entirely new Diameter application to offer functionality not supported by existing applications.
3. 既存のアプリケーションではサポートされていない機能を提供するための、まったく新しいDiameterアプリケーションの定義。
4. The definition of a new generic functionality that can be reused across different applications.
4. 異なるアプリケーション間で再利用できる新しい汎用機能の定義。
All of these extensions are design decisions that can be carried out by any combination of reusing existing or defining new commands, AVPs, or AVP values. However, application designers do not have complete freedom when making their design. A number of rules have been defined in [RFC6733] that place constraints on when an extension requires the allocation of a new Diameter application identifier or a new command code value. The objective of this document is the following:
これらの拡張はすべて、既存のコマンドを再利用するか、新しいコマンド、AVP、またはAVP値を定義することを組み合わせて実行できる設計上の決定です。ただし、アプリケーション設計者は、設計を行う際に完全な自由はありません。 [RFC6733]には、拡張機能が新しいDiameterアプリケーション識別子または新しいコマンドコード値の割り当てを必要とする場合に制約を課すいくつかのルールが定義されています。このドキュメントの目的は次のとおりです。
o Clarify the Diameter extensibility rules as defined in the Diameter base protocol.
o Diameter基本プロトコルで定義されているDiameter拡張性ルールを明確にします。
o Discuss design choices and provide guidelines when defining new applications.
o 新しいアプリケーションを定義するときに、設計の選択について話し合い、ガイドラインを提供します。
o Present trade-off choices.
o トレードオフの選択肢を提示します。
This document reuses the terminology defined in [RFC6733]. Additionally, the following terms and acronyms are used in this application:
このドキュメントは、[RFC6733]で定義された用語を再利用します。さらに、このアプリケーションでは次の用語と頭字語が使用されています。
Application: Extension of the Diameter base protocol [RFC6733] via the addition of new commands or AVPs. Each application is uniquely identified by an IANA-allocated application identifier value.
アプリケーション：新しいコマンドまたはAVPの追加によるDiameter基本プロトコル[RFC6733]の拡張。各アプリケーションは、IANAによって割り当てられたアプリケーション識別子の値によって一意に識別されます。
Command: Diameter request or answer carrying AVPs between Diameter endpoints. Each command is uniquely identified by an IANA-allocated Command Code value and is described by a Command Code Format (CCF) for an application.
コマンド：Diameterエンドポイント間でAVPを伝送するDiameter要求または応答。各コマンドは、IANAによって割り当てられたコマンドコード値によって一意に識別され、アプリケーションのコマンドコード形式（CCF）によって記述されます。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
As designed, the Diameter base protocol [RFC6733] can be seen as a two-layer protocol. The lower layer is mainly responsible for managing connections between neighboring peers and for message routing. The upper layer is where the Diameter applications reside. This model is in line with a Diameter node having an application layer and a peer-to-peer delivery layer. The Diameter base protocol document defines the architecture and behavior of the message delivery layer and then provides the framework for designing Diameter applications on the application layer. This framework includes definitions of application sessions and accounting support (see Sections 8 and 9 of [RFC6733]). Accordingly, a Diameter node is seen in this document as a single instance of a Diameter message delivery layer and one or more Diameter applications using it.
設計どおり、Diameter基本プロトコル[RFC6733]は2層プロトコルと見なすことができます。下位層は主に、隣接するピア間の接続の管理とメッセージのルーティングを担当します。上位層は、Diameterアプリケーションが存在する場所です。このモデルは、アプリケーションレイヤーとピアツーピア配信レイヤーを持つDiameterノードと一致しています。 Diameter基本プロトコルドキュメントは、メッセージ配信層のアーキテクチャと動作を定義し、アプリケーション層でDiameterアプリケーションを設計するためのフレームワークを提供します。このフレームワークには、アプリケーションセッションと会計サポートの定義が含まれています（[RFC6733]のセクション8と9を参照）。したがって、このドキュメントでは、Diameterノードは、Diameterメッセージ配信層の単一のインスタンスおよびそれを使用する1つ以上のDiameterアプリケーションと見なされます。
The Diameter base protocol is designed to be extensible and the principles are described in Section 1.3 of [RFC6733]. In summary, Diameter can be extended by the following:
Diameter基本プロトコルは拡張可能に設計されており、その原理は[RFC6733]のセクション1.3で説明されています。要約すると、Diameterは次のように拡張できます。
1. Defining new AVP values
1. 新しいAVP値の定義
2. Creating new AVPs
2. 新しいAVPの作成
3. Creating new commands
3. 新しいコマンドを作成する
4. Creating new applications As a main guiding principle, application designers SHOULD comply with the following recommendation: "try to reuse as much as possible!". It will reduce the time to finalize specification writing, and it will lead to a smaller implementation effort as well as reduce the need for testing. In general, it is clever to avoid duplicate effort when possible.
4.新しいアプリケーションの作成主な指針として、アプリケーション設計者は、次の推奨事項に準拠する必要があります（SHOULD）。「可能な限り再利用してください！」。これにより、仕様の作成を完了する時間が短縮され、実装の労力が軽減されるだけでなく、テストの必要性も減少します。一般に、可能な場合は重複した作業を回避するのが賢明です。
However, reuse is not appropriate when the existing functionality does not fit the new requirement and/or the reuse leads to ambiguity.
ただし、既存の機能が新しい要件に適合しない場合や再利用によって曖昧さが生じる場合は、再利用は適切ではありません。
The impact on extending existing applications can be categorized into two groups:
既存のアプリケーションの拡張への影響は、次の2つのグループに分類できます。
Minor Extension: Enhancing the functional scope of an existing application by the addition of optional features to support it. Such enhancement has no backward-compatibility issue with the existing application.
マイナー拡張：オプションの機能を追加してサポートすることにより、既存のアプリケーションの機能範囲を拡張します。このような拡張機能には、既存のアプリケーションとの下位互換性の問題はありません。
A typical example would be the definition of a new optional AVP for use in an existing command. Diameter implementations supporting the existing application but not the new AVP will simply ignore it, without consequences for the Diameter message handling, as described in [RFC6733]. The standardization effort will be fairly small.
典型的な例は、既存のコマンドで使用するための新しいオプションのAVPの定義です。 [RFC6733]で説明されているように、Diameterの実装は既存のアプリケーションをサポートしますが、新しいAVPはサポートしませんが、Diameterメッセージ処理に影響を与えることなく単に無視します。標準化の努力はかなり小さいでしょう。
Major Extension: Enhancing an application that requires the definition of a new Diameter application. Such enhancement causes a backward-compatibility issue with existing implementations supporting the application.
主な拡張：新しいDiameterアプリケーションの定義を必要とするアプリケーションを拡張します。このような機能拡張により、アプリケーションをサポートする既存の実装との下位互換性の問題が発生します。
Typical examples would be the creation of a new command for providing functionality not supported by existing applications or the definition of a new AVP to be carried in an existing command with the M-bit set in the AVP flags (see Section 4.1 of [RFC6733] for definition of "M-bit"). For such an extension, a significant specification effort is required, and a careful approach is recommended.
典型的な例は、既存のアプリケーションでサポートされていない機能を提供するための新しいコマンドの作成、またはAVPフラグにMビットが設定された既存のコマンドで実行される新しいAVPの定義です（[RFC6733]のセクション4.1を参照）。 「Mビット」の定義については）。そのような拡張については、かなりの仕様の努力が必要であり、注意深いアプローチが推奨されます。
An existing application may need to be enhanced to fulfill new requirements, and these modifications can be at the command level and/or at the AVP level. The following sections describe the possible modifications that can be performed on existing applications and their related impact.
新しい要件を満たすために既存のアプリケーションを拡張する必要がある場合があり、これらの変更はコマンドレベルまたはAVPレベル、あるいはその両方で行うことができます。次のセクションでは、既存のアプリケーションで実行可能な変更とそれに関連する影響について説明します。
Adding a new command to an existing application is considered to be a major extension and requires a new Diameter application to be defined, as stated in Section 1.3.4 of [RFC6733]. The need for a new application is because a Diameter node that is not upgraded to support the new command(s) within the (existing) application would reject any unknown command with the protocol error DIAMETER_COMMAND_UNSUPPORTED and cause the failure of the transaction. The new application ensures that Diameter nodes only receive commands within the context of applications they support.
[RFC6733]のセクション1.3.4に記載されているように、既存のアプリケーションに新しいコマンドを追加することは主要な拡張と見なされ、新しいDiameterアプリケーションを定義する必要があります。新しいアプリケーションの必要性は、（既存の）アプリケーション内の新しいコマンドをサポートするようにアップグレードされていないDiameterノードが、プロトコルエラーDIAMETER_COMMAND_UNSUPPORTEDのある不明なコマンドを拒否し、トランザクションの失敗を引き起こすためです。新しいアプリケーションは、Diameterノードがサポートするアプリケーションのコンテキスト内でのみコマンドを受信するようにします。
Adding a new command means either defining a completely new command or importing the command's Command Code Format (CCF) syntax from another application whereby the new application inherits some or all of the functionality of the application from which the command came. In the former case, the decision to create a new application is straightforward, since this is typically a result of adding a new functionality that does not exist yet. For the latter, the decision to create a new application will depend on whether importing the command in a new application is more suitable than simply using the existing application as it is in conjunction with any other application.
新しいコマンドを追加するということは、完全に新しいコマンドを定義するか、別のアプリケーションからコマンドのコマンドコード形式（CCF）構文をインポートして、新しいアプリケーションがコマンドの送信元のアプリケーションの機能の一部またはすべてを継承することを意味します。前者の場合、これは通常、まだ存在しない新しい機能を追加した結果であるため、新しいアプリケーションを作成する決定は簡単です。後者の場合、新しいアプリケーションを作成するかどうかの決定は、他のアプリケーションと組み合わせて既存のアプリケーションを使用するよりも、新しいアプリケーションにコマンドをインポートする方が適しているかどうかによって異なります。
An example considers the Diameter Extensible Authentication Protocol (EAP) application [RFC4072] and the Diameter Network Access Server application [RFC7155]. When network access authentication using EAP is required, the Diameter EAP commands (Diameter-EAP-Request/ Diameter-EAP-Answer) are used; otherwise, the Diameter Network Access Server application will be used. When the Diameter EAP application is used, the accounting exchanges defined in the Diameter Network Access Server may be used.
例では、Diameter拡張認証プロトコル（EAP）アプリケーション[RFC4072]とDiameterネットワークアクセスサーバーアプリケーション[RFC7155]を検討します。 EAPを使用したネットワークアクセス認証が必要な場合、Diameter EAPコマンド（Diameter-EAP-Request / Diameter-EAP-Answer）が使用されます。それ以外の場合は、Diameterネットワークアクセスサーバーアプリケーションが使用されます。 Diameter EAPアプリケーションを使用する場合、Diameterネットワークアクセスサーバーで定義されたアカウンティング交換を使用できます。
However, in general, it is difficult to come to a hard guideline, and so a case-by-case study of each application requirement should be applied. Before adding or importing a command, application designers should consider the following:
ただし、一般に、ハードガイドラインに到達することは困難であるため、各アプリケーション要件のケースバイケースの調査を適用する必要があります。コマンドを追加またはインポートする前に、アプリケーション設計者は次のことを考慮する必要があります。
o Can the new functionality be fulfilled by creating a new command independent from any existing command? In this case, the resulting new application and the existing application can work independent of, but cooperating with, each other.
o 既存のコマンドから独立した新しいコマンドを作成することにより、新しい機能を実現できますか？この場合、結果の新しいアプリケーションと既存のアプリケーションは、互いに独立して動作しますが、互いに連携します。
o Can the existing command be reused without major extensions and, therefore, without the need for the definition of a new application, e.g., new functionality introduced by the creation of new optional AVPs.
o 既存のコマンドを大きな拡張なしで再利用できますか？したがって、新しいオプションのAVPの作成によって導入された新しい機能など、新しいアプリケーションを定義する必要はありませんか？
It is important to note that importing commands too liberally could result in a monolithic and hard-to-manage application supporting too many different features.
コマンドを過剰にインポートすると、モノリシックで管理が難しいアプリケーションが多すぎる機能をサポートする可能性があることに注意することが重要です。
Although this process is not typical, removing a command from an application requires a new Diameter application to be defined, and then it is considered as a major extension. This is due to the fact that the reception of the deleted command would systematically result in a protocol error (i.e., DIAMETER_COMMAND_UNSUPPORTED).
このプロセスは一般的ではありませんが、アプリケーションからコマンドを削除するには、新しいDiameterアプリケーションを定義する必要があり、それが主要な拡張機能と見なされます。これは、削除されたコマンドを受信すると、体系的にプロトコルエラーが発生するためです（DIAMETER_COMMAND_UNSUPPORTEDなど）。
It is unusual to delete an existing command from an application for the sake of deleting it or the functionality it represents. An exception might be if the intent of the deletion is to create a newer variance of the same application that is somehow simpler than the application initially specified.
コマンドまたはそれが表す機能を削除するために、アプリケーションから既存のコマンドを削除することは珍しいことです。例外は、削除の目的が、最初に指定されたアプリケーションよりも多少単純な、同じアプリケーションの新しい差異を作成することである場合があります。
This section discusses rules in adding and/or deleting AVPs from an existing command of an existing application. The cases described in this section may not necessarily result in the creation of new applications.
このセクションでは、既存のアプリケーションの既存のコマンドからAVPを追加または削除する際のルールについて説明します。このセクションで説明されているケースでは、必ずしも新しいアプリケーションが作成されるとは限りません。
From a historical point of view, it is worth noting that there was a strong recommendation to reuse existing commands in [RFC3588] to prevent rapid depletion of code values available for vendor-specific commands. However, [RFC6733] has relaxed the allocation policy and enlarged the range of available code values for vendor-specific applications. Although reuse of existing commands is still RECOMMENDED, protocol designers can consider defining a new command when it provides a solution more suitable than the twisting of an existing command's use and applications.
歴史的な観点から、ベンダー固有のコマンドで利用可能なコード値の急速な枯渇を防ぐために、[RFC3588]で既存のコマンドを再利用することを強く推奨したことは注目に値します。ただし、[RFC6733]は割り当てポリシーを緩和し、ベンダー固有のアプリケーションで使用可能なコード値の範囲を拡大しました。既存のコマンドの再利用は引き続き推奨されますが、プロトコルの設計者は、既存のコマンドの用途やアプリケーションを変更するよりも適切なソリューションを提供する場合、新しいコマンドの定義を検討できます。
Based on the rules in [RFC6733], AVPs that are added to an existing command can be categorized as either:
[RFC6733]のルールに基づいて、既存のコマンドに追加されたAVPは、次のいずれかに分類できます。
o Mandatory (to understand) AVPs. As defined in [RFC6733], these are AVPs with the M-bit flag set in this command, which means that the Diameter node receiving them is required to understand not only their values but also their semantics. Failure to do so will cause a message handling error: either an error message with the result-code set to DIAMETER_AVP_UNSUPPORTED if the AVP is not understood in a request or an application-specific error handling if the given AVP is in an answer.
o 必須の（理解する）AVP。 [RFC6733]で定義されているように、これらはこのコマンドでMビットフラグが設定されたAVPです。つまり、それらを受信するDiameterノードは、値だけでなくセマンティクスも理解する必要があります。そうしないと、メッセージ処理エラーが発生します。AVPが要求で理解されない場合は結果コードがDIAMETER_AVP_UNSUPPORTEDに設定されたエラーメッセージ、または指定されたAVPが応答にある場合はアプリケーション固有のエラー処理のいずれかです。
o Optional (to understand) AVPs. As defined in [RFC6733], these are AVPs with the M-bit flag cleared in this command. A Diameter node receiving these AVPs can simply ignore them if it does not support them.
o オプション（理解）AVP。 [RFC6733]で定義されているように、これらはこのコマンドでMビットフラグがクリアされたAVPです。これらのAVPを受信するDiameterノードは、それらをサポートしていない場合は単に無視できます。
It is important to note that the definitions given above are independent of whether these AVPs are required or optional in the command as specified by the command's CCF syntax [RFC6733].
上記の定義は、コマンドのCCF構文[RFC6733]で指定されているように、これらのAVPがコマンドで必須かオプションかに依存しないことに注意することが重要です。
NOTE: As stated in [RFC6733], the M-bit setting for a given AVP is relevant to an application and each command within that application that includes the AVP.
注：[RFC6733]で述べられているように、特定のAVPのMビット設定は、アプリケーションと、AVPを含むそのアプリケーション内の各コマンドに関連しています。
The rules are strict in the case where the AVPs to be added in an exiting command are mandatory to understand, i.e., they have the M-bit set. A mandatory AVP MUST NOT be added to an existing command without defining a new Diameter application, as stated in [RFC6733]. This falls into the "Major Extensions" category. Despite the clarity of the rule, ambiguity still arises when evaluating whether a new AVP being added should be mandatory to begin with. Application designers should consider the following questions when deciding about the M-bit for a new AVP:
ルールは、既存のコマンドに追加されるAVPが理解するために必須である場合、つまり、それらにMビットが設定されている場合に厳格です。 [RFC6733]で述べられているように、新しいDiameterアプリケーションを定義せずに、必須のAVPを既存のコマンドに追加してはなりません（MUST NOT）。これは「主要な拡張機能」カテゴリに分類されます。ルールが明確であるにもかかわらず、追加する新しいAVPがそもそも必須であるかどうかを評価する場合、あいまいさが依然として発生します。アプリケーション設計者は、新しいAVPのMビットについて決定するときに、次の質問を検討する必要があります。
o Would it be required for the receiving side to be able to process and understand the AVP and its content?
o 受信側がAVPとそのコンテンツを処理して理解できる必要がありますか？
o Would the new AVPs change the state machine of the application?
o 新しいAVPはアプリケーションのステートマシンを変更しますか？
o Would the presence of the new AVP lead to a different number of round trips, effectively changing the state machine of the application?
o 新しいAVPが存在すると、ラウンドトリップの数が異なり、アプリケーションのステートマシンが効果的に変更されますか？
o Would the new AVP be used to differentiate between old and new variances of the same application whereby the two variances are not backward compatible?
o 新しいAVPを使用して、同じアプリケーションの古い分散と新しい分散を区別し、2つの分散に下位互換性がないようにしますか？
o Would the new AVP have duality in meaning, i.e., be used to carry application-related information as well as to indicate that the message is for a new application?
o 新しいAVPには意味の二重性がありますか？つまり、アプリケーション関連の情報を運ぶために使用され、メッセージが新しいアプリケーション用であることを示しますか？
If the answer to at least one of the questions is "yes", then the M-bit MUST be set for the new AVP, and a new Diameter application MUST be defined. This list of questions is non-exhaustive, and other criteria MAY be taken into account in the decision process.
少なくとも1つの質問に対する答えが「はい」の場合、Mビットを新しいAVPに設定する必要があり、新しいDiameterアプリケーションを定義する必要があります。この質問のリストは網羅的なものではなく、他の基準が決定プロセスで考慮される場合があります。
If application designers are instead contemplating the use of optional AVPs, i.e., with the M-bit cleared, there are still pitfalls that will cause interoperability problems; therefore, they must be avoided. Some examples of these pitfalls are as follows:
アプリケーション設計者が代わりにオプションのAVPの使用を検討している場合、つまりMビットがクリアされている場合でも、相互運用性の問題を引き起こす落とし穴があります。したがって、それらは回避する必要があります。これらの落とし穴のいくつかの例は次のとおりです。
o Use of optional AVPs with intersecting meaning. One AVP has partially the same usage and meaning as another AVP. The presence of both can lead to confusion.
o 交差する意味を持つオプションのAVPの使用。 1つのAVPの使用法と意味は、別のAVPと部分的に同じです。両方が存在すると混乱が生じる可能性があります。
o Optional AVPs with dual purpose, i.e., to carry application data as well as to indicate support for one or more features. This has a tendency to introduce interpretation issues.
o アプリケーションデータを運ぶだけでなく、1つまたは複数の機能のサポートを示すという二重の目的を持つオプションのAVP。これは解釈の問題を導入する傾向があります。
o Adding one or more optional AVPs and indicating (usually within descriptive text for the command) that at least one of them has to be understood by the receiver of the command. This would be equivalent to adding a mandatory AVP, i.e., an AVP with the M-bit set, to the command.
o 1つ以上のオプションのAVPを追加し、それらの少なくとも1つをコマンドの受信者が理解する必要があることを（通常はコマンドの説明テキスト内に）示します。これは、必須のAVP、つまりMビットが設定されたAVPをコマンドに追加することと同じです。
Application designers may want to reuse an existing command, but some of the AVPs present in the command's CCF syntax specification may be irrelevant for the functionality foreseen to be supported by this command. It may be then tempting to delete those AVPs from the command.
アプリケーション設計者は既存のコマンドを再利用したいと思うかもしれませんが、コマンドのCCF構文仕様に存在する一部のAVPは、このコマンドでサポートされることが予測される機能とは無関係である場合があります。次に、それらのAVPをコマンドから削除したくなるかもしれません。
The impacts of deleting an AVP from a command depends on its Command Code format specification and M-bit setting:
コマンドからAVPを削除した場合の影響は、コマンドコード形式の仕様とMビット設定によって異なります。
o Case 1: Deleting an AVP that is indicated as a required AVP (noted as {AVP}) in the command's CCF syntax specification (regardless of the M-bit setting).
o ケース1：コマンドのCCF構文仕様で必要なAVP（{AVP}と表記）として示されているAVPを削除する（Mビットの設定に関係なく）。
In this case, a new Command Code, and subsequently a new Diameter application, MUST be specified.
この場合、新しいコマンドコードを指定し、続いて新しいDiameterアプリケーションを指定する必要があります。
o Case 2: Deleting an AVP, which has the M-bit set, and is indicated as an optional AVP (noted as [AVP] in the command CCF) in the command's CCF syntax specification.
o ケース2：コマンドのCCF構文仕様で、Mビットが設定され、オプションのAVP（コマンドCCFでは[AVP]と表記）として示されているAVPを削除する。
In this case, no new Command Code has to be specified, but the definition of a new Diameter application is REQUIRED.
この場合、新しいコマンドコードを指定する必要はありませんが、新しいDiameterアプリケーションの定義が必要です。
o Case 3: Deleting an AVP, which has the M-bit cleared, and is indicated as [AVP] in the command's CCF syntax specification.
o ケース3：Mビットがクリアされ、コマンドのCCF構文仕様で[AVP]と示されているAVPを削除する。
In this case, the AVP can be deleted without consequences.
この場合、AVPは問題なく削除できます。
Application designers SHOULD attempt to reuse the command's CCF syntax specification without modification and simply ignore (but not delete) any optional AVPs that will not be used. This is to maintain compatibility with existing applications that will not know about the new functionality as well as to maintain the integrity of existing dictionaries.
アプリケーション設計者は、変更せずにコマンドのCCF構文仕様を再利用し、使用されないオプションのAVPを単に無視する（ただし削除しない）ようにする必要があります（SHOULD）。これは、新しい機能を認識しない既存のアプリケーションとの互換性を維持し、既存の辞書の整合性を維持するためです。
Although unusual, implementors may want to change the setting of the AVP flags a given AVP used in a command.
通常ではありませんが、実装者は、コマンドで使用される特定のAVPのAVPフラグの設定を変更したい場合があります。
Into an existing command, an AVP that was initially defined as a mandatory AVP to understand, i.e., an AVP with the M-bit flag set in the command MAY be safely turned to an optional AVP, i.e., with the M-bit cleared. Any node supporting the existing application will still understand the AVP, whatever the setting of the M-bit. On the contrary, an AVP initially defined as an optional AVP to understand, i.e., an AVP with the M-bit flag cleared in the command MUST NOT be changed into a mandatory AVP with the M-bit flag set without defining a new Diameter application. Setting the M-bit for an AVP that was defined as an optional AVP is equivalent to adding a new mandatory AVP to an existing command, and the rules given in Section 4.3.1 apply.
既存のコマンドでは、理解するために必須のAVPとして最初に定義されたAVP、つまり、コマンドでMビットフラグが設定されたAVPをオプションのAVPに安全に変換できます（Mビットをクリアした状態）。既存のアプリケーションをサポートするノードは、Mビットの設定に関係なく、引き続きAVPを理解します。逆に、最初に理解するオプションのAVPとして定義されたAVP、つまり、コマンドでMビットフラグがクリアされたAVPは、新しいDiameterアプリケーションを定義せずにMビットフラグが設定された必須AVPに変更してはなりません（MUST NOT）。 。オプションのAVPとして定義されたAVPのMビットを設定することは、既存のコマンドに新しい必須のAVPを追加することと同等であり、セクション4.3.1に記載されているルールが適用されます。
All other AVP flags (V-bit, P-bit, reserved bits) MUST remain unchanged.
他のすべてのAVPフラグ（Vビット、Pビット、予約ビット）は変更しないでください。
This section discusses rules in reusing existing AVPs when reusing an existing command or defining a new command in a new application.
このセクションでは、既存のコマンドを再利用するとき、または新しいアプリケーションで新しいコマンドを定義するときに、既存のAVPを再利用する際のルールについて説明します。
When reusing existing AVPs in a new application, application designers MUST specify the setting of the M-bit flag for a new Diameter application and, if necessary, for every command of the application that can carry these AVPs. In general, for AVPs defined outside of the Diameter base protocol, the characteristics of an AVP are tied to its role within a given application and the commands used in this application.
新しいアプリケーションで既存のAVPを再利用する場合、アプリケーション設計者は、新しいDiameterアプリケーションのMビットフラグの設定を指定する必要があり、必要に応じて、これらのAVPを伝送できるアプリケーションのすべてのコマンドに指定する必要があります。一般に、Diameter基本プロトコルの外部で定義されたAVPの場合、AVPの特性は、特定のアプリケーション内での役割と、このアプリケーションで使用されるコマンドに関連付けられています。
All other AVP flags (V-bit, P-bit, reserved bits) MUST remain unchanged.
他のすべてのAVPフラグ（Vビット、Pビット、予約ビット）は変更しないでください。
When reusing an AVP of type Enumerated in a command for a new application, it is RECOMMENDED to avoid modifying the set of valid values defined for this AVP. Modifying the set of Enumerated values includes adding a value or deprecating the use of a value defined initially for the AVP. Modifying the set of values will impact the application defining this AVP and all the applications using this AVP, causing potential interoperability issues: a value used by a peer that will not be recognized by all the nodes between the client and the server will cause an error response with the Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE. When the full range of values defined for this Enumerated AVP is not suitable for the new application, it is RECOMMENDED that a new AVP be defined to avoid backward-compatibility issues with existing implementations.
新しいアプリケーションのコマンドでEnumeratedタイプのAVPを再利用する場合、このAVPに定義されている有効な値のセットを変更しないようにすることをお勧めします。列挙値のセットの変更には、値の追加、またはAVPに対して最初に定義された値の使用の廃止が含まれます。値のセットを変更すると、このAVPを定義するアプリケーションとこのAVPを使用するすべてのアプリケーションに影響を及ぼし、相互運用性の問題が発生する可能性があります。クライアントとサーバー間のすべてのノードで認識されないピアが使用する値は、エラーの原因になりますResult-Code AVPがDIAMETER_INVALID_AVP_VALUEに設定された応答。この列挙型AVPに定義されている値の全範囲が新しいアプリケーションに適していない場合は、既存の実装との下位互換性の問題を回避するために新しいAVPを定義することをお勧めします。
This section discusses the case where new applications have requirements that cannot be fulfilled by existing applications and would require definition of completely new commands, AVPs, and/or AVP values. Typically, there is little ambiguity about the decision to create these types of applications. Some examples are the interfaces defined for the IP Multimedia Subsystem of 3GPP, e.g., Cx/Dx ([TS29.228] and [TS29.229]), Sh ([TS29.328] and [TS29.329]), etc.
このセクションでは、新しいアプリケーションに、既存のアプリケーションでは満たすことができない要件があり、まったく新しいコマンド、AVP、AVP値の定義が必要になる場合について説明します。通常、これらのタイプのアプリケーションを作成する決定については、曖昧さがほとんどありません。いくつかの例は、3GPPのIPマルチメディアサブシステム用に定義されたインターフェースです。たとえば、Cx / Dx（[TS29.228]および[TS29.229]）、Sh（[TS29.328]および[TS29.329]）などです。
Application designers SHOULD try to import existing AVPs and AVP values for any newly defined commands. In certain cases where accounting will be used, the models described in Section 5.10 SHOULD also be considered.
アプリケーション設計者は、新しく定義されたコマンドの既存のAVPとAVP値をインポートする必要があります。アカウンティングが使用される特定のケースでは、セクション5.10で説明されているモデルも考慮されるべきです（SHOULD）。
Additional considerations are described in the following sections.
次のセクションでは、追加の考慮事項について説明します。
As a general recommendation, commands SHOULD NOT be defined from scratch. It is instead RECOMMENDED to reuse an existing command offering similar functionality and use it as a starting point. Code reuse leads to a smaller implementation effort as well as reduces the need for testing.
一般的な推奨事項として、コマンドは最初から定義すべきではありません（SHOULD NOT）。代わりに、同様の機能を提供する既存のコマンドを再利用し、それを開始点として使用することをお勧めします。コードの再利用は、実装の労力を軽減し、テストの必要性を減らします。
Moreover, the new command's CCF syntax specification SHOULD be carefully defined when considering applicability and extensibility of the application. If most of the AVPs contained in the command are indicated as fixed or required, it might be difficult to reuse the same command and, therefore, the same application in a slightly changed environment. Defining a command with most of the AVPs indicated as optional is considered as a good design choice in many cases, despite the flexibility it introduces in the protocol. Protocol designers MUST clearly state the reasons why these optional AVPs might or might not be present and properly define the corresponding behavior of the Diameter nodes when these AVPs are absent from the command.
さらに、新しいコマンドのCCF構文仕様は、アプリケーションの適用性と拡張性を検討するときに慎重に定義する必要があります。コマンドに含まれているAVPのほとんどが修正済みまたは必須として示されている場合、同じコマンドを再利用することが難しいため、わずかに変更された環境で同じアプリケーションを再利用できません。ほとんどのAVPがオプションとして示されているコマンドを定義することは、プロトコルに導入された柔軟性にもかかわらず、多くの場合、優れた設計の選択と見なされます。プロトコル設計者は、これらのオプションのAVPが存在する場合と存在しない場合がある理由を明確に示し、これらのAVPがコマンドに存在しない場合のDiameterノードの対応する動作を適切に定義する必要があります。
NOTE: As a hint for protocol designers, it is not sufficient to just look at the command's CCF syntax specification. It is also necessary to carefully read through the accompanying text in the specification.
注：プロトコル設計者へのヒントとして、コマンドのCCF構文仕様を見るだけでは不十分です。また、仕様書の添付テキストを注意深く読む必要があります。
In the same way, the CCF syntax specification SHOULD be defined such that it will be possible to add any arbitrary optional AVPs with the M-bit cleared (including vendor-specific AVPs) without modifying the application. For this purpose, "* [AVP]" SHOULD be added in the command's CCF, which allows the addition of any arbitrary number of optional AVPs as described in [RFC6733].
同様に、CCF構文仕様は、アプリケーションを変更せずにMビットがクリアされた任意のオプションのAVP（ベンダー固有のAVPを含む）を追加できるように定義する必要があります（SHOULD）。この目的のために、コマンドのCCFに「* [AVP]」を追加する必要があります。これにより、[RFC6733]で説明されているように、任意の数のオプションのAVPを追加できます。
When designing new applications, application designers SHOULD specify that the Application Id carried in all session-level messages is the Application Id of the application using those messages. This includes the session-level messages defined in the Diameter base protocol, i.e., Re-Auth-Request (RAR) / Re-Auth-Answer (RAA), Session-Termination-Request (STR) / Session-Termination-Answer (STA), Abort-Session-Request (ASR) / Abort-Session-Answer (ASA), and possibly Accounting-Request (ACR) / Accounting Answer (ACA) in the coupled accounting model; see Section 5.10. Some existing specifications do not adhere to this rule for historical reasons. However, this guidance SHOULD be followed by new applications to avoid routing problems.
新しいアプリケーションを設計するとき、アプリケーション設計者は、すべてのセッションレベルのメッセージで伝えられるアプリケーションIDが、それらのメッセージを使用するアプリケーションのアプリケーションIDであることを指定する必要があります（SHOULD）。これには、Diameter基本プロトコルで定義されたセッションレベルのメッセージが含まれます。つまり、Re-Auth-Request（RAR）/ Re-Auth-Answer（RAA）、Session-Termination-Request（STR）/ Session-Termination-Answer（STA ）、Abort-Session-Request（ASR）/ Abort-Session-Answer（ASA）、および場合によっては結合されたアカウンティングモデルのAccounting-Request（ACR）/ Accounting Answer（ACA）。セクション5.10を参照してください。一部の既存の仕様は、歴史的な理由からこのルールに準拠していません。ただし、ルーティングの問題を回避するために、このガイダンスには新しいアプリケーションが続く必要があります。
When a new application has been allocated with a new Application Id and it also reuses existing commands with or without modifications, the commands SHOULD use the newly allocated Application Id in the header and in all relevant Application-Id AVPs (Auth-Application-Id or Acct-Application-Id) present in the commands message body.
新しいアプリケーションが新しいアプリケーションIDで割り当てられ、既存のコマンドを変更の有無にかかわらず再利用する場合、コマンドは、ヘッダーと関連するすべてのApplication-Id AVP（Auth-Application-IdまたはAcct-Application-Id）は、コマンドメッセージ本文に含まれます。
Additionally, application designers using a vendor-specific Application-Id AVP SHOULD NOT use the Vendor-Id AVP to further dissect or differentiate the vendor-specification Application Id. Diameter routing is not based on the Vendor Id. As such, the Vendor Id SHOULD NOT be used as an additional input for routing or delivery of messages. The Vendor-Id AVP is an informational AVP only and kept for backward compatibility reasons.
さらに、ベンダー固有のApplication-Id AVPを使用するアプリケーション設計者は、ベンダー固有のアプリケーションIDをさらに分析または区別するためにVendor-Id AVPを使用しないでください。 DiameterルーティングはベンダーIDに基づいていません。そのため、ベンダーIDは、メッセージのルーティングまたは配信の追加入力として使用してはなりません（SHOULD NOT）。 Vendor-Id AVPは情報提供のみのAVPであり、下位互換性のために保持されています。
Section 8 of [RFC6733] provides session state machines for AAA services, and these session state machines are not intended to cover behavior outside of AAA. If a new application cannot clearly be categorized into any of these AAA services, it is RECOMMENDED that the application define its own session state machine. Support for a server-initiated request is a clear example where an application-specific session state machine would be needed, for example, the Rw interface for the ITU-T push model (cf. [Q.3303.3]).
[RFC6733]のセクション8は、AAAサービス用のセッションステートマシンを提供します。これらのセッションステートマシンは、AAA以外の動作をカバーすることを意図していません。新しいアプリケーションをこれらのAAAサービスのいずれかに明確に分類できない場合は、アプリケーションが独自のセッションステートマシンを定義することをお勧めします。サーバー開始要求のサポートは、アプリケーション固有のセッションステートマシンが必要になる明確な例です。たとえば、ITU-TプッシュモデルのRwインターフェイス（[Q.3303.3]を参照）です。
Diameter applications are usually designed with the aim of managing user sessions (e.g., Diameter Network Access Server (NAS) application [RFC4005]) or a specific service access session (e.g., Diameter SIP application [RFC4740]). In the Diameter base protocol, session state is referenced using the Session-Id AVP. All Diameter messages that use the same Session-Id will be bound to the same session. Diameter-based session management also implies that both the Diameter client and server (and potentially proxy agents along the path) maintain session state information.
Diameterアプリケーションは通常、ユーザーセッション（Diameterネットワークアクセスサーバー（NAS）アプリケーション[RFC4005]など）または特定のサービスアクセスセッション（Diameter SIPアプリケーション[RFC4740]など）の管理を目的として設計されています。 Diameter基本プロトコルでは、セッション状態はSession-Id AVPを使用して参照されます。同じSession-Idを使用するすべてのDiameterメッセージは、同じセッションにバインドされます。 Diameterベースのセッション管理では、Diameterクライアントとサーバー（およびパス上のプロキシエージェント）の両方がセッション状態情報を保持することも意味します。
However, some applications may not need to rely on the Session-Id to identify and manage sessions because other information can be used instead to correlate Diameter messages. Indeed, the User-Name AVP or any other specific AVP can be present in every Diameter message and used, therefore, for message correlation. Some applications might not require the notion of the Diameter-session concept at all. For such applications, the Auth-Session-State AVP is usually set to NO_STATE_MAINTAINED in all Diameter messages, and these applications are, therefore, designed as a set of stand-alone transactions. Even if an explicit access session termination is required, application-specific commands are defined and used instead of the STR/STA or ASR/ ASA defined in the Diameter base protocol [RFC6733]. In such a case, the Session-Id is not significant.
ただし、他の情報を使用してDiameterメッセージを関連付けることができるため、一部のアプリケーションでは、Session-Idに依存してセッションを識別および管理する必要がない場合があります。実際、ユーザー名AVPまたはその他の特定のAVPは、すべてのDiameterメッセージに存在し、メッセージの相関に使用できます。一部のアプリケーションでは、Diameterセッションの概念の概念をまったく必要としない場合があります。このようなアプリケーションの場合、通常、すべてのDiameterメッセージでAuth-Session-State AVPがNO_STATE_MAINTAINEDに設定されるため、これらのアプリケーションはスタンドアロントランザクションのセットとして設計されています。明示的なアクセスセッションの終了が必要な場合でも、Diameter基本プロトコル[RFC6733]で定義されているSTR / STAまたはASR / ASAの代わりに、アプリケーション固有のコマンドが定義および使用されます。このような場合、Session-Idは重要ではありません。
Based on these considerations, protocol designers should carefully appraise whether the Diameter application being defined relies on the session management specified in the Diameter base protocol:
これらの考慮事項に基づいて、プロトコル設計者は、定義されているDiameterアプリケーションがDiameter基本プロトコルで指定されたセッション管理に依存しているかどうかを慎重に評価する必要があります。
o If it is, the Diameter command defined for the new application MUST include the Session-Id AVP defined in the Diameter base protocol [RFC6733], and the Session-Id AVP MUST be used for correlation of messages related to the same session. Guidance on the use of the Auth-Session-State AVP is given in the Diameter base protocol [RFC6733].
o そうである場合、新しいアプリケーション用に定義されたDiameterコマンドには、Diameter基本プロトコル[RFC6733]で定義されたSession-Id AVPを含める必要があり、同じセッションに関連するメッセージの相関にSession-Id AVPを使用する必要があります。 Auth-Session-State AVPの使用に関するガイダンスは、Diameter基本プロトコル[RFC6733]で提供されています。
o Otherwise, because session management is not required or the application relies on its own session management mechanism, Diameter commands for the application need not include the Session-Id AVP. If any specific session management concept is supported by the application, the application documentation MUST clearly specify how the session is handled between the client and server (and possibly Diameter agents in the path). Moreover, because the application is not maintaining session state at the Diameter base protocol level, the Auth-Session-State AVP MUST be included in all Diameter commands for the application and MUST be set to NO_STATE_MAINTAINED.
o それ以外の場合は、セッション管理が不要であるか、アプリケーションが独自のセッション管理メカニズムに依存しているため、アプリケーションのDiameterコマンドにSession-Id AVPを含める必要はありません。特定のセッション管理の概念がアプリケーションでサポートされている場合、アプリケーションのドキュメントでは、クライアントとサーバー（および場合によってはパス内のDiameterエージェント）間のセッションの処理方法を明確に指定する必要があります。さらに、アプリケーションはDiameter基本プロトコルレベルでセッション状態を維持していないため、Auth-Session-State AVPをアプリケーションのすべてのDiameterコマンドに含める必要があり、NO_STATE_MAINTAINEDに設定する必要があります。
The type Enumerated was initially defined to provide a list of valid values for an AVP with their respective interpretation described in the specification. For instance, AVPs of type Enumerated can be used to provide further information on the reason for the termination of a session or a specific action to perform upon the reception of the request.
Enumeratedタイプは、AVPの有効な値のリストと、仕様で説明されているそれぞれの解釈を提供するために最初に定義されました。たとえば、タイプEnumeratedのAVPを使用して、セッションの終了の理由や、要求の受信時に実行する特定のアクションに関する詳細情報を提供できます。
As described in Section 4.4.2 above, defining an AVP of type Enumerated presents some limitations in terms of extensibility and reusability. Indeed, the finite set of valid values defined in the definition of the AVP of type Enumerated cannot be modified in practice without causing backward-compatibility issues with existing implementations. As a consequence, AVPs of type Enumerated MUST NOT be extended by adding new values to support new capabilities. Diameter protocol designers SHOULD carefully consider before defining an Enumerated AVP whether the set of values will remain unchanged or new values may be required in the near future. If such an extension is foreseen or cannot be avoided, it is RECOMMENDED to define AVPs of type Unsigned32 or Unsigned64 in which the data field would contain an address space representing "values" that would have the same use of Enumerated values. Whereas only the initial values defined at the definition of the AVP of type Enumerated are valid as described in Section 4.4.2, any value from the address space from 0 to 2^32 - 1 for AVPs of type Unsigned32 or from 0 to 2^64 - 1 for AVPs of type Unsigned64 is valid at the Diameter base protocol level and will not cause interoperability issues for intermediary nodes between clients and servers. Only clients and servers will be able to process the values at the application layer.
上記のセクション4.4.2で説明したように、EnumeratedタイプのAVPを定義すると、拡張性と再利用性の点でいくつかの制限が生じます。実際、EnumeratedタイプのAVPの定義で定義されている有効な値の有限セットは、既存の実装との下位互換性の問題を引き起こさずに実際に変更することはできません。結果として、列挙型のAVPは、新しい機能をサポートするために新しい値を追加することによって拡張してはなりません（MUST NOT）。 Diameterプロトコル設計者は、列挙型AVPを定義する前に、値のセットが変更されないままか、近い将来に新しい値が必要になるかどうかを慎重に検討する必要があります。そのような拡張が予測されるか、回避できない場合は、列挙型の値を同じように使用する「値」を表すアドレススペースがデータフィールドに含まれるUnsigned32またはUnsigned64タイプのAVPを定義することをお勧めします。 EnumeratedタイプのAVPの定義で定義された初期値のみがセクション4.4.2で説明されているように有効ですが、Unsigned32タイプまたは0〜2 ^のAVPの場合、アドレス空間の0〜2 ^ 32-1の値はすべて有効です。タイプUnsigned64のAVPの64-1は、Diameter基本プロトコルレベルで有効であり、クライアントとサーバー間の中間ノードに相互運用性の問題を引き起こしません。クライアントとサーバーのみがアプリケーション層で値を処理できます。
For illustration, an AVP describing possible access networks would be defined as follows:
例として、可能なアクセスネットワークを記述するAVPは次のように定義されます。
Access-Network-Type AVP (XXX) is of type Unsigned32 and contains a 32-bit address space representing types of access networks. This application defines the following classes of access networks, all identified by the thousands digit in the decimal notation:
Access-Network-Type AVP（XXX）のタイプはUnsigned32で、アクセスネットワークのタイプを表す32ビットのアドレス空間が含まれています。このアプリケーションは、次のクラスのアクセスネットワークを定義します。これらはすべて、10進表記の数千桁で識別されます。
o 1xxx (Mobile Access Networks)
o 1xxx（モバイルアクセスネットワーク）
o 2xxx (Fixed Access Networks)
o 2xxx（固定アクセスネットワーク）
o 3xxx (Wireless Access Networks)
o 3xxx（ワイヤレスアクセスネットワーク）
Values that fall within the Mobile Access Networks category are used to inform a peer that a request has been sent for a user attached to a mobile access network. The following values are defined in this application:
モバイルアクセスネットワークのカテゴリに含まれる値は、モバイルアクセスネットワークに接続しているユーザーにリクエストが送信されたことをピアに通知するために使用されます。このアプリケーションでは、次の値が定義されています。
1001: 3GPP-GERAN
1001：素晴らしい
The user is attached to a Global System for Mobile Communications (GSM) Enhanced Data rates for GSM Evolution (EDGE) Radio Access Network.
ユーザーは、GSM Evolution（EDGE）無線アクセスネットワークのモバイルコミュニケーション（GSM）拡張データレートのグローバルシステムに接続されています。
1002: 3GPP-UTRAN-FDD
1002：3GPP-UTRAN-FDD
The user is attached to a Universal Mobile Telecommunications System (UMTS) access network that uses frequency-division duplexing for duplexing.
ユーザーは、二重化に周波数分割二重化を使用するUniversal Mobile Telecommunications System（UMTS）アクセスネットワークに接続しています。
Unlike Enumerated AVP, any new value can be added in the address space defined by this Unsigned32 AVP without modifying the definition of the AVP. There is, therefore, no risk of backward-compatibility issues, especially when intermediate nodes may be present between Diameter endpoints.
列挙型AVPとは異なり、AVPの定義を変更せずに、このUnsigned32 AVPによって定義されたアドレス空間に新しい値を追加できます。したがって、特にDiameterエンドポイント間に中間ノードが存在する場合は、下位互換性の問題のリスクはありません。
Along the same line, AVPs of type Enumerated are too often used as a simple Boolean flag, indicating, for instance, a specific permission or capability; therefore, only three values are defined, e.g., TRUE/ FALSE, AUTHORIZED/UNAUTHORIZED, or SUPPORTED/UNSUPPORTED. This is a sub-optimal design since it limits the extensibility of the application: any new capability/permission would have to be supported by a new AVP or new Enumerated value of the already-defined AVP, with the backward-compatibility issues described above. Instead of using an Enumerated AVP for a Boolean flag, protocol designers SHOULD use AVPs of type Unsigned32 or Unsigned64 in which the data field would be defined as a bit mask whose bit settings are described in the relevant Diameter application specification. Such AVPs can be reused and extended without major impact on the Diameter application. The bit mask SHOULD leave room for future additions. Examples of AVPs that use bit masks are the Session-Binding AVP defined in [RFC6733] and the MIP6-Feature-Vector AVP defined in [RFC5447].
同じように、EnumeratedタイプのAVPは単純なブールフラグとして頻繁に使用され、たとえば、特定の権限または機能を示します。したがって、3つの値、たとえば、TRUE / FALSE、AUTHORIZED / UNAUTHORIZED、またはSUPPORTED / UNSUPPORTEDのみが定義されます。これは、アプリケーションの拡張性を制限するため、次善の設計です。新しい機能/権限は、すでに定義されたAVPの新しいAVPまたは新しい列挙値によってサポートされる必要があり、上記の後方互換性の問題があります。ブールフラグに列挙型AVPを使用する代わりに、プロトコル設計者は、データフィールドが関連するDiameterアプリケーション仕様にビット設定が記述されているビットマスクとして定義されるタイプUnsigned32またはUnsigned64のAVPを使用する必要があります。このようなAVPは、Diameterアプリケーションに大きな影響を与えることなく、再利用および拡張できます。ビットマスクは、将来の追加のための余地を残してください。ビットマスクを使用するAVPの例は、[RFC6733]で定義されたセッションバインディングAVPと[RFC5447]で定義されたMIP6-Feature-Vector AVPです。
As described in [RFC6733], a Diameter request that needs to be sent to a home server serving a specific realm, but not to a specific server (such as the first request of a series of round trips), will contain a Destination-Realm AVP and no Destination-Host AVP.
[RFC6733]で説明されているように、特定のレルムを提供するホームサーバーに送信する必要があるが、特定のサーバーには送信しないDiameterリクエスト（一連の往復の最初のリクエストなど）には、Destination-Realmが含まれます。 AVPおよび宛先ホストAVPなし。
For such a request, the message routing usually relies only on the Destination-Realm AVP and the Application Id present in the request message header. However, some applications may need to rely on the User-Name AVP or any other application-specific AVPs present in the request to determine the final destination of a request, e.g., to find the target AAA server hosting the authorization information for a given user when multiple AAA servers are addressable in the realm.
このようなリクエストの場合、メッセージルーティングは通常、リクエストメッセージヘッダーにある宛先レルムAVPとアプリケーションIDのみに依存します。ただし、一部のアプリケーションは、リクエストに含まれるユーザー名AVPまたはその他のアプリケーション固有のAVPに依存して、リクエストの最終的な宛先を決定する必要がある場合があります。たとえば、特定のユーザーの認証情報をホストしているターゲットAAAサーバーを見つける場合などです。複数のAAAサーバーがレルムでアドレス可能である場合。
In such a context, basic routing mechanisms described in [RFC6733] are not fully suitable, and additional application-level routing mechanisms MUST be described in the application documentation to provide such specific AVP-based routing. Such functionality will be basically hosted by an application-specific proxy agent that will be responsible for routing decisions based on the received specific AVPs.
このような状況では、[RFC6733]で説明されている基本的なルーティングメカニズムは完全に適切ではなく、そのような特定のAVPベースのルーティングを提供するには、追加のアプリケーションレベルのルーティングメカニズムをアプリケーションのドキュメントで説明する必要があります。このような機能は基本的に、受信した特定のAVPに基づいてルーティングの決定を行うアプリケーション固有のプロキシエージェントによってホストされます。
Examples of such application-specific routing functions can be found in the Cx/Dx applications ([TS29.228] and [TS29.229]) of the 3GPP IP Multimedia Subsystem, in which the proxy agent (Subscriber Location Function, aka SLF) uses specific application-level identities found in the request to determine the final destination of the message.
このようなアプリケーション固有のルーティング機能の例は、3GPP IPマルチメディアサブシステムのCx / Dxアプリケーション（[TS29.228]および[TS29.229]）にあり、プロキシエージェント（Subscriber Location Function、別名SLF）が含まれています。リクエストで見つかった特定のアプリケーションレベルのIDを使用して、メッセージの最終的な送信先を決定します。
Whatever the criteria used to establish the routing path of the request, the routing of the answer MUST follow the reverse path of the request, as described in [RFC6733], with the answer being sent to the source of the received request, using transaction states and hop-by-hop identifier matching. This ensures that the Diameter relay or proxy agents in the request routing path will be able to release the transaction state upon receipt of the corresponding answer, avoiding unnecessary failover. Moreover, especially in roaming cases, proxy agents in the path must be able to apply local policies when receiving the answer from the server during authentication/ authorization and/or accounting procedures and maintain up-to-date session state information by keeping track of all authorized active sessions. Therefore, application designers MUST NOT modify the answer-routing principles described in [RFC6733] when defining a new application.
リクエストのルーティングパスを確立するために使用する基準が何であれ、[RFC6733]で説明されているように、応答のルーティングはリクエストのリバースパスに従い、トランザクション状態を使用して、受信したリクエストのソースに回答を送信する必要があります。ホップバイホップ識別子のマッチング。これにより、リクエストルーティングパス内のDiameterリレーまたはプロキシエージェントが、対応する回答を受信するとトランザクション状態を解放できるようになり、不要なフェイルオーバーが回避されます。さらに、特にローミングの場合、パス内のプロキシエージェントは、認証/承認および/またはアカウンティングの手順中にサーバーから回答を受信するときにローカルポリシーを適用し、すべてを追跡することで最新のセッション状態情報を維持できる必要があります。許可されたアクティブなセッション。したがって、アプリケーション設計者は、新しいアプリケーションを定義するときに、[RFC6733]で説明されている回答ルーティングの原則を変更してはなりません。
As defined in [RFC6733], a translation agent is a device that provides interworking between Diameter and another AAA protocol, such as RADIUS.
[RFC6733]で定義されているように、変換エージェントは、DiameterとRADIUSなどの別のAAAプロトコル間の相互作用を提供するデバイスです。
In the case of RADIUS, it was initially thought that defining the translation function would be straightforward by adopting a few basic principles, e.g., by the use of a shared range of code values for RADIUS attributes and Diameter AVPs. Guidelines for implementing a RADIUS-Diameter translation agent were put into the Diameter NAS Application [RFC4005].
RADIUSの場合、RADIUS属性とDiameter AVPのコード値の共有範囲を使用するなど、いくつかの基本原則を採用することにより、変換関数の定義は簡単になると当初は考えられていました。 RADIUS-Diameter変換エージェントを実装するためのガイドラインは、Diameter NASアプリケーション[RFC4005]に組み込まれました。
However, it was acknowledged that such a translation mechanism was not so obvious and deeper protocol analysis was required to ensure efficient interworking between RADIUS and Diameter. Moreover, the interworking requirements depend on the functionalities provided by the Diameter application under specification, and a case-by-case analysis is required. As a consequence, all the material related to RADIUS-to-Diameter translation is removed from the new version of the Diameter NAS Application specification [RFC7155], which deprecates RFC 4005 [RFC4005].
ただし、RADIUSとDiameter間の効率的なインターワーキングを保証するには、そのような変換メカニズムはそれほど明白ではなく、より深いプロトコル分析が必要であることが認められました。さらに、インターワーキング要件は、Diameterアプリケーションが仕様に基づいて提供する機能によって異なり、ケースバイケースの分析が必要です。その結果、RADIUSからDiameterへの変換に関連するすべての資料は、Diameter NAS Application仕様の新しいバージョン[RFC7155]から削除され、RFC 4005 [RFC4005]は廃止されました。
Therefore, protocol designers SHOULD NOT assume the availability of a "standard" Diameter-to-RADIUS gateway agent when planning to interoperate with the RADIUS infrastructure. They SHOULD specify the required translation mechanism along with the Diameter application, if needed. This recommendation applies for any kind of translation.
したがって、プロトコル設計者は、RADIUSインフラストラクチャとの相互運用を計画するときに、「標準」のDiameter-to-RADIUSゲートウェイエージェントの可用性を想定してはなりません（SHOULD NOT）。必要に応じて、Diameterアプリケーションとともに必要な変換メカニズムを指定する必要があります。この推奨事項は、あらゆる種類の翻訳に適用されます。
Diameter applications can rely on optional AVPs to exchange application-specific capabilities and features. These AVPs can be exchanged on an end-to-end basis at the application layer. Examples of this can be found with the MIP6-Feature-Vector AVP in [RFC5447] and the QoS-Capability AVP in [RFC5777].
Diameterアプリケーションは、オプションのAVPに依存して、アプリケーション固有の機能を交換できます。これらのAVPは、アプリケーション層でエンドツーエンドで交換できます。この例は、[RFC5447]のMIP6-Feature-Vector AVPおよび[RFC5777]のQoS-Capability AVPで見つけることができます。
End-to-end capabilities AVPs can be added as optional AVPs with the M-bit cleared to existing applications to announce support of new functionality. Receivers that do not understand these AVPs or the AVP values can simply ignore them, as stated in [RFC6733]. When supported, receivers of these AVPs can discover the additional functionality supported by the Diameter endpoint originating the request and behave accordingly when processing the request. Senders of these AVPs can safely assume the receiving endpoint does not support any functionality carried by the AVP if it is not present in the corresponding response. This is useful in cases where deployment choices are offered, and the generic design can be made available for a number of applications.
エンドツーエンド機能AVPは、MビットがクリアされたオプションのAVPとして既存のアプリケーションに追加して、新しい機能のサポートを発表できます。 [RFC6733]で述べられているように、これらのAVPまたはAVP値を理解しない受信者は、それらを単に無視することができます。サポートされている場合、これらのAVPの受信者は、要求を発信したDiameterエンドポイントによってサポートされている追加機能を検出し、要求を処理するときにそれに応じて動作できます。これらのAVPの送信者は、対応する応答にAVPが存在しない場合、受信エンドポイントがAVPによって実行される機能をサポートしていないと想定できます。これは、展開の選択肢が提供され、多くのアプリケーションで一般的な設計を利用できる場合に役立ちます。
When used in a new application, these end-to-end capabilities AVPs SHOULD be added as an optional AVP into the CCF of the commands used by the new application. Protocol designers SHOULD clearly specify this end-to-end capabilities exchange and the corresponding behavior of the Diameter nodes supporting the application.
新しいアプリケーションで使用する場合、これらのエンドツーエンド機能AVPは、新しいアプリケーションで使用されるコマンドのCCFにオプションのAVPとして追加する必要があります（SHOULD）。プロトコル設計者は、このエンドツーエンドの機能交換と、アプリケーションをサポートするDiameterノードの対応する動作を明確に指定する必要があります（SHOULD）。
It is also important to note that this end-to-end capabilities exchange relying on the use of optional AVPs is not meant as a generic mechanism to support extensibility of Diameter applications with arbitrary functionality. When the added features drastically change the Diameter application or when Diameter agents must be upgraded to support the new features, a new application SHOULD be defined, as recommended in [RFC6733].
オプションのAVPの使用に依存するこのエンドツーエンドの機能交換は、任意の機能を備えたDiameterアプリケーションの拡張性をサポートする一般的なメカニズムとして意図されたものではないことに注意することも重要です。追加された機能がDiameterアプリケーションを大幅に変更する場合、または新しい機能をサポートするためにDiameterエージェントをアップグレードする必要がある場合は、[RFC6733]で推奨されているように、新しいアプリケーションを定義する必要があります。
Accounting can be treated as an auxiliary application that is used in support of other applications. In most cases, accounting support is required when defining new applications. This document provides two possible models for using accounting:
アカウンティングは、他のアプリケーションのサポートで使用される補助アプリケーションとして扱うことができます。ほとんどの場合、新しいアプリケーションを定義するときは、会計サポートが必要です。このドキュメントは、アカウンティングを使用するための2つの可能なモデルを提供します。
Split Accounting Model:
分割会計モデル：
In this model, the accounting messages will use the Diameter base accounting Application Id (value of 3). The design implication for this is that the accounting is treated as an independent application, especially for Diameter routing. This means that accounting commands emanating from an application may be routed separately from the rest of the other application messages. This may also imply that the messages end up in a central accounting server. A split accounting model is a good design choice when:
このモデルでは、アカウンティングメッセージはDiameterベースアカウンティングアプリケーションID（値3）を使用します。これが設計に与える影響は、特にDiameterルーティングでは、アカウンティングが独立したアプリケーションとして扱われることです。つまり、アプリケーションから発せられるアカウンティングコマンドは、他のアプリケーションメッセージの残りとは別にルーティングされる可能性があります。これは、メッセージが中央のアカウンティングサーバーに到達することを意味する場合もあります。分割会計モデルは、次の場合に適切な設計上の選択です。
* The application itself does not define its own accounting commands.
* アプリケーション自体は、独自のアカウンティングコマンドを定義しません。
* The overall system architecture permits the use of centralized accounting for one or more Diameter applications.
* 全体的なシステムアーキテクチャでは、1つまたは複数のDiameterアプリケーションに対して集中型アカウンティングを使用できます。
Centralizing accounting may have advantages, but there are also drawbacks. The model assumes that the accounting server can differentiate received accounting messages. Since the received accounting messages can be for any application and/or service, the accounting server MUST have a method to match accounting messages with applications and/or services being accounted for. This may mean defining new AVPs; checking the presence, absence, or contents of existing AVPs; or checking the contents of the accounting record itself. One of these means could be to insert into the request sent to the accounting server an Auth-Application-Id AVP containing the identifier of the application for which the accounting request is sent. But in general, there is no clean and generic scheme for sorting these messages. Therefore, this model SHOULD NOT be used when all received accounting messages cannot be clearly identified and sorted. For most cases, the use of the Coupled Accounting Model is RECOMMENDED.
会計の集中化には利点がありますが、欠点もあります。モデルは、アカウンティングサーバーが受信したアカウンティングメッセージを区別できることを前提としています。受信したアカウンティングメッセージは任意のアプリケーションやサービスを対象としている可能性があるため、アカウンティングサーバーは、アカウンティングメッセージをアカウンティングされているアプリケーションやサービスと照合するメソッドを持つ必要があります。これは、新しいAVPを定義することを意味する場合があります。既存のAVPの存在、不在、または内容を確認する。または、会計記録自体の内容を確認します。これらの手段の1つは、アカウンティングサーバーに送信される要求に、アカウンティング要求が送信されるアプリケーションの識別子を含むAuth-Application-Id AVPを挿入することです。しかし、一般に、これらのメッセージをソートするための明確で汎用的なスキームはありません。したがって、このモデルは、受信したすべてのアカウンティングメッセージを明確に識別およびソートできない場合は使用しないでください。ほとんどの場合、結合会計モデルの使用が推奨されます。
Coupled Accounting Model:
連結会計モデル：
In this model, the accounting messages will use the Application Id of the application using the accounting service. The design implication for this is that the accounting messages are tightly coupled with the application itself, meaning that accounting messages will be routed like the other application messages. It would then be the responsibility of the application server (application entity receiving the ACR message) to send the accounting records carried by the accounting messages to the proper accounting server. The application server is also responsible for formulating a proper response (ACA). A coupled accounting model is a good design choice when:
このモデルでは、アカウンティングメッセージは、アカウンティングサービスを使用するアプリケーションのアプリケーションIDを使用します。これの設計上の意味は、アカウンティングメッセージがアプリケーション自体と密に結合されていることです。つまり、アカウンティングメッセージは他のアプリケーションメッセージと同じようにルーティングされます。次に、アカウンティングメッセージによって運ばれたアカウンティングレコードを適切なアカウンティングサーバーに送信するのは、アプリケーションサーバー（ACRメッセージを受信するアプリケーションエンティティ）の責任です。アプリケーションサーバーは、適切な応答（ACA）の作成も行います。結合会計モデルは、次の場合に優れた設計の選択肢です。
* The system architecture or deployment does not provide an accounting server that supports Diameter. Consequently, the application server MUST be provisioned to use a different protocol to access the accounting server, e.g., via the Lightweight Directory Access Protocol (LDAP), SOAP, etc. This case includes the support of older accounting systems that are not Diameter aware.
* システムアーキテクチャまたは展開は、Diameterをサポートするアカウンティングサーバーを提供しません。その結果、アプリケーションサーバーは、たとえば、ライトウェイトディレクトリアクセスプロトコル（LDAP）、SOAPなどを介して、アカウンティングサーバーにアクセスするために別のプロトコルを使用するようにプロビジョニングする必要があります。このケースには、Diameterに対応していない古いアカウンティングシステムのサポートが含まれます。
* The system architecture or deployment requires that the accounting service for the specific application should be handled by the application itself.
* システムアーキテクチャまたは展開では、特定のアプリケーションのアカウンティングサービスをアプリケーション自体で処理する必要があります。
In all cases above, there will generally be no direct Diameter access to the accounting server.
上記のすべてのケースで、通常、Diameterからアカウンティングサーバーに直接アクセスすることはありません。
These models provide a basis for using accounting messages. Application designers may obviously deviate from these models provided that the factors being addressed here have also been taken into account. As a general recommendation, application designers SHOULD NOT define a new set of commands to carry application-specific accounting records.
これらのモデルは、アカウンティングメッセージを使用するための基礎を提供します。ここで取り上げられている要因も考慮に入れられている場合、アプリケーション設計者は明らかにこれらのモデルから逸脱する可能性があります。一般的な推奨事項として、アプリケーション設計者は、アプリケーション固有のアカウンティングレコードを運ぶための新しいコマンドセットを定義してはなりません（SHOULD NOT）。
As specified in [RFC6733], the Diameter message exchange SHOULD be secured between neighboring Diameter peers using Transport Layer Security (TLS) / TCP or Datagram Transport Layer Security (DTLS) / Stream Control Transmission Protocol (SCTP). However, IPsec MAY also be deployed to secure communication between Diameter peers. When IPsec is used instead of TLS or DTLS, the following recommendations apply.
[RFC6733]で指定されているように、Diameterメッセージ交換は、トランスポート層セキュリティ（TLS）/ TCPまたはデータグラムトランスポート層セキュリティ（DTLS）/ストリーム制御伝送プロトコル（SCTP）を使用して、隣接するDiameterピア間で保護する必要があります。ただし、IPsecは、Diameterピア間の通信を保護するためにも展開できます（MAY）。 TLSまたはDTLSの代わりにIPsecを使用する場合、次の推奨事項が適用されます。
IPsec Encapsulating Security Payload (ESP) [RFC4301] in transport mode with non-null encryption and authentication algorithms MUST be used to provide per-packet authentication, integrity protection, and confidentiality and to support the replay protection mechanisms of IPsec. Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] SHOULD be used for performing mutual authentication and for establishing and maintaining security associations (SAs).
パケットごとの認証、整合性保護、および機密性を提供し、IPsecのリプレイ保護メカニズムをサポートするために、非ヌルの暗号化および認証アルゴリズムを使用するトランスポートモードのIPsecカプセル化セキュリティペイロード（ESP）[RFC4301]を使用する必要があります。インターネットキー交換プロトコルバージョン2（IKEv2）[RFC7296]相互認証の実行、およびセキュリティアソシエーション（SA）の確立と維持に使用する必要があります（SHOULD）。
Version 1 of IKE (IKEv1), defined in [RFC2409], was initially used for peer authentication, negotiation of security associations, and key management in RFC 3588 [RFC3588]. For easier migration from the obsoleted implementations based on IKEv1 to IKEv2, both RSA digital signatures and pre-shared keys SHOULD be supported in IKEv2. However, if IKEv1 is used, implementors SHOULD follow the guidelines given in Section 13.1 of RFC 3588 [RFC3588].
[RFC2409]で定義されたIKEのバージョン1（IKEv1）は、RFC 3588 [RFC3588]でピア認証、セキュリティアソシエーションのネゴシエーション、およびキー管理に最初に使用されました。 IKEv1に基づく廃止された実装からIKEv2への移行を容易にするために、RSAデジタル署名と事前共有鍵の両方をIKEv2でサポートする必要があります（SHOULD）。ただし、IKEv1を使用する場合、実装者はRFC 3588 [RFC3588]のセクション13.1に記載されているガイドラインに従う必要があります。
Generic Diameter extensions are AVPs, commands, or applications that are designed to support other Diameter applications. They are auxiliary applications meant to improve or enhance the Diameter protocol itself or Diameter applications/functionality. Some examples include the extensions to support realm-based redirection of Diameter requests (see [RFC7075]), conveying a specific set of priority parameters influencing the distribution of resources (see [RFC6735]), and the support for QoS AVPs (see [RFC5777]).
Generic Diameter拡張機能は、他のDiameterアプリケーションをサポートするように設計されたAVP、コマンド、またはアプリケーションです。これらは、Diameterプロトコル自体またはDiameterアプリケーション/機能を改善または強化するための補助アプリケーションです。いくつかの例には、Diameterリクエストのレルムベースのリダイレクトをサポートする拡張機能（[RFC7075]を参照）、リソースの配布に影響を与える特定の優先度パラメーターのセット（[RFC6735]を参照）、およびQoS AVPのサポート（[RFC5777]を参照）が含まれます。 ]）。
Since generic extensions may cover many aspects of Diameter and Diameter applications, it is not possible to enumerate all scenarios. However, some of the most common considerations are as follows:
一般的な拡張はDiameterおよびDiameterアプリケーションの多くの側面をカバーする可能性があるため、すべてのシナリオを列挙することはできません。ただし、最も一般的な考慮事項は次のとおりです。
Backward Compatibility:
下位互換性：
When defining generic extensions designed to be supported by existing Diameter applications, protocol designers MUST consider the potential impacts of the introduction of the new extension on the behavior of the node that would not be yet upgraded to support/understand this new extension. Designers MUST also ensure that new extensions do not break expected message delivery layer behavior.
既存のDiameterアプリケーションでサポートされるように設計された一般的な拡張機能を定義する場合、プロトコル設計者は、新しい拡張機能の導入が、この新しい拡張機能をサポート/理解するためにまだアップグレードされていないノードの動作に及ぼす潜在的な影響を考慮する必要があります。また、設計者は、新しい拡張機能が予期されるメッセージ配信層の動作を中断しないことを確認する必要があります。
Forward Compatibility:
前方互換性：
Protocol designers MUST ensure that their design will not introduce undue restrictions for future applications.
プロトコル設計者は、その設計が将来のアプリケーションに過度の制限を導入しないことを確認する必要があります。
Trade-off in Signaling:
シグナリングのトレードオフ：
Designers may have to choose between the use of optional AVPs piggybacked onto existing commands versus defining new commands and applications. Optional AVPs are simpler to implement and may not need changes to existing applications. However, this ties the sending of extension data to the application's transmission of a message. This has consequences if the application and the extensions have different timing requirements. The use of commands and applications solves this issue, but the trade-off is the additional complexity of defining and deploying a new application. It is left up to the designer to find a good balance among these trade-offs based on the requirements of the extension.
設計者は、既存のコマンドに便乗したオプションのAVPを使用するか、新しいコマンドやアプリケーションを定義するかを選択する必要があります。オプションのAVPは実装が簡単で、既存のアプリケーションを変更する必要がない場合があります。ただし、これにより、拡張データの送信とアプリケーションによるメッセージの送信が結び付けられます。これは、アプリケーションと拡張機能のタイミング要件が異なる場合に影響します。コマンドとアプリケーションを使用することでこの問題は解決しますが、トレードオフは、新しいアプリケーションの定義と展開がさらに複雑になることです。拡張機能の要件に基づいて、これらのトレードオフの間の適切なバランスを見つけることは、設計者に任されています。
In practice, generic extensions often use optional AVPs because they are simple and non-intrusive to the application that would carry them. Peers that do not support the generic extensions need not understand nor recognize these optional AVPs. However, it is RECOMMENDED that the authors of the extension specify the context or usage of the optional AVPs. As an example, in the case that the AVP can be used only by a specific set of applications, then the specification MUST enumerate these applications and the scenarios when the optional AVPs will be used. In the case where the optional AVPs can be carried by any application, it should be sufficient to specify such a use case and perhaps provide specific examples of applications using them.
実際には、一般的な拡張機能はオプションのAVPを使用することがよくあります。これは、それらが単純であり、それらを実行するアプリケーションに邪魔にならないためです。一般的な拡張をサポートしないピアは、これらのオプションのAVPを理解したり認識したりする必要はありません。ただし、拡張機能の作成者がオプションのAVPのコンテキストまたは使用法を指定することをお勧めします。例として、AVPが特定のアプリケーションセットでのみ使用できる場合、仕様では、これらのアプリケーションと、オプションのAVPが使用されるシナリオを列挙する必要があります。オプションのAVPを任意のアプリケーションで実行できる場合は、そのようなユースケースを指定し、それらを使用するアプリケーションの具体的な例を提供するだけで十分です。
In most cases, these optional AVPs piggybacked by applications would be defined as a Grouped AVP, and it would encapsulate all the functionality of the generic extension. In practice, it is not uncommon that the Grouped AVP will encapsulate an existing AVP that has previously been defined as mandatory ('M'-bit set), e.g., 3GPP IP Multimedia Subsystems (IMS) Cx/Dx interfaces ([TS29.228] and [TS29.229]).
ほとんどの場合、アプリケーションによって便乗されるこれらのオプションのAVPは、グループ化されたAVPとして定義され、一般的な拡張機能のすべての機能をカプセル化します。実際には、グループ化されたAVPが、以前に必須（「M」ビットセット）として定義された既存のAVP、たとえば3GPP IPマルチメディアサブシステム（IMS）Cx / Dxインターフェイス（[TS29.228 ]および[TS29.229]）。
As summarized in Section 3 of this document and further described in Section 1.3 of [RFC6733], there are four main ways to extend Diameter. The process for defining new functionality slightly varies based on the different extensions. This section provides protocol designers with some guidance regarding the definition of values for possible Diameter extensions and the necessary interaction with IANA to register the new functionality.
このドキュメントのセクション3で要約され、さらに[RFC6733]のセクション1.3で説明されているように、Diameterを拡張するには主に4つの方法があります。新しい機能を定義するプロセスは、さまざまな拡張機能に基づいてわずかに異なります。このセクションでは、プロトコル設計者に、可能なDiameter拡張の値の定義と、新しい機能を登録するために必要なIANAとのやり取りに関するガイダンスを提供します。
a. Defining New AVP Values
a. 新しいAVP値の定義
The specifications defining AVPs and AVP values MUST provide guidance for defining new values and the corresponding policy for adding these values. For example, RFC 5777 [RFC5777] defines the Treatment-Action AVP, which contains a list of valid values corresponding to predefined actions (drop, shape, mark, permit). This set of values can be extended following the Specification Required policy defined in [RFC5226]. As a second example, the Diameter base specification [RFC6733] defines the Result-Code AVP that contains a 32-bit address space used to identity possible errors. According to Section 11.3.2 of [RFC6733], new values can be assigned by IANA via an IETF Review process [RFC5226].
AVPとAVP値を定義する仕様は、新しい値とこれらの値を追加するための対応するポリシーを定義するためのガイダンスを提供する必要があります。たとえば、RFC 5777 [RFC5777]は、事前定義されたアクション（ドロップ、シェイプ、マーク、許可）に対応する有効な値のリストを含むTreatment-Action AVPを定義しています。この値のセットは、[RFC5226]で定義されている仕様必須ポリシーに従って拡張できます。 2番目の例として、Diameter基本仕様[RFC6733]は、起こり得るエラーを識別するために使用される32ビットアドレス空間を含むResult-Code AVPを定義しています。 [RFC6733]のセクション11.3.2によると、IEANAはIETFレビュープロセス[RFC5226]を介して新しい値を割り当てることができます。
b. Creating New AVPs
b. 新しいAVPの作成
Two different types of AVP Codes namespaces can be used to create a new AVP:
2つの異なるタイプのAVPコード名前空間を使用して、新しいAVPを作成できます。
* IETF AVP Codes namespace.
* IETF AVPコード名前空間。
* Vendor-specific AVP Codes namespace.
* ベンダー固有のAVPコード名前空間。
In the latter case, a vendor needs to be first assigned by IANA with a private enterprise number, which can be used within the Vendor-Id field of the vendor-specific AVP. This enterprise number delimits a private namespace in which the vendor is responsible for vendor-specific AVP code value assignment. The absence of a Vendor Id or a Vendor-Id value of zero (0) in the AVP header identifies standard AVPs from the IETF AVP Codes namespace managed by IANA. The allocation of code values from the IANA-managed namespace is conditioned by an Expert Review of the specification defining the AVPs or an IETF Review if a block of AVPs needs to be assigned. Moreover, the remaining bits of the AVP Flags field of the AVP header are also assigned via Standards Action if the creation of new AVP flags is desired.
後者の場合、ベンダーは最初にIANAによってプライベートエンタープライズ番号を割り当てられる必要があります。これはベンダー固有のAVPのVendor-Idフィールド内で使用できます。このエンタープライズ番号は、ベンダーがベンダー固有のAVPコード値の割り当てを担当するプライベート名前空間を区切ります。 AVPヘッダーにベンダーIDまたはゼロ（0）のベンダーID値がないことは、IANAが管理するIETF AVPコード名前空間からの標準AVPを識別します。 IANAが管理する名前空間からのコード値の割り当ては、AVPを定義する仕様のエキスパートレビューまたはAVPのブロックを割り当てる必要がある場合はIETFレビューによって条件付けられます。さらに、新しいAVPフラグの作成が必要な場合は、AVPヘッダーのAVPフラグフィールドの残りのビットも標準アクションを介して割り当てられます。
c. Creating New Commands
c. 新しいコマンドの作成
Unlike the AVP Codes namespace, the Command Code namespace is flat, but the range of values is subdivided into three chunks with distinct IANA registration policies:
AVPコード名前空間とは異なり、コマンドコード名前空間はフラットですが、値の範囲は、異なるIANA登録ポリシーを持つ3つのチャンクに細分されます。
* A range of standard Command Code values that are allocated via IETF Review;
* IETFレビューを介して割り当てられる一連の標準コマンドコード値。
* A range of vendor-specific Command Code values that are allocated on a first-come, first-served basis; and
* 先着順で割り当てられるベンダー固有のコマンドコード値の範囲。そして
* A range of values reserved only for experimental and testing purposes.
* 実験とテストの目的でのみ予約されている値の範囲。
As for AVP flags, the remaining bits of the Command Flags field of the Diameter header are also assigned via a Standards Action to create new Command flags if required.
AVPフラグについては、Diameterヘッダーのコマンドフラグフィールドの残りのビットも標準アクションを介して割り当てられ、必要に応じて新しいコマンドフラグを作成します。
d. Creating New Applications
d. 新しいアプリケーションの作成
Similarly, to the Command Code namespace, the Application-Id namespace is flat but divided into two distinct ranges:
同様に、コマンドコード名前空間と同様に、Application-Id名前空間はフラットですが、2つの異なる範囲に分けられます。
* A range of values reserved for standard Application Ids, allocated after Expert Review of the specification defining the standard application.
* 標準アプリケーションIDのために予約されている値の範囲。標準アプリケーションを定義する仕様のエキスパートレビューの後に割り当てられます。
* A range for values for vendor-specific applications, allocated by IANA on a first-come, first-served basis.
* ベンダー固有のアプリケーションの値の範囲。先着順でIANAによって割り当てられます。
The IANA AAA parameters page can be found at <http://www.iana.org/assignments/aaa-parameters>, and the enterprise number IANA page is available at <http://www.iana.org/assignments/ enterprise-numbers>. More details on the policies followed by IANA for namespace management (e.g., first-come, first-served; Expert Review; IETF Review; etc.) can be found in [RFC5226].
IANA AAAパラメータページは<http://www.iana.org/assignments/aaa-parameters>にあり、企業番号IANAページは<http://www.iana.org/assignments/ enterpriseにあります。 -numbers>。名前空間管理のためにIANAが従うポリシーの詳細（先着順、エキスパートレビュー、IETFレビューなど）は、[RFC5226]にあります。
NOTE: When the same functionality/extension is used by more than one vendor, it is RECOMMENDED that a standard extension be defined. Moreover, a vendor-specific extension SHOULD be registered to avoid interoperability issues in the same network. With this aim, the registration policy of a vendor-specific extension has been simplified with the publication of [RFC6733], and the namespace reserved for vendor-specific extensions is large enough to avoid exhaustion.
注：同じ機能/拡張機能が複数のベンダーによって使用されている場合、標準の拡張機能を定義することをお勧めします。さらに、ベンダー固有の拡張機能を登録して、同じネットワークでの相互運用性の問題を回避する必要があります。この目的のために、ベンダー固有の拡張の登録ポリシーは[RFC6733]の公開によって簡素化され、ベンダー固有の拡張用に予約されている名前空間は、枯渇を避けるのに十分な大きさです。
This document provides guidelines and considerations for extending Diameter and Diameter applications. Although such an extension may be related to a security functionality, the document does not explicitly give additional guidance on enhancing Diameter with respect to security. However, as a general guideline, it is recommended that any Diameter extension SHOULD NOT break the security concept given in [RFC6733]. In particular, it is reiterated here that any command defined or reused in a new Diameter application SHOULD be secured by using TLS [RFC5246] or DTLS/SCTP [RFC6083] and MUST NOT be used without one of the following: TLS, DTLS, or IPsec [RFC4301]. When defining a new Diameter extension, any possible impact of the existing security principles described in [RFC6733] MUST be carefully appraised and documented in the Diameter application specification.
このドキュメントでは、DiameterおよびDiameterアプリケーションを拡張するためのガイドラインと考慮事項について説明します。このような拡張機能はセキュリティ機能に関連している可能性がありますが、ドキュメントでは、セキュリティに関するDiameterの拡張に関する追加のガイダンスは明示的に提供されていません。ただし、一般的なガイドラインとして、Diameter拡張機能は、[RFC6733]で規定されているセキュリティの概念を破らないようにすることをお勧めします。特に、新しいDiameterアプリケーションで定義または再利用されるすべてのコマンドは、TLS [RFC5246]またはDTLS / SCTP [RFC6083]を使用して保護する必要があり、TLS、DTLS、またはIPsec [RFC4301]。新しいDiameter拡張を定義するとき、[RFC6733]で説明されている既存のセキュリティ原則の考えられる影響を慎重に評価し、Diameterアプリケーション仕様に文書化する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V.、Arkko、J.、Loughney、J。、およびG. Zorn、「Diameterベースプロトコル」、RFC 6733、2012年10月、<http://www.rfc-editor.org/info/ rfc6733>。
[Q.3303.3] International Telecommunications Union, "Resource control protocol No. 3: Protocols at the Rw interface between the policy decision physical entity (PD-PE) and a policy enforcement physical entity (PE-PE): Diameter profile version 3", ITU-T Recommendation Q.3303.3, August 2008.
[Q.3303.3]国際電気通信連合、「リソース制御プロトコルNo. 3：ポリシー決定物理エンティティ（PD-PE）とポリシー実施物理エンティティ（PE-PE）間のRwインターフェイスでのプロトコル：Diameterプロファイルバージョン3」 、ITU-T勧告Q.3303.3、2008年8月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998, <http://xml.resource.org/public/rfc/info/rfc2409>.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月、<http://xml.resource.org/public/rfc/info/rfc2409>。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003, <http://www.rfc-editor.org/info/rfc3588>.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月、<http：//www.rfc-editor .org / info / rfc3588>。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005, <http://www.rfc-editor.org/info/rfc4005>.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月、<http://www.rfc-editor.org/ info / rfc4005>。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005, <http://www.rfc-editor.org/info/rfc4072>.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「Diameter Extensible Authentication Protocol（EAP）Application」、RFC 4072、2005年8月、<http://www.rfc-editor.org/info/ rfc4072>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006, <http://www.rfc-editor.org/info/rfc4740>.
[RFC4740] Garcia-Martin、M.、Belinchon、M.、Pallares-Lopez、M.、Canales-Valenzuela、C。、およびK. Tammi、「Diameter Session Initiation Protocol（SIP）Application」、RFC 4740、2006年11月、<http://www.rfc-editor.org/info/rfc4740>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009, <http://www.rfc-editor.org/info/rfc5447>.
[RFC5447] Korhonen、J.、Bournelle、J.、Tschofenig、H.、Perkins、C。、およびK. Chowdhury、「Diameter Mobile IPv6：Support for Network Access Server to Diameter Server Interaction」、RFC 5447、2009年2月、 <http://www.rfc-editor.org/info/rfc5447>。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010, <http://www.rfc-editor.org/info/rfc5777>.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、and A. Lior、 "Traffic Classification and Quality of Service（QoS）Attributes for Diameter"、RFC 5777、February 2010、< http://www.rfc-editor.org/info/rfc5777>。
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, January 2011, <http://www.rfc-editor.org/info/rfc6083>.
[RFC6083] Tuexen、M.、Seggelmann、R。、およびE. Rescorla、「Data Control Transport Layer Security（DTLS）for Stream Control Transmission Protocol（SCTP）」、RFC 6083、2011年1月、<http：//www.rfc -editor.org/info/rfc6083>。
[RFC6735] Carlberg, K. and T. Taylor, "Diameter Priority Attribute-Value Pairs", RFC 6735, October 2012, <http://www.rfc-editor.org/info/rfc6735>.
[RFC6735] Carlberg、K。およびT. Taylor、「Diameter Priority Attribute-Value Pairs」、RFC 6735、2012年10月、<http://www.rfc-editor.org/info/rfc6735>。
[RFC7075] Tsou, T., Hao, R., and T. Taylor, "Realm-Based Redirection In Diameter", RFC 7075, November 2013, <http://www.rfc-editor.org/info/rfc7075>.
[RFC7075] Tsou、T.、Hao、R。、およびT. Taylor、「Realm-Based Redirection In Diameter」、RFC 7075、2013年11月、<http://www.rfc-editor.org/info/rfc7075> 。
[RFC7155] Zorn, G., "Diameter Network Access Server Application", RFC 7155, April 2014, <http://www.rfc-editor.org/info/rfc7155>.
[RFC7155] Zorn、G。、「Diameter Network Access Server Application」、RFC 7155、2014年4月、<http://www.rfc-editor.org/info/rfc7155>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）」、STD 79、RFC 7296、2014年10月、< http://www.rfc-editor.org/info/rfc7296>。
[TS29.228] 3rd Generation Partnership Project, "Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents", 3GPP TS 29.228, September 2014, <http://www.3gpp.org/ftp/Specs/html-info/29228.htm>.
[TS29.228] 3rd Generation Partnership Project、「Technical Specification Group Core Network and Terminals; IP Multimedia（IM）Subsystem Cx and Dx Interfaces; Signaling flow and message contents」、3GPP TS 29.228、2014年9月、<http：// www .3gpp.org / ftp / Specs / html-info / 29228.htm>。
[TS29.229] 3rd Generation Partnership Project, "Technical Specification Group Core Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Protocol details", 3GPP TS 29.229, September 2014, <http://www.3gpp.org/ftp/Specs/html-info/29229.htm>.
[TS29.229] 3rd Generation Partnership Project、「Technical Specification Group Core Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Protocol details」、3GPP TS 29.229、2014年9月、<http://www.3gpp.org /ftp/Specs/html-info/29229.htm>。
[TS29.328] 3rd Generation Partnership Project, "Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents", 3GPP TS 29.328, September 2014, <http://www.3gpp.org/ftp/Specs/html-info/29328.htm>.
[TS29.328] 3rd Generation Partnership Project、「Technical Specification Group Core Network and Terminals; IP Multimedia（IM）Subsystem Sh interface; Signaling flow and message contents」、3GPP TS 29.328、2014年9月、<http：//www.3gpp .org / ftp / Specs / html-info / 29328.htm>。
[TS29.329] 3rd Generation Partnership Project, "Technical Specification Group Core Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details", 3GPP TS 29.329, September 2014, <http://www.3gpp.org/ftp/Specs/html-info/29329.htm>.
[TS29.329] 3rd Generation Partnership Project、「Technical Specification Group Core Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details」、3GPP TS 29.329、2014年9月、<http://www.3gpp.org/ftp /Specs/html-info/29329.htm>。
Contributors
貢献者
The content of this document was influenced by a design team created to revisit the Diameter extensibility rules. The team was formed in February 2008 and finished its work in June 2008. In addition to those individuals listed in the Authors' Addresses section, the design team members were:
このドキュメントの内容は、Diameter拡張性ルールを再検討するために作成された設計チームの影響を受けました。チームは2008年2月に結成され、2008年6月に作業を終了しました。「著者のアドレス」セクションにリストされている個人に加えて、設計チームのメンバーは次のとおりです。
o Avi Lior
o avi Lior
o Glen Zorn
o グレンラス
o Jari Arkko
o ヤリアルコ
o Jouni Korhonen
o ジョーニ・コルホネン
o Mark Jones
o マーク・ジョーンズ
o Tolga Asveren
o トルガ・アスヴェレン
o Glenn McGregor
o グレン・マクレガー
o Dave Frascone
o デイブ・フラスコーネ
We would like to thank Tolga Asveren, Glenn McGregor, and John Loughney for their contributions as coauthors to earlier versions of this document.
このドキュメントの以前のバージョンの共著者として貢献してくれたTolga Asveren、Glenn McGregor、およびJohn Loughneyに感謝します。
Acknowledgments
謝辞
We greatly appreciate the insight provided by Diameter implementors who have highlighted the issues and concerns being addressed by this document. The authors would also like to thank Jean Mahoney, Ben Campbell, Sebastien Decugis, and Benoit Claise for their invaluable, detailed reviews and comments on this document.
このドキュメントで取り上げられている問題と懸念を強調したDiameterの実装者から得られた洞察に深く感謝します。このドキュメントに関する貴重で詳細なレビューとコメントを提供してくれたJean Mahoney、Ben Campbell、Sebastien Decugis、Benoit Claiseにも感謝します。
Authors' Addresses
著者のアドレス
Lionel Morand (editor) Orange Labs 38/40 rue du General Leclerc Issy-Les-Moulineaux Cedex 9 92794 France
ライオネルモランド（編集者）Orange Labs 38/40 rue du General LeclercイシレムリノーCedex 9 92794フランス
Phone: +33145296257
EMail: lionel.morand@orange.com
Victor Fajardo Fluke Networks
ビクターファハルドフルークネットワークス
EMail: vf0213@gmail.com
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060オーストリア
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at