Network Working Group M. Barnes, Ed.
Request for Comments: 4097 Nortel Networks
Category: Informational June 2005
Middlebox Communications (MIDCOM) Protocol Evaluation
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation.
この文書では、MIDCOM（ミドル・コミュニケーションズ）プロトコルとしてSNMP（簡易ネットワーク管理プロトコル）、RSIP（レルム特定のインターネット・プロトコル）、Megacoの、直径の適用性の評価、およびCOPS（コモンオープンポリシーサービス）を提供します。 MIDCOM要件とMIDCOMフレームワークに対する提案されたプロトコルの各々の要約が提供されます。各要件に対するプロトコルのそれぞれの準拠は、詳細です。結論は、評価におけるプロトコル運賃の方法それぞれをまとめました。
Table of Contents
目次
Overview.......................................................... 2
Conventions Used in This Document................................. 3
1. Protocol Proposals............................................ 3
1.1. SNMP.................................................... 3
1.2. RSIP.................................................... 5
1.3. Megaco.................................................. 7
1.4. Diameter................................................ 8
1.5. COPS.................................................... 10
2. Item Level Compliance Evaluation.............................. 11
2.1. Protocol Machinery...................................... 11
2.2. Protocol Semantics...................................... 20
2.3. General Security Requirements........................... 27
3. Conclusions................................................... 29
4. Security Considerations....................................... 30
5. References.................................................... 31
5.1. Normative References.................................... 31
5.2. Informative References.................................. 33
6. Acknowledgements.............................................. 33
Appendix A - SNMP Overview........................................ 34
Appendix B - RSIP with Tunneling.................................. 35
Appendix C - Megaco Modeling Approach............................. 37
Appendix D - Diameter IPFilter Rule............................... 39
Contributors ..................................................... 42
Overview
概要
This document provides an evaluation of the applicability of SNMP (Simple Network Management Protocol), RSIP (Realm Specific Internet Protocol), Megaco, Diameter and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. This evaluation provides overviews of the protocols and general statements of applicability based upon the MIDCOM framework [2] and requirements [1] documents.
この文書では、MIDCOM（ミドル・コミュニケーションズ）プロトコルとしてSNMP（簡易ネットワーク管理プロトコル）、RSIP（レルム特定のインターネット・プロトコル）、Megacoの、直径およびCOPS（コモンオープンポリシーサービス）の適用性の評価を提供します。この評価は、プロトコルとMIDCOMフレームワークに基づいて、適用の一般的な文の概要[2]と要件[1]ドキュメントを提供します。
The process for the protocol evaluation was fairly straightforward as individuals volunteered to provide an individual document evaluating a specific protocol. Thus, some protocols that might be considered as reasonably applicable as the MIDCOM protocol are not evaluated in this document since there were no volunteers to champion the work. The individual protocol documents for which there were volunteers were submitted for discussion on the list with feedback being incorporated into an updated document. The updated versions of these documents formed the basis for the content of this WG document.
個人が特定のプロトコルを評価する個々の文書を提供するために申し出たとして、プロトコル評価のためのプロセスはかなり簡単でした。チャンピオンへのボランティアの仕事がなかったので、このように、MIDCOMプロトコルとして合理的に適用されると考えられるかもしれないいくつかのプロトコルは、このドキュメントでは評価されません。ボランティアがあったたため、個々のプロトコルドキュメントは、フィードバックが更新されたドキュメントに組み込まれて、リスト上の議論のために提出されました。これらのドキュメントの更新バージョンは、このWGの文書の内容の基礎を形成しました。
Section 1 contains a list of the proposed protocols submitted for the purposes of the protocol evaluation with some background information on the protocols and similarities and differences with regards to the applicability to the framework [2] provided.
セクション1は、提供フレームワーク[2]への適用に関してプロトコルとの類似点と相違点にいくつかの背景情報とプロトコルの評価のために提出提案プロトコルのリストを含みます。
Section 2 provides the item level evaluation of the proposed protocols against the Requirements [1].
セクション2は、要件[1]に対して提案されたプロトコルのアイテム・レベルの評価を提供します。
Section 3 provides a summary of the evaluation. A table containing a numerical breakdown for each of the protocols, with regards to its applicability to the requirements, for the following categories is provided: Fully met, Partially met through the use of extensions, Partially met through other changes to the protocol, or Failing to be met. This summary is not meant to provide a conclusive statement of the suitability of the protocols, but rather to provide information to be considered as input into the overall protocol decision process.
第3節では、評価の要約を提供します。次のカテゴリのために、要求への適用に関して持つプロトコルのそれぞれの数値内訳を含むテーブルが提供される：完全に満たされ、部分的に拡張を使用することによって満たされ、部分的にプロトコルに他の変更を介して満たさ、又は障害の満たされます。この要約は、プロトコルの適合性の決定的な声明を提供するのではなく、全体的なプロトコルの決定プロセスへの入力として考慮されるべき情報を提供するものではありません。
In order for this document to serve as a complete evaluation of the protocols, some of the background information and more detailed aspects of the proposals documenting enhancements and applications of the protocols to comply with the MIDCOM framework and requirements are included in Appendices.
このドキュメントはプロトコルの完全な評価として機能するためには、MIDCOMフレームワークと要件に準拠したプロトコルの拡張機能やアプリケーションを文書化提案の背景情報の一部と、より詳細な態様は、付録に含まれています。
Conventions Used in this Document
このドキュメントの表記規則
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 BCP 14, RFC 2119 [4].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[4]。
The following protocols were submitted to the MIDCOM WG for consideration:
次のプロトコルは、検討のためにMIDCOM WGに提出されました：
o SNMP o RSIP o Megaco o Diameter o COPS
お ＳんＭＰ お ＲしＰ お めがこ お ぢあめてｒ お こＰＳ
The following provides an overview of each of the protocols and the applicability of each protocol to the MIDCOM framework.
以下は、プロトコルの各々の概要とMIDCOMフレームワークへの各プロトコルの適用を提供します。
This section provides a general statement with regards to the applicability of SNMP as the MIDCOM protocol. A general overview and some specific details of SNMP are provided in Appendix A. This evaluation of SNMP is specific to SNMPv3, which provides the security required for MIDCOM usage. SNMPv1 and SNMPv2c would be inappropriate for MIDCOM since they have been declared Historic, and because their messages have only trivial security. Some specifics with regards to existing support for NAT and Firewall Control are provided in section 1.1.2. The differences between the SNMP framework and the MIDCOM framework are addressed in section 1.1.3.
このセクションでは、MIDCOMプロトコルとしてSNMPの適用に関して一般的なステートメントを提供します。一般的な概要およびSNMPのいくつかの具体的な詳細は、付録Aで提供されているSNMPのこの評価はMIDCOM使用のために必要なセキュリティを提供SNMPv3の、固有のものです。彼らは歴史的に宣言されているので、SNMPv1およびSNMPv2cのは、MIDCOMのために不適切である、と彼らのメッセージは些細なセキュリティを持っているので。 NATやファイアウォールのコントロールのための既存のサポートに関して持ついくつかの詳細は、セクション1.1.2で提供されています。 SNMPフレームワークとMIDCOMフレームワークとの違いは、セクション1.1.3で対応しています。
The primary advantages of SNMPv3 are that it is a mature, well understood protocol, currently deployed in various scenarios, with mature toolsets available for SNMP managers and agents.
SNMPv3のの主な利点は、SNMPマネージャとエージェントのために利用可能な成熟したツールセットと、現在、様々なシナリオで展開成熟し、よく理解プロトコル、であることです。
Application intelligence is captured in MIB modules, rather than in the messaging protocol. MIB modules define a data model of the information that can be collected and configured for a managed functionality. The SNMP messaging protocol transports the data in a standardized format without needing to understand the semantics of the data being transferred. The endpoints of the communication understand the semantics of the data.
アプリケーションインテリジェンスではなく、メッセージングプロトコルに比べて、MIBモジュールでキャプチャされます。 MIBモジュールを収集し、管理機能のために構成することができる情報のデータモデルを定義します。 SNMPメッセージングプロトコルは、転送されるデータの意味を理解することなく、標準化された形式でデータを転送します。通信のエンドポイントは、データの意味を理解しています。
Partly due to the lack of security in SNMPv1 and SNMPv2c, and partly due to variations in configuration requirements across vendors, few MIB modules have been developed that enable standardized configuration of managed devices across vendors. Since monitoring can be done using only a least-common-denominator subset of information across vendors, many MIB modules have been developed to provide standardized monitoring of managed devices. As a result, SNMP has been used primarily for monitoring rather than for configuring network nodes.
部分的にSNMPv1およびSNMPv2cのセキュリティの欠如に、かつ部分的にベンダー間での構成要件の変化に、いくつかのMIBモジュールは、ベンダー間で、管理対象デバイスの標準化されたコンフィギュレーションを可能にする開発されています。監視はベンダー間での情報の唯一の最小共通分母のサブセットを使用して行うことができるので、多くのMIBモジュールは、管理対象デバイスの標準化された監視を提供するために開発されました。結果として、SNMPを監視するためではなく、ネットワークのノードを構成するために主に使用されてきました。
SNMPv3 builds upon the design of widely-deployed SNMPv1 and SNMPv2c versions. Specifically, SNMPv3 shares the separation of data modeling (MIBs) from the protocol to transfer data, so all existing MIBs can be used with SNMPv3. SNMPv3 also uses the SMIv2 standard, and it shares operations and transport with SNMPv2c. The major difference between SNMPv3 and earlier versions is the addition of strong message security and controlled access to data.
SNMPv3は広く展開されSNMPv1およびSNMPv2cのバージョンの設計に基づいて構築します。具体的には、SNMPv3はそう既存のすべてのMIBがのSNMPv3で使用することができ、データを転送するためのプロトコルからデータモデリング（のMIB）の分離を共有します。 SNMPv3はまたSMIv2の標準を使用し、それはSNMPv2cのと操作とトランスポートを共有しています。 SNMPv3のとそれ以前のバージョンとの主な違いは、強力なメッセージセキュリティやデータへのアクセス制御を追加することです。
SNMPv3 uses the architecture detailed in RFC 3411 [5], where all SNMP entities are capable of performing certain functions, such as the generation of requests, response to requests, the generation of asynchronous notifications, the receipt of notifications, and the proxy-forwarding of SNMP messages. SNMP is used to read and manipulate virtual databases of managed-application-specific operational parameters and statistics, which are defined in MIB modules.
SNMPv3は、RFC 3411に詳細なアーキテクチャを使用し[5]、すべてのSNMPエンティティがそのような要求、要求に対する応答の生成などの特定の機能を実行することが可能である場合、非同期通知の生成、通知の受信、およびプロキシ転送SNMPメッセージの。 SNMPは、MIBモジュールで定義されている管理アプリケーション固有の動作パラメータと統計の仮想データベースを読み、操作するために使用されます。
For configuring NATs, a NAT MIB module [16] has been developed. The NAT MIB module meets all of the MIDCOM requirements concerning NAT control with the exception of grouping of policy rules (requirement 2.2.3.). In order to support this, an additional grouping table in the NAT MIB module is required.
NATの設定をするために、NAT MIBモジュール[16]が開発されてきました。 NAT MIBモジュールは、ポリシールールのグループ化（要件2.2.3。）を除いて、NAT制御に関するMIDCOM要件のすべてを満たしています。これをサポートするために、NAT MIBモジュール内の追加グルーピングテーブルが必要となります。
Existing work for firewall control with SNMP only considered the monitoring of firewalls and not the configuration. Further work is required towards the development of MIBs for configuring firewalls.
SNMPでのファイアウォール制御のための既存の作業は、ファイアウォールの監視ではなく設定を検討しました。さらに作業がファイアウォールを設定するためのMIBの開発に向けて必要とされます。
The SNMP management framework provides functions equivalent to those defined by the MIDCOM framework, although there are a few architectural differences.
いくつかのアーキテクチャの違いはあるもののSNMP管理フレームワークは、MIDCOMフレームワークによって定義されたものと同等の機能を提供します。
Traditionally, SNMP entities have been called Manager and Agent. Manager and agent are now recognized as entities designed to support particular configurations of SNMPv3 functions. A traditional manager is an entity capable of generating requests and receiving notifications, and a traditional agent is an entity capable of responding to requests and generating notifications. The SNMP use of the term agent is different from its use in the MIDCOM framework: The SNMP Manager corresponds to the MIDCOM agent and the SNMP Agent corresponds to the MIDCOM PDP. The SNMP evaluation assumes that the MIDCOM PDP (SNMP Agent) is physically part of the middlebox, which is allowed by the MIDCOM framework as described in section 6.0 of [2]. Thus, for the purpose of this evaluation, the SNMP agent corresponds to the Middlebox.
伝統的に、SNMPエンティティは、マネージャとエージェントと呼ばれています。マネージャとエージェントは、現在のSNMPv3機能の特定の構成をサポートするように設計されたエンティティとして認識されています。伝統的なマネージャーが通知要求を生成し、受信可能なエンティティであり、伝統的な薬剤は、要求に応答し、通知を生成することができるエンティティです。用語エージェントのSNMPの使用はMIDCOMフレームワークでの使用は異なっている：SNMPマネージャはMIDCOMエージェントに対応し、SNMPエージェントはMIDCOM PDPに対応しています。 SNMP評価はMIDCOM PDP（SNMPエージェント）は、物理的に[2]のセクション6.0に記載されているようにMIDCOMフレームワークによって許可されているミドルの一部であることを前提としています。したがって、この評価の目的のために、SNMPエージェントは、ミドルに対応しています。
While this evaluation is based on the assumption that the SNMP agent corresponds to the middlebox, SNMP does not force such a restriction.
この評価は、SNMPエージェントがミドルボックスに対応するという仮定に基づいている間、SNMPはこのような制限を強制しません。
Proxy means many things to many people. SNMP can be deployed using intermediate entities to forward messages, or to help distribute policies to the middlebox, similar to the proxy capabilities of the other candidate protocols. Since proxy adds configuration and deployment complexity and is not necessary to meet the specified MIDCOM requirements, the use of a proxy agent or mid-level manager is not considered in this evaluation. Further details on SNMP proxy capabilities are provided in Appendix A.
プロキシは、多くの人々に多くのことを意味します。 SNMPは、メッセージを転送する中間エンティティを使用して展開することができ、または他の候補プロトコルのプロキシ機能に似たミドルにポリシーを、配布を支援します。プロキシが設定と展開の複雑さを追加し、指定されたMIDCOM要件を満たす必要がないため、プロキシエージェントまたは中間レベルのマネージャーの使用は、本評価では考慮されていません。 SNMPプロキシ機能に関する詳細については、付録Aで提供されています
Although the SNMP management framework does not have the concept of a session, session-like associations can be established through the use of managed objects. In order to implement the MIDCOM protocol based on SNMP, a MIDCOM MIB module is required. All requests from the MIDCOM agent to the Middlebox would be performed using write access to managed objects defined in the MIDCOM MIB module. Replies to requests are signaled by the Middlebox (SNMP agent), by modifying the managed objects. The MIDCOM agent (SNMP manager) can receive this information by reading or polling, if required, the corresponding managed object.
SNMP管理フレームワークは、セッションの概念がありませんが、セッションのような団体は、管理対象オブジェクトを使用して確立することができます。 SNMPに基づくMIDCOMプロトコルを実装するために、MIDCOM MIBモジュールが必要とされます。ミドルへMIDCOMエージェントからのすべての要求はMIDCOM MIBモジュールで定義された管理対象オブジェクトへの書き込みアクセスを使用して実行されるであろう。要求への回答は、管理対象オブジェクトを変更することで、ミドル（SNMPエージェント）によって通知されます。 、対応する管理オブジェクトを必要に応じてMIDCOMエージェント（SNMPマネージャ）は、読み取りまたはポーリングすることによって、この情報を受信することができます。
The RSIP framework and detailed protocol are defined in RFC 3102 [17] and RFC 3103 [18] respectively.
RSIPフレームワークと詳細なプロトコールは、それぞれ、RFC 3102 [17]およびRFC 3103 [18]で定義されています。
The following framework elements are common to MIDCOM and RSIP listed by their MIDCOM names, with the RSIP name indicated in parenthesis:
RSIP名は括弧内に示されていると、次のフレームワーク要素は、そのMIDCOM名で記載されているMIDCOMとRSIPに共通しています。
o Hosts o Applications o Middleboxes (RSIP gateways) o Private domain (private realm) o External domain (public realm) o Middlebox communication protocol (RSIP) o MIDCOM agent registration (host registration) o MIDCOM session (RSIP session) o MIDCOM Filter (local / remote address and port number(s) pairs)
MIDCOMフィルターO MIDCOMセッション（RSIPセッション）O MIDCOMエージェント登録（ホスト登録）Oミドル通信プロトコル（RSIP）O外部ドメイン（公共分野）Oプライベートドメイン（プライベート領域）〇〇のMiddleboxes OアプリケーションOホスト（RSIPゲートウェイ）（ローカル/リモートアドレスとポート番号（S）ペア）
The following MIDCOM framework elements are not supported by RSIP:
次MIDCOMフレームワーク要素はRSIPによってサポートされていません。
o Policy actions and rules. RSIP always implicitly assumes a permit action. To support MIDCOM, a more general and explicit action parameter would have to be defined. RSIP requests specifying local / remote address and port number(s) pairs would have to be extended to include an action parameter, in MIDCOM rules.
Oポリシーアクションおよびルール。 RSIPは常に暗黙的に許可アクションを前提としています。 MIDCOMをサポートするために、より一般的かつ明示的なアクションパラメータを定義する必要があります。リモート/ローカルアドレスおよびポート番号（S）ペアを特定RSIP要求はMIDCOMルールで、アクションパラメータを含むように拡張されなければなりません。
o MIDCOM agents. RSIP makes no distinction between applications and agents; address assignment operations can be performed equally by applications and agents.
MIDCOMエージェントO。 RSIPは、アプリケーションおよびエージェントを区別しません。アドレス割り当て操作はアプリケーションおよびエージェントによって均等に行うことができます。
o Policy Decision Points. RSIP assumes that middleboxes grant or deny requests with reference to a policy known to them; the policy could be determined jointly by the middlebox and a policy decision point; such joint determination is not addressed by the RSIP framework, nor is it specifically precluded.
Oポリシー決定ポイント。 RSIPは、ミドルボックスは彼らに知られているポリシーを参照して要求を許可または拒否することを前提とし、ポリシーは、ミドルとポリシー決定ポイントが共同で決定することができました。そのような関節決意はRSIPフレームワークによって対処されていない、またそれは、具体的に排除されます。
The following elements are unique to the RSIP framework. If RSIP were adopted as the basis for the MIDCOM protocol, they could be added to the MIDCOM framework:
次の要素はRSIPフレームワークに固有のものです。 RSIPはMIDCOMプロトコルの基礎として採用された場合、それらはMIDCOMフレームワークに追加することができます。
o RSIP client: that portion of the application (or agent) that talks to the RSIP gateway using RSIP.
O RSIPクライアント：アプリケーション（またはエージェント）の部分RSIPを使用RSIPゲートウェイに話します。
o RSIP server: that portion of an RSIP gateway that talks to applications using RSIP.
O RSIPサーバ：RSIPを使用してアプリケーションと対話RSIPゲートウェイのその部分。
o Realm Specific Address IP (RSA-IP) and Realm Specific Address and Port IP (RSAP-IP): RSIP distinguishes between filters that include all ports on an IP address and those that do not.
Oレルム特定のアドレスIP（RSA-IP）およびレルム特定のアドレスとポートIP（RSAP-IP）：RSIPは、すべてのIPアドレス上のポートとそうでないものが含まれるフィルタが区別されます。
o Demultiplexing Fields: Any set of packet header or payload fields that an RSIP gateway uses to route an incoming packet to an RSIP host. RSIP allows a gateway to perform, and an application to control, packet routing to hosts in the private domain based on more than IP header fields.
O多重分離フィールド：RSIPゲートウェイはRSIPホストにルーティングする着信パケットを使用してパケットヘッダまたはペイロードフィールドの任意のセット。 RSIPゲートウェイが実行することができ、そして制御するアプリケーション、IPヘッダフィールド以上に基づいて、プライベート・ドメイン内のホストにパケットルーティング。
o Host-to-middlebox tunnels: RSIP assumes that data communicated between a private realm host and a public realm host is transferred through the private realm by a tunnel between the inner host and the middle box, where it is converted to and from native IP based communications to the public realm host.
Oホスト - ミドルトンネル：RSIPプライベートレルムホストとパブリック領域のホストとの間で通信されるデータは、それがネイティブIPから変換された内部ホストと中央ボックスとの間のトンネルによってプライベート領域を介して転送されていることを前提と公共レルムホストにベースの通信。
RSIP with tunneling, has the advantage that the public realm IP addresses and port numbers are known to the private realm host application, thus no translation is needed for protocols such as SDP, the FTP control protocol, RTSP, SMIL, etc. However, this does require that an RSIP server and a tunneling protocol be implemented in the middlebox and an RSIP client and the tunneling protocol be implemented in the private realm host. The host modifications can generally be made without modification to the host application or requiring the implementation of a host application agent. This is viewed as a significant advantage over NAT (Network Address Translation).
トンネリングとRSIP、これ何の変換はところがなどSDP、FTP制御プロトコル、RTSP、SMIL、などのプロトコルのために必要ではありません、パブリックレルムIPアドレスとポート番号をプライベートレルムホストアプリケーションに知られているという利点があり、このRSIPサーバとトンネリングプロトコルがミドルで実装すると、RSIPクライアントとトンネリングプロトコルは、プライベートレルムホストに実装する必要がありません。ホストの変更は、一般に、ホスト・アプリケーションへの修正またはホストアプリケーションエージェントの実装を必要とせずに行うことができます。これは、NAT（ネットワークアドレス変換）に比べて大きな利点と見られています。
Further details on the evaluation of RSIP with regards to tunneling in the context of NAT support are available in Appendix B of this document.
NATサポートの文脈でのトンネリングに関してでRSIPの評価に関する詳細は、このドキュメントの付録Bでご利用いただけます。
Megaco is a master-slave, transaction-oriented protocol defined in RFC 3015 [20] in which Media Gateway Controllers (MGC) control the operation of Media Gateways (MG). Originally designed to control IP Telephony gateways, it is used between an application-unaware device (the Media Gateway) and an intelligent entity (the Media Gateway Controller) having application awareness.
MEGACOは、メディアゲートウェイコントローラ（MGC）はメディアゲートウェイ（MG）の動作を制御するマスタ・スレーブ、RFC 3015で定義されたトランザクション指向のプロトコル[20]です。元々IPテレフォニーゲートウェイを制御するように設計され、それは、アプリケーション認識を有するアプリケーション非対応デバイス（メディアゲートウェイ）とインテリジェントエンティティ（メディアゲートウェイコントローラ）との間で使用されています。
The Megaco model includes the following key concepts:
Megacoのモデルは、次の主要な概念が含まれています。
1. Terminations: Logical entities on the MG that act as sources or sink of packet streams. A termination can be physical or ephemeral and is associated with a single MGC.
1.終端：ソースまたはパケットストリームのシンクとして機能MG上の論理エンティティ。終端は、物理的または短命であることができ、単一のMGCに関連しています。
2. Context: An association between Terminations for sharing media between the Terminations. Terminations can be added, subtracted from a Context and can be moved from one Context to another. A Context and all of its Terminations are associated with a single MGC.
2.コンテキスト：終端の間でメディアを共有するための終端との間の関連性。終端は、コンテキストから減算し、別のコンテキストから移動することができ、添加することができます。コンテキストとその終端のすべてを単一のMGCに関連付けられています。
3. Virtual Media Gateways: A physical MG can be partitioned into multiple virtual MGs allowing multiple Controllers to interact with disjoint sets of Contexts/Terminations within a single physical device.
3.仮想メディアゲートウェイ：物理MGは、複数のコントローラは、単一の物理デバイス内でコンテキスト/終端の互いに素な集合と対話することを可能にする複数の仮想のMGに分割することができます。
4. Transactions/Messages: Each Megaco command applies to one Termination within a Context and generates a unique response. Commands may be replicated implicitly so that they act on all Terminations of a given Context through wildcarding of Termination identifiers. Multiple commands addressed to different Contexts can be grouped in a Transaction structure. Similarly, multiple Transactions can be concatenated into a Message.
4.取引/メッセージ：各Megacoのコマンドは、コンテキスト内で1つのターミネーションに適用され、独自の応答を生成します。彼らは終了識別子のワイルドカードによって与えられたコンテキストのすべての端子に作用するようにコマンドが暗黙的に複製することができます。別のコンテキストに宛てた複数のコマンドは、取引構造にグループ化することができます。同様に、複数のトランザクションメッセージに連結することができます。
5. Descriptors/Properties: A Termination is described by a number of characterizing parameters or Properties, which are grouped in a set of Descriptors that are included in commands and responses.
5.ディスクリプタ/プロパティ：終了は、コマンドおよび応答に含まれる記述子のセットにグループ化され特徴付けるパラメータまたはプロパティの数によって記述されます。
6. Events and signals: A Termination can be programmed to perform certain actions or to detect certain events and notify the Agent.
6.イベントとシグナル：終了は、特定のアクションを実行したり、特定のイベントを検出して、エージェントに通知するようにプログラムすることができます。
7. Packages: Packages are groups of properties, events, etc. associated with a Termination. Packages are simple means of extending the protocol to serve various types of devices or Middleboxes.
7.パッケージ：パッケージは、終了に関連するプロパティのグループ、イベント、などです。パッケージには、デバイスまたはのMiddleboxes様々な種類のサービスを提供するためのプロトコルを拡張する簡単な手段です。
In the MIDCOM architecture, the Middlebox plays the role of an application-unaware device being controlled by the application-aware Agent. In the Megaco architecture, the Media Gateway controller serves a role similar to the MIDCOM Agent (MA) and the Media Gateway serves a role similar to the Middlebox (MB). One major difference between the Megaco model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the Megaco definition is that a MG (Middlebox) establishes communication with an MGC (MIDCOM Agent).
MIDCOMアーキテクチャでは、ミドルは、アプリケーションアウェアエージェントによって制御されているアプリケーション非対応デバイスの役割を果たしています。 Megacoのアーキテクチャでは、メディアゲートウェイコントローラはMIDCOMエージェント（MA）と同様の役割を提供しており、メディアゲートウェイは、ミドル（MB）と同様の役割を果たす。 MegacoのモデルとMIDCOMプロトコル要件との間の1つの大きな違いはMIDCOMが、MIDCOMエージェントがセッションを確立することを必要とすることです。一方、Megacoの定義は、MG（ミドル）がMGC（MIDCOMエージェント）との通信を確立することです。
Diameter is designed to support AAA for network access. It is meant to operate through networks of Diameter nodes, which both act upon and route messages toward their final destinations. Endpoints are characterized as either clients, which perform network access control, or servers, which handle authentication, authorization and accounting requests for a particular realm. Intermediate nodes perform relay, proxy, redirect, and translation services. Design requirements for the protocol include robustness in the face of bursty message loads and server failures, resistance to specific DOS attacks and protection of message contents, and extensibility including support for vendor-specific attributes and message types.
直径は、ネットワークアクセスのためのAAAをサポートするように設計されています。両方がその最終目的地に向かって作用し、ルートメッセージDiameterノードのネットワークを介して動作することを意味します。エンドポイントは、特定の領域での認証、許可およびアカウンティング要求を処理するいずれかのネットワークアクセス制御を実行するクライアント、またはサーバとして特徴づけられます。中間ノードは、リレー、プロキシ、リダイレクト、および翻訳サービスを行います。プロトコルの設計要件は、バースト性のメッセージをロードし、サーバの障害に直面して堅牢性、特定のDOS攻撃やメッセージの内容の保護に対する抵抗性、およびベンダー固有の属性とメッセージタイプのサポートなど、拡張性があります。
The protocol is designed as a base protocol in RFC 3588 [24] to be supported by all implementations, plus extensions devoted to specific applications. Messages consist of a header and an aggregation of "Attribute-Value Pairs (AVPs)", each of which is a tag-length-value construct. The header includes a command code, which determines the processing of the message and what other AVP types must or may be present. AVPs are strongly typed. Some basic and compound types are provided by the base protocol specification, while others may be added by application extensions. One of the types provided in the base is the IPFilterRule, which may be sufficient to express the Policy Rules that MIDCOM deals with.
プロトコルは、特定のアプリケーションに専念すべての実装に加えて、拡張によってサポートされる[24] RFC 3588でベースプロトコルとして設計されています。メッセージは、ヘッダとタグ長値構築物で各々が「属性値ペア（AVPの）」、の集合から成ります。ヘッダは、メッセージとどのような他のAVPタイプの、または存在してもよいしなければならないの処理を決定する命令コードを含みます。 AVPは強く型付けされています。他のものは、アプリケーションの拡張によって追加することができるが、いくつかの塩基性化合物の種類は、ベースプロトコル仕様によって提供されます。ベースに設けられたタイプの一つは、MIDCOMは扱っポリシールールを表現するのに十分であり得るIPFilterRuleのです。
Messaging takes the form of request-answer exchanges. Some exchanges may take multiple round-trips to complete. The protocol is connection-oriented at both the transport and application levels. In addition, the protocol is tied closely to the idea of sessions, which relate sequences of message exchanges through use of a common session identifier. Each application provides its own definition of the semantics of a session. Multiple sessions may be open simultaneously.
メッセージは、要求回答交流の形をとります。いくつかの交換が完了するまでに、複数のラウンドトリップがかかる場合があります。プロトコルは、コネクション型の両方のトランスポートおよびアプリケーションレベルです。また、プロトコルは、共通のセッション識別子の使用を介してメッセージ交換のシーケンスを関連セッションの考えに密接に結びついています。各アプリケーションは、セッションの意味論の独自の定義を提供します。複数のセッションが同時に開くことがあります。
The MIDCOM Agent does not perform the functions of a Diameter client, nor does the Middlebox support the functions of a Diameter server. Thus the MIDCOM application would introduce two new types of endpoints into the Diameter architecture. Moreover, the MIDCOM requirements do not at this time imply any type of intermediate node.
MIDCOMエージェントはDiameterクライアントの機能を実行していない、またミドルは、Diameterサーバの機能をサポートしていません。したがって、MIDCOMアプリケーションは、Diameterアーキテクチャにエンドポイントの二つの新しいタイプを紹介します。また、MIDCOM要件は、この時点で、中間ノードの任意の型を意味しません。
A general assessment might be that Diameter meets and exceeds MIDCOM architectural requirements, however the connection orientation may be too heavy for the number of relationships the Middlebox must support. Certainly the focus on extensibility, request-response messaging orientation, and treatment of the session, are all well-matched to what MIDCOM needs. At this point, MIDCOM is focused on simple point-to-point relationships, so the proxying and forwarding capabilities provided by Diameter are not needed. Most of the commands and AVPs defined in the base protocol are also surplus to MIDCOM requirements.
一般的な評価は、直径が満たしているとMIDCOMアーキテクチャ要件を超えていることかもしれません、しかし、接続方向はミドルがサポートしなければならない関係の数は重すぎるかもしれません。確かに拡張性、要求 - 応答メッセージングの向き、およびセッションの治療上の焦点は、すべてのMIDCOMが必要とするものによく一致しています。この時点で、MIDCOMは、単純なポイント・ツー・ポイントの関係に焦点を当てているので、直径が提供するプロキシおよび転送能力は必要ありません。基本プロトコルで定義されたコマンドとのAVPのほとんどは、MIDCOM要件に黒字です。
Overall, COPS, defined in RFC 2748 [25], and COPS-PR, defined in RFC 3084 [26], have similar compliancy with regards to the MIDCOM protocol requirements. In this document, references to COPS are generally applicable to both COPS and COPS-PR. However, COPS-PR is explicitly identified to meet two of the requirements. The only other major difference between COPS-PR and COPS, as applied to the MIDCOM protocol, would be the description of the MIDCOM policy rule attributes with COPS-PR MIDCOM PIB attributes rather than COPS MIDCOM client specific objects.
全体として、RFC 2748で定義されたCOPS、[25]、およびRFC 3084で定義されたCOPS-PR、[26]、MIDCOMプロトコル要件に関して同様のコンプライアンスを有します。この文書では、COPSへの言及は、一般的にCOPSとCOPS-PRの両方に適用されています。しかし、COPS-PRは、明示的な要件のうちの2つを満たすために識別されます。 COPS-PRとCOPSの間の唯一の他の主要な違いは、MIDCOMプロトコルに適用されるように、COPSは-PR MIDCOM PIBは、COPS MIDCOMクライアントの特定のオブジェクトではなく、属性とMIDCOM政策ルールの説明属性になります。
COPS is a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). COPS was defined to be a simple and extensible protocol. The main characteristics of COPS include the following:
COPSポリシーサーバ（ポリシー決定ポイントまたはPDP）とそのクライアント（ポリシー施行ポイントまたはのPEP）との間でポリシー情報を交換するために使用することができ、単純なクエリと応答プロトコルです。 COPSは、単純で拡張プロトコルであると定義しました。 COPSの主な特徴は次のとおりです。
1. The protocol employs a client/server model. The PEP sends requests, updates, and deletions to the remote PDP and the PDP returns decisions back to the PEP.
1.プロトコルは、クライアント/サーバモデルを採用しています。 PEPはリモートPDPに要求、更新、削除を送信し、PDPはバックPEPに意思決定を返します。
2. The protocol uses TCP as its transport protocol for reliable exchange of messages between policy clients and a server.
2.プロトコルは、ポリシー、クライアントとサーバー間のメッセージの信頼できる交換のためのトランスポートプロトコルとしてTCPを使用しています。
3. The protocol is extensible in that it is designed to leverage self-identifying objects and can support diverse client specific information without requiring modification of the COPS protocol.
自己識別オブジェクトを活用するように設計されており、COPSプロトコルの変更を必要とすることなく、多様なクライアント固有の情報をサポートすることができるという点で3プロトコルは拡張可能です。
4. The protocol was created for the general administration, configuration, and enforcement of policies.
4.プロトコルは、一般的な管理、構成、およびポリシーの施行のために作成されました。
5. COPS provides message level security for authentication, replay protection, and message integrity. COPS can make use of existing protocols for security such as IPSEC [22] or TLS [21] to authenticate and secure the channel between the PEP and the PDP.
5. COPSは、認証、再生保護、およびメッセージの整合性のためのメッセージレベルのセキュリティを提供します。 COPSは、認証とPEPとPDPの間のチャネルを確保するようなIPSEC [22]またはTLS [21]のようにセキュリティのための既存のプロトコルを利用することができます。
6. The protocol is stateful in two main aspects:
前記プロトコルは、2つの主な態様において、ステートフルです。
(1) Request/Decision state is shared and kept synchronized in a transactional manner between client and server. Requests from the client PEP are installed or remembered by the remote PDP until they are explicitly deleted by the PEP. At the same time, Decisions from the remote PDP can be generated asynchronously at any time for a currently installed request state.
（1）要求/決定状態は共有され、クライアントとサーバの間のトランザクション方法で同期を維持します。クライアントPEPからの要求は、インストールしたり、それらを明示的にPEPにより削除されるまで、リモートPDPによって記憶されます。同時に、リモートPDPからの決定は、現在インストールされている要求状態のために、いつでも非同期的に生成することができます。
(2) State from various events (Request/Decision pairs) may be inter-associated. The server may respond to new queries differently because of previously installed, related Request/Decision state(s).
（2）様々なイベント（要求/決定対）からの状態は相互関連していてもよいです。サーバーは、異なる理由は、以前にインストールし、関連する要求/決定状態（S）の新しいクエリに応答することができます。
7. The protocol is also stateful in that it allows the server to push configuration information to the client, and then allows the server to remove such state from the client when it is no longer applicable.
7.プロトコルはまた、サーバがクライアントに設定情報をプッシュすることができ、それがもはや適用されたときに、サーバがクライアントからそのような状態を削除することができないことでステートフル。
In the MIDCOM framework, the Middlebox enforces the policy controlled by an application-aware Agent. Thus, when compared to the COPS architecture, the Middlebox serves as the PEP (COPS Client) and the MIDCOM Agent serves as the PDP (COPS Policy Server). One major difference between the COPS protocol model and the MIDCOM protocol requirements is that MIDCOM requires that the MIDCOM Agent establish the session. Whereas, the COPS definition is that a PEP (Middlebox) establishes communication with a PDP (MIDCOM Agent).
MIDCOMフレームワークでは、ミドルは、アプリケーションアウェアエージェントによって制御ポリシーを適用します。 COPSアーキテクチャと比較した場合、このように、ミドルは、PEP（COPSクライアント）として機能し、MIDCOMエージェントは、PDP（COPSポリシーサーバ）として機能します。 COPSプロトコルモデルとMIDCOMプロトコル要件との間の1つの大きな違いはMIDCOMが、MIDCOMエージェントがセッションを確立することを必要とすることです。一方、COPS定義は、PEP（ミドル）がPDP（MIDCOMエージェント）との通信を確立することです。
This section contains a review of the protocol's level of compliance to each of the MIDCOM Requirements [1]. The following key will be used to identify the level of compliancy of each of the individual protocols:
このセクションでは、MIDCOM要件[1]の各への準拠のプロトコルのレベルの見直しが含まれています。次のキーは、個々のプロトコルの各々のコンプライアンスのレベルを識別するために使用されます。
T = Total Compliance. Meets the requirement fully.
T =総コンプライアンス。完全に要件を満たしています。
P+ = Partial Compliance+. Fundamentally meets the requirement through the use of extensions (e.g., packages, additional parameters, etc).
P + =部分的なコンプライアンス+。基本的に拡張（例えば、パッケージ、追加パラメータなど）の使用を介して要求を満たします。
P = Partial Compliance. Meets some aspect of the requirement, however, the necessary changes require more than an extension and/or are inconsistent with the design intent of the protocol.
P =部分的なコンプライアンス。要件のいくつかの側面を満たし、但し、必要な変更は、拡張よりも多くを必要とし、および/またはプロトコルの設計意図と矛盾します。
F = Failed Compliance. Does not meet the requirement.
Fは=コンプライアンスを失敗しました。要件を満たしていません。
This section describes the compliancy of the proposed protocols against the protocol machinery requirements from section 2.1 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
このセクションでは、要件文書[1]のセクション2.1からプロトコル機械要件に対して提案されたプロトコルのコンプライアンスを記載します。プロトコルのそれぞれの短い説明が評価を実証するために設けられています。
SNMP: T, RSIP: P+, Megaco: P, Diameter: T, COPS: P
SNMP：T、RSIP：Pの+、Megacoの：P、直径：T、COPS：P
SNMP: SNMPv3 provides mutual authentication at the user level (where the user can be an application or a host if desired) via shared secrets. Each authenticated principal is associated with a group that has access rights that control the principals ability to perform operations on specific subsets of data. Failure to authenticate can generate a SNMP notification (administrator configurable choice).
SNMP：SNMPv3の共有秘密を介して（必要に応じて、ユーザは、アプリケーションまたはホストすることができる場合）、ユーザレベルでの相互認証を提供します。各認証されたプリンシパルは、データの特定のサブセット上で動作を実行する主体の能力を制御するアクセス権を持っているグループに関連付けられています。認証に失敗すると、SNMP通知（管理者設定可能な選択肢）を生成することができます。
RSIP: RSIP allows sessions to be established between middleboxes and applications and MIDCOM agents. Authorization credentials would have to be added to the session establishment request to allow the middlebox to authorize the session requestor.
RSIP：RSIPは、セッションがミドルボックスとアプリケーションとMIDCOMエージェントの間で確立することができます。認証資格情報はミドルがセッション要求者を認証することを可能にするセッション確立要求に追加する必要があります。
Megaco: There is a directionality component implicit in this requirement in that the MA initiates the establishment of the authorized session. Megaco defines this association to be established in the opposite direction, i.e., the Middlebox(MG) initiates the establishment. If this restriction is not considered, then Megaco makes the syntax and semantics available for the endpoint to initiate the connection.
MEGACOは：MAが認可セッションの確立を開始することで、この要件では、暗黙的な方向性コンポーネントがあります。 MEGACO、すなわち、ミドル（MG）の確立を開始する、逆方向に確立するためにこの関連付けを定義します。この制限が考慮されていない場合は、Megacoのは、接続を開始するためのエンドポイントの構文とセマンティクスが使用可能になります。
Diameter: Although this is out of scope, the Diameter specification describes several ways to discover a peer. Having done so, a Diameter node establishes a transport connection (TCP, TLS, or SCTP) to the peer. The two peers then exchange Capability Exchange Request/Answer messages to identify each other and determine the Diameter applications each supports.
直径：これは範囲外であるが、直径仕様はピアを発見するいくつかの方法を記載しています。そうした、Diameterノードは、ピアへのトランスポート接続（TCP、TLS、またはSCTP）を確立します。 2つのピアが、その後交換能力交換要求/お互いを識別し、Diameterアプリケーションにそれぞれがサポートを決定するために、メッセージを回答します。
If the connection between two peers is lost, Diameter prescribes procedures whereby it may be re-established. To ensure that loss of connectivity is detected quickly, Diameter provides the Device-Watchdog Request/Answer messages, to be used when traffic between the two peers is low.
2つのピア間の接続が失われた場合、直径は、それが再確立されてもよいれる手順を規定しています。接続性の損失が迅速に検出されていることを確認するために、直径が2つのピア間のトラフィックが低いときにデバイス・ウォッチドッグ要求/回答メッセージは、使用されることを提供します。
Diameter provides an extensive state machine to govern the relationship between two peers.
直径は、2つのピア間の関係を管理するための広範な状態マシンを提供します。
COPS: COPS does not meet the directionality part of the requirement. The definition of COPS allows a PEP (Middlebox) to establish communication with a PDP (MIDCOM Agent). However, nothing explicitly prohibits a PDP from establishing communication with a PEP. The PEP could have local policies dictating what action to take when it is contacted by an unknown PDP. These actions, defined in the local policies, would ensure the proper establishment of an authorized association.
COPS：COPSは、要件の方向性の一部を満たしていません。 COPSの定義は、PEP（ミドル）がPDP（MIDCOMエージェント）との通信を確立することを可能にします。しかし、何も明示的にPEPとの通信を確立するからPDPを禁止していません。 PEPは、それが未知のPDPと接触する際に取るべきアクションを口述ローカルポリシーを持つことができます。ローカルポリシーで定義されたこれらのアクションは、認可協会の適切な設置を確実にするでしょう。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：P、Megacoの：T、直径：T、COPS：T
SNMP: An SNMP manager can communicate simultaneously with several Middleboxes.
SNMP：SNMPマネージャは、いくつかのMiddleboxesと同時に通信することができます。
RSIP: RSIP sessions are identified by their IP source and destination addresses and their TCP / UDP port numbers. Thus each RSIP client can communicate with multiple servers, and each server can communicate with multiple clients. However, RSIP did not explicitly include agents in its design. The architecture and semantics of RSIP messages do not preclude agents, thus the RSIP architecture could certainly be extended to explicitly include agents; therefore RSIP is deemed partially compliant to this requirement.
RSIPは：RSIPセッションはIP送信元と送信先アドレスとそのTCP / UDPポート番号で識別されています。したがって、各RSIPクライアントは、複数のサーバと通信することができ、および各サーバは複数のクライアントと通信することができます。しかし、RSIPは明示的にその設計のエージェントが含まれていませんでした。アーキテクチャとRSIPメッセージの意味は、このようにRSIPアーキテクチャは確かに明示的に薬を含むように拡張することができ、薬を排除するものではありません。したがって、RSIPは、この要件に部分的に準拠したものとみなされます。
Megaco: Megaco allows an MA to control several Middleboxes. Each message carries an identifier of the endpoint that transmitted the message allowing the recipient to determine the source.
MEGACO：MEGACOには、いくつかのMiddleboxesを制御するために、MAを可能にします。各メッセージは、受信者がソースを決定することを可能にするメッセージを送信したエンドポイントの識別子を運びます。
Diameter: Diameter allows connection to more than one peer (and encourages this for improved reliability). Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion.
直径：直径は、複数のピアとの接続を可能にする（および信頼性の向上のためにこれを奨励します）。直径接続状態マシンが必要な接続の数をサポートするためには重すぎるかどうかは、議論の問題です。
COPS: COPS PDPs are designed to communicate with several PEPs.
COPS：COPSのPDPのは、いくつかのPEPと通信するように設計されています。
SNMP: T, RSIP: P, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：P、Megacoの：T、直径：T、COPS：T
SNMP: An SNMP agent can communicate with several SNMP managers Simultaneously.
SNMP：SNMPエージェントは、同時に複数のSNMPマネージャと通信することができます。
RSIP: Refer to 2.1.2.
RSIPは：2.1.2を参照してください。
Megaco: Megaco has the concept of Virtual Media Gateways (VMG), allowing multiple MGCs to communicate simultaneously with the same MG. Applying this model to MIDCOM would allow the same middlebox (MG) to have associations with multiple MIDCOM Agents (MGCs).
MEGACO：Megacoのは、複数のMGCは同じMGと同時に通信できるように、仮想メディアゲートウェイ（VMG）の概念を持っています。 MIDCOMにこのモデルを適用すると、同じミドル（MG）は、複数のMIDCOMエージェント（MGCの）との関連を持つことができるようになります。
Diameter: Diameter allows connection to more than one peer and encourages this for improved reliability. Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. The Middlebox and Agent play symmetric roles as far as Diameter peering is concerned.
直径：直径が複数のピアとの接続を可能にし、信頼性向上のためにこれを奨励。直径接続状態マシンが必要な接続の数をサポートするためには重すぎるかどうかは、議論の問題です。ミドルとエージェントは限り直径ピアリングに関しては対称な役割を果たしています。
COPS: The COPS-PR framework specifies that a PEP should have a unique PDP in order to achieve effective policy control. The COPS-PR protocol would allow the scenario whereby a PEP establishes communication with multiple PDPs by creating a COPS client instance per PDP.
COPS：COPS-PRのフレームワークは、PEPは、効果的なポリシー制御を実現するために、独自のPDPを持つべきであることを指定します。 COPS-PRプロトコルは、PEPはPDP当たりCOPSクライアント・インスタンスを作成することにより、複数のPDPとの通信を確立することによりシナリオを可能にします。
2.1.4. Deterministic Outcome When Multiple Requests are Presented to the Middlebox Simultaneously
2.1.4. 複数の要求を同時にミドルに提示される決定論的アウトカム
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: While the architectural design of SNMP can permit race conditions to occur, there are mechanisms defined as part of the SNMPv3 standard, such as view-based access control and advisory locking that can be used to prevent the conditions, and MIB modules may also contain special functionality, such as RMONs OwnerString, to prevent conflicts. Deterministic behavior of SNMP agents when being accessed by multiple managers is important for several management applications and supported by SNMP.
SNMP：SNMPの建築設計が発生する競合状態を可能にすることができるが、そのようなビューベースアクセス制御および状態を予防するために使用することができるアドバイザリロックとしてSNMPv3の規格の一部として定義されたメカニズム、およびMIBモジュールが存在もよいです競合を防ぐために、このようRMONs OwnerStringなどの特別な機能が含まれています。複数のマネージャによってアクセスされているSNMPエージェントの決定論的挙動は、いくつかの管理アプリケーションのための重要なおよびSNMPによってサポートされています。
RSIP: All RSIP requests are defined to be atomic. Near simultaneous requests are executed as is they were sequential.
RSIP：すべてのRSIP要求がアトミックになるように定義されています。同時リクエストの近くに、彼らはシーケンシャルたあるとして実行されています。
Megaco: Megaco supports the concept of VMGs to make these interactions deterministic and to avoid resource access conflicts. Each VMG has a single owner, in a MGC, and there can be no overlap between the sets of Terminations belonging to multiple VMGs. The Megaco protocol messages also include the identifier of the sending entity, so that the MG can easily determine to whom to send the response or asynchronously report certain events.
MEGACO：Megacoのは、これらの相互作用は、決定論的にすると、リソースへのアクセスの競合を回避するためにVMGsの概念をサポートしています。各VMGはMGCに、単一の所有者を有し、複数VMGsに属する終端のセット間に重複が存在することはできません。 MGは簡単に応答を送信したり、非同期的に、特定のイベントを報告するために誰に判断できるように、Megacoのプロトコルメッセージはまた、送信側エンティティの識別子が含まれます。
Diameter: Diameter depends partly upon the transport protocol to provide flow control when the server becomes heavily loaded. It also has application-layer messaging to indicate that it is too busy or out of space (Diameter_TOO_BUSY and Diameter_OUT_OF_SPACE result codes).
直径：直径は、サーバが高負荷になった場合、フロー制御を提供するために、一部のトランスポートプロトコルに依存します。また、それはあまりにも忙しいまたはスペース（Diameter_TOO_BUSYとDiameter_OUT_OF_SPACE結果コード）の外であることを示すために、アプリケーション層のメッセージングを持っています。
COPS: COPS has built-in support for clear state and policy instances. This would allow the creation of well-behaved MIDCOM state machines.
COPS：COPSが組み込まれている明確な状態と政策のインスタンスをサポートしています。これは行儀MIDCOMステートマシンの作成を可能にします。
SNMP: T, RSIP: T, Megaco: T, Diameter: P, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：P、COPS：T
SNMP: Requests are atomic in SNMP. MIB modules can define which data is persistent across reboots, so a known startup state can be established. The manager can poll the agent to determine the current state.
SNMP：要求はSNMPでアトミックです。 MIBモジュールは、データがリブート永続的であるため、既知の起動状態を確立することができるかを定義することができます。管理者は、現在の状態を判断するために、エージェントをポーリングすることができます。
RSIP: RSIP assumes that on middlebox start-up no sessions are defined, and thus no allocations have been made. In effect, all resources are released upon restart after failure.
RSIP：RSIPは起動ミドルに何のセッションが定義されていないので、何の割り当ては行われていないことを前提としています。実際には、すべてのリソースが失敗した後、再起動の際に放出されています。
Megaco: Megaco has extensive audit capabilities to synchronize states between the MG and the MGC. Megaco also provides the MGC with the ability to do mass resets, as well as individual resets. The MGC can always release resources in the MG. The MG can also initiate the release of resources by the MGC.
MEGACO：MegacoのはMGとMGC間の状態を同期させるための広範な監査機能を持っています。 MEGACOも質量リセットを行う能力、ならびに個々のリセットとMGCを提供します。 MGCは常にMGにリソースを解放することができます。 MGはまた、MGCによって、リソースの解放を開始することができます。
Diameter: Diameter documentation does not discuss the degree of atomicity of message processing, so this would have to be specified in the MIDCOM extension.
直径：直径のドキュメントは、メッセージ処理のアトミック性の程度を議論していないので、これはMIDCOM拡張子で指定する必要があります。
COPS: The COPS protocol maintains synchronized states between Middleboxes and MA hence all the states are known on both sides.
COPS：COPSプロトコルは、したがって、すべての状態が両側に知られているのMiddleboxesとMAとの間の同期状態を維持します。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: The status of a middlebox can be reported using asynchronous communications, or via polling.
SNMP：ミドルのステータスは、またはポーリング経由で非同期通信を使用して報告することができます。
RSIP: All RSIP client requests have explicit server responses. Additionally, a client may explicitly request server status using a QUERY request.
RSIP：すべてのRSIPクライアント要求は、明示的なサーバーの応答を持っています。さらに、クライアントは、明示的に照会要求を使用して、サーバーの状態を要求することができます。
Megaco: Megaco has extensive audit capabilities for the MG to report status information to the MGC. It can also report some status updates using the ServiceChange command.
MEGACO：MGはMGCにステータス情報を報告するためのMegacoは、大規模な監査機能を持っています。それはまたのServiceChangeコマンドを使用して、いくつかのステータスの更新を報告することができます。
Diameter: Diameter provides a number of response codes by means of which a server can indicate error conditions reflecting status of the server as a whole. The Disconnect-Peer-Request provides a means in the extreme case to terminate a connection with a peer gracefully, informing the other end about the reason for the disconnection.
直径：直径サーバが全体としてサーバの状態を反映するエラー状態を示すことができ、これにより応答コードの数を提供します。切断ピア・リクエスト切断理由に関する他端に知らせる、正常にピアとの接続を終了するために、極端な場合に手段を提供します。
COPS: The COPS Report message is designed to indicate any asynchronous conditions/events.
COPS：COPS Reportメッセージは、任意の非同期条件/イベントを示すために設計されています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: SNMPv3 supports both confirmed and unconfirmed asynchronous notifications.
SNMP：SNMPv3の両方の確認及び未確認の非同期通知をサポートしています。
RSIP: An RSIP server will send an unsolicited DE_REGISTER_RESPONSE to force an RSIP host to relinquish all of its bindings and terminate its relationship with the RSIP gateway. An RSIP server can send an asynchronous ERROR_RESPONSE to indicate less severe conditions.
RSIP：RSIPサーバは、そのバインディングのすべてを放棄し、RSIPゲートウェイとの関係を終了させるためにRSIPホストを強制的に迷惑DE_REGISTER_RESPONSEを送信します。 RSIPサーバは、それほど厳しい条件を示すために、非同期ERROR_RESPONSEを送ることができます。
Megaco: Megaco supports the asynchronous notification of events using the Notify command.
MEGACO：MEGACOは、通知コマンドを使用して、イベントの非同期通知をサポートしています。
Diameter: The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports Middlebox-originated messages.
直径：Diameterプロトコルがトランザクションを発信するための接続のいずれかのピアを可能にします。したがって、プロトコルはミドル発信メッセージをサポートしています。
COPS: The COPS Report message is designed to indicate any asynchronous conditions/events.
COPS：COPS Reportメッセージは、任意の非同期条件/イベントを示すために設計されています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: SNMPv3 meets this requirement. SNMPv3 supports user authentication and explicitly supports symmetric secret key encryption between MIDCOM agent (SNMP manager) and Middlebox (SNMP agent), thus supporting mutual authentication. The default authentication and encryption methods are specified in RFC 3414 [11] (MD5, SHA-1, and DES). Different users at the same management application (MIDCOM agent) can authenticate themselves with different authentication and encryption methods, and additional methods can be added to SNMPv3 entities as needed.
SNMP：SNMPv3はこの要件を満たしています。 SNMPv3はユーザー認証をサポートしており、明示的にので、相互認証をサポートし、MIDCOMエージェント（SNMPマネージャ）とミドル（SNMPエージェント）間の対称秘密鍵暗号化をサポートしています。デフォルトの認証および暗号化の方法は、RFC 3414 [11]（MD5、SHA-1、およびDES）で指定されています。同じ管理アプリケーション（MIDCOMエージェント）で異なるユーザが異なる認証方式と暗号化方式で自身を認証することができ、必要に応じて追加的な方法は、SNMPv3のエンティティに追加することができます。
RSIP: This requirement can be met by operating RSIP over IPSec as described in RFC 3104 [19]. The RSIP framework recommends all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and avoid replay attacks with an anti-replay counter. However, the message hash and replay counter parameters would need to be defined for the RSIP protocol.
RSIPは：RFC 3104 [19]に記載されているように、この要件は、IPSec上RSIPを操作することによって満たすことができます。 RSIPフレームワークは、RSIPホストとゲートウェイの間のすべての通信を認証することをお勧めします。認証は、各RSIPプロトコルパケットの末尾に付加されたメッセージのハッシュの形で、互いにRSIPホストとゲートウェイを認証するメッセージの完全性を提供し、アンチリプレイカウンタとリプレイ攻撃を回避するために役立つことができます。しかし、メッセージのハッシュとリプレイカウンタパラメータはRSIPプロトコルのために定義される必要があるであろう。
Megaco: Megaco provides for the use of IPSec [22] for all security mechanisms including mutual authentication, integrity check and encryption. Use of IKE is recommended with support of RSA signatures and public key encryption.
MEGACO：MEGACOは、相互認証、整合性チェックや暗号化など、すべてのセキュリティ・メカニズムのためのIPSec [22]の使用を提供します。 IKEの使用は、RSA署名と公開鍵暗号のサポートをお勧めします。
Diameter: The Diameter base protocol assumes that messages are secured by using either IPSec or TLS [21]. Diameter requires that when using the latter, peers must mutually authenticate themselves.
直径：直径ベースプロトコルは、メッセージがIPSecまたはTLS [21]のいずれかを使用して固定されていることを前提としています。直径は後者を使用している場合、ピアが相互に自分自身を認証しなければならないことが必要です。
COPS: COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec.
COPS：COPSは組み込まれていたメッセージレベルのセキュリティ認証、再生保護、およびメッセージの整合性のために。 COPSはまた、TLSまたはIPSecを使用することができます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: Each SNMPv3 message is authenticated and authorized, so each message could be considered to have its own session, which automatically terminates after processing. Processing may be stopped for a number of reasons, such as security, and a response is sent.
SNMP：各SNMPv3のメッセージが認証および承認ので、各メッセージは自動的に処理した後に終了独自のセッションを、持っていると考えることができています。処理は、セキュリティなどの理由から、多くのために停止することができ、応答が送信されます。
Either peer may stop operating, and be unavailable for further operations. The authentication and/or authorization parameters of a principal may be changed between operations if desired, to prevent further authentication or authorization for security reasons.
ピアが動作を停止し、そして更なる操作のために利用不可能のいずれであってもよいです。所望であれば、プリンシパルの認証および/または認可パラメータは、セキュリティ上の理由のために、さらに認証または許可を防止するために、操作の間に変更されてもよいです。
Additionally, managed objects can be defined for realizing sessions that persist beyond processing of a single message. The MIB module would need to specify the responsibility for cleanup of the objects following normal/abnormal termination.
また、管理オブジェクトは、単一のメッセージの処理を超えて持続セッションを実現するために定義することができます。 MIBモジュールは、正常/異常終了次のオブジェクトのクリーンアップのための責任を指定する必要があります。
RSIP: An RSIP client may terminate a session with a DE_REGISTER_REQUEST. An RSIP server may terminate a session with an unsolicited DE_REGISTER_RESPONSE, and then respond to subsequent requests on the session with a REGISTER_FIRST error.
RSIP：RSIPクライアントはDE_REGISTER_REQUESTとのセッションを終了させることができます。 RSIPサーバは迷惑DE_REGISTER_RESPONSEとのセッションを終了し、その後REGISTER_FIRSTエラーとのセッションのその後の要求に応答することができます。
Megaco: The Megaco protocol allows both peers to terminate the association with proper reason code.
MEGACO：MEGACOプロトコルは、両方のピアが適切な理由コードとの関連付けを終了することを可能にします。
Diameter: Either peer in a connection may issue a Disconnect-Peer-Request to end the connection gracefully.
直径：接続のピアのいずれかが正常に接続を終了する切断ピア・リクエストを発行することができます。
COPS: COPS allows both the PEP and PDP to terminate a session.
COPS：COPSはPEPとPDPの両方がセッションを終了することができます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: Each operation request has a corresponding response message that contains an error status to indicate success or failure. For complex requests that the middlebox cannot complete immediately, the corresponding MIB module may be designed to also provide asynchronous notifications of the success or failure of the complete transaction, and/or may provide pollable objects that indicate the success or failure of the complete transaction. For example, see ifAdminStatus and ifOperStatus in RFC 2863 [28].
SNMP：各操作要求は、成功または失敗を示すエラー・ステータスが含まれている、対応する応答メッセージを持っています。ミドルはすぐに完了することができない複雑な要求の場合、対応するMIBモジュールはまた、完全なトランザクションの成功または失敗の非同期通知を提供するように設計することができる、および/または完全なトランザクションの成功または失敗を示すポーリング可能なオブジェクトを提供することができます。例えば、RFC 2863 [28]でのifAdminStatusとのifOperStatusを参照。
RSIP: All RSIP requests result in a paired RSIP response if the request was successful or an ERROR_RESPONSE if the request was not successful.
RSIP：要求が成功しなかった場合は、要求が成功したかERROR_RESPONSE場合は、すべてのRSIP要求がペアになっRSIPの応答をもたらします。
Megaco: Megaco defines a special descriptor called an Error descriptor that contains the error code and an optional explanatory string.
MEGACO：MEGACOは、エラーコードとオプションの説明の文字列を含むエラー記述子と呼ばれる特殊な記述を定義します。
Diameter: Every Diameter request is matched by a response, and this response contains a result code as well as other information.
直径：すべての直径の要求が応答にマッチし、そしてこの応答は結果コードだけでなく、他の情報が含まれています。
COPS: The COPS Report message directly fulfills this requirement.
COPS：COPS Reportメッセージは、直接この要件を満たしています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: SNMP has a separation of the protocol to carry data, and the data that defines additional management functionality. Additional functionality can be added easily through MIBs. Capability exchange in SNMP is usually uni-directional. Managers can query the middlebox (SNMP agent) to determine which MIBs are supported. In addition, multiple message versions can be supported simultaneously, and are identified by a version number in the message header.
SNMP：SNMPは、データを搬送するためのプロトコルの分離、および追加の管理機能を定義するデータを有しています。追加機能は、MIBを経由簡単に追加することができます。 SNMPでの能力交換は、通常、単方向です。マネージャはサポートされているMIBを決定するために、ミドル（SNMPエージェント）を照会することができます。加えて、複数のメッセージのバージョンが同時にサポートすることができ、メッセージヘッダーのバージョン番号で識別されます。
RSIP: Each RSIP message contains a version parameter.
RSIP：RSIP各メッセージは、バージョンのパラメータが含まれています。
Megaco: Version interworking and negotiation are supported both for the protocol and any extension Packages.
MEGACO：バージョンのインターワーキングとの交渉は、両方のプロトコルと任意の拡張パッケージでサポートされています。
Diameter: The Capabilities Exchange Request/Answer allows two peers to determine information about what each supports, including protocol version and specific applications.
直径：能力交換要求/応答2つのピアがプロトコルバージョンと、特定のアプリケーションを含むものをそれぞれがサポートに関する情報を決定することができます。
COPS: The COPS protocol can carry a MIDCOM version number and capability negotiation between the COPS client and the COPS server. This capability negotiation mechanism allows the COPS client and server to communicate the supported features/capabilities. This would allow seamless version interworking.
COPS：COPSプロトコルはCOPSクライアントとCOPSサーバ間のMIDCOMのバージョン番号と能力交渉を運ぶことができます。この能力交渉メカニズムはCOPSクライアントとサーバがサポートされている機能/性能を通信することができます。これは、シームレスなバージョンのインターワーキングを可能にします。
2.1.12. Deterministic Behaviour in the Presence of Overlapping Rules
2.1.12. 重複するルールの存在下での決定論的挙動
SNMP: T, RSIP: T, Megaco: P, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：P、直径：T、COPS：T
SNMP: Rulesets would be defined in MIBs. The priority of rulesets, and the resolution of conflict, can be defined in the MIB module definition. The SNMPConf policy MIB defines mechanisms to achieve deterministic behavior in the presence of overlapping rule sets.
SNMP：ルールセットのMIBで定義されます。ルールセットの優先度、及び紛争の解決は、MIBモジュール定義で定義することができます。 SNMPCONFポリシーMIBは、ルールセットの重複の存在下で決定論的挙動を達成するためのメカニズムを定義します。
RSIP: All requests for allocation of IP addresses, or ports or both resulting in rule overlap are rejected by an RSIP server with a LOCAL_ADDR_INUSE error.
RSIPは：IPアドレス、またはポートまたはルールオーバーラップを生じる両方の割り当てのためのすべての要求はLOCAL_ADDR_INUSE誤差のRSIPサーバによって拒否されています。
Megaco: This is met with the help of a model that separates Megaco protocol elements from the overlapping Policy rules (see Appendix C). However, new behavior for the Megaco protocol elements needs to be specified as part of a new MIDCOM specific Package.
MEGACO：これは、重複ポリシールールからのMegacoプロトコル要素を分離モデルの助けを借りて満たされている（付録Cを参照してください）。しかし、Megacoのプロトコル要素のための新しい動作は、新しいMIDCOMの特定のパッケージの一部として指定する必要があります。
Diameter: The IPFilterRule type specification, which would probably be used as the type of a Policy Rule AVP, comes with an extensive semantic description providing a deterministic outcome, which the individual Agent cannot know unless it knows all of the Policy Rules installed on the Middlebox. Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. The IPFilterRule format and further details on its applicability to this requirement are provided in Appendix D.
直径：おそらく、ポリシールールのAVPのタイプとして使用されるIPFilterRuleのタイプの仕様は、それがミドルにインストールされているポリシールールのすべてを知っている場合を除き、個々のエージェントは知ることができない決定論的な結果を提供する広範な意味記述、付属しています。適切な方向の規則は評価を終了最初に一致した規則と、順に評価されます。各パケットは一度だけ評価されます。ルールが一致しない場合は、最後に評価ルールが許可した、と最後のルールが拒否した場合は渡された場合、パケットはドロップされます。 IPFilterRuleのフォーマットと、この要件への適用に関する詳細は、付録Dで提供されています
COPS: The COPS protocol provides transactional-based communication between the PEP and PDP, hence the behavior is totally deterministic provided the middlebox state machine is designed correctly. The COPS protocol features encourage and support good state machine design.
COPS：COPSプロトコルは、PEPとPDPの間でトランザクションベースの通信を提供し、したがって挙動がミドル状態マシンが正しく設計されて設けられ全く決定的です。 COPSプロトコル機能を奨励し、良好な状態の機械設計をサポートしています。
This section contains the individual protocols as evaluated against the protocol semantic requirements from section 2.2 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
要件文書[1]のセクション2.2からプロトコルセマンティック要件に対して評価として、このセクションでは、個々のプロトコルを含んでいます。プロトコルのそれぞれの短い説明が評価を実証するために設けられています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: Extensibility is a basic feature of the SNMP management Framework.
SNMP：拡張性は、SNMP管理フレームワークの基本的な機能です。
RSIP: All RSIP messages consist of three mandatory fields (protocol version, message type, and message length) and a sequence of parameterType / length / value 3-tuples. New messages may be defined by defining new values for the message type field. New parameter types may be defined, and existing messages may be extended, by defining new parameterType values. If new messages, parameters, or both are added in a non-backward compatible way, a new value of the protocol version field may be defined. This may be desirable even of the additions are backward compatible.
RSIP：すべてのRSIPメッセージは、3つの必須のフィールド（プロトコルバージョン、メッセージタイプ、およびメッセージの長さ）とのParameterType /長さ/値の3タプルのシーケンスから成ります。新しいメッセージはメッセージタイプフィールドの新しい値を定義することによって定義されてもよいです。新しいパラメータの型を定義することができる、そして既存のメッセージは、新しいのParameterType値を定義することにより、延長することができます。新しいメッセージ、パラメータ、または両方が非下位互換性のある方法で添加される場合、プロトコルバージョンフィールドの新しい値を定義することができます。これは、下位互換性があっても加算のが望ましいかもしれません。
Megaco: Megaco is easily extensible through new Packages, which allow definition of new attributes and behavior of a Termination.
MEGACO：Megacoのは、新しい属性と終了の振る舞いの定義を許可する新しいパッケージを介して、簡単に拡張可能です。
Diameter: Diameter provides a great deal of flexibility for extensions, including allowance for vendor-defined commands and AVPs and the ability to flag each AVP as must-understand or ignorable if not understood.
直径：直径は、ベンダー定義コマンドとのAVPの許容フラグに能力各AVPは理解されていない場合は、理解しなければならない、または無視として含む拡張のために大きな柔軟性を提供します。
COPS: The COPS protocol is extensible, since it was designed to separate the Protocol from the Policy Control Information.
COPS：それはポリシー制御情報からプロトコルを分離するように設計されていたので、COPSプロトコルは、拡張可能です。
SNMP: T, RSIP: P+, Megaco: T, Diameter: P+, COPS: T
SNMP：T、RSIP：Pの+、Megacoの：T、直径：Pの+、COPS：T
SNMP: SNMP explicitly supports managing different device types with different capabilities. First the managed object called sysObjectID from basic MIB-II [3] identifies the type of box. For boxes with variable capabilities, SNMP can check the availability of corresponding MIBs.
SNMP：SNMPは、明示的に異なる機能を持つ管理異なるデバイスタイプをサポートしています。最初の基本的なMIB-II [3]からのsysObjectIDと呼ばれる管理オブジェクトは、ボックスのタイプを識別する。変数機能を備えたボックスの場合、SNMPは、対応するMIBの可用性を確認することができます。
RSIP: All types of middleboxes are supported so long as the ruleset action is permit. Other actions would require the definition of a new RSIP message parameter with values for permit and the other desired actions.
RSIPは：ミドルボックスのすべての種類は、ルールセットのアクションが許可されている限り、サポートされています。他のアクションは、許可証の値および他の所望のアクションを持つ新しいRSIPメッセージパラメータの定義が必要となります。
Megaco: Megaco can support multiple Middlebox types on the same interface either by designing the properties representing the Policy Rules to provide this support, or by using multiple terminations in the same session, each representing one type of action. In the latter case, the Megaco Context can be used as a convenient means of managing the related terminations as a group. However, the inherent idea of flow between terminations of a context is irrelevant and would have to be discarded.
MEGACO：MEGACOは、このサポートを提供するポリシールールを表す特性を設計することによって、または同じセッションで複数の終端を使用して、いずれかのアクションのそれぞれ表す1つのタイプを同じインタフェース上に複数のミドルタイプをサポートすることができます。後者の場合には、Megacoのコンテキストは、グループとして、関連する終端を管理するための便利な手段として使用することができます。しかし、コンテキストの終端との間の流れの固有のアイデアは無関係であり、そして廃棄しなければならないであろう。
Diameter: Any necessary additional AVPs or values must be specified as part of the MIDCOM application extension (see <2.2.8> below).
直径：任意の必要な追加のAVPまたは値が（下記参照<2.2.8>）MIDCOMアプリケーション拡張機能の一部として指定されなければなりません。
COPS: COPS allows a PDP to provide filters and actions to multiple PEP functions through a single COPS session.
COPS：COPSは、単一COPSセッションを介して複数のPEP機能にフィルタと処置を提供するために、PDPすることができます。
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：Pの+、Megacoの：T、直径：T、COPS：T
SNMP: This requirement can be realized via the SNMP management framework by an appropriate definition of a MIB module. The SNMPConf WG has already defined an SNMP Policy MIB that permits the definitions of policy rulesets and grouping of rulesets.
SNMP：この要件は、MIBモジュールの適切な定義によって、SNMP管理フレームワークを介して実現することができます。 SNMPCONF WGは、すでにポリシールールセットとルールセットのグループ化の定義を許可するSNMP MIBポリシーを定義しています。
RSIP: RSIP currently only allows one IP address, or address and port range, to be assigned to a bind-ID. RSIP could implement rulesets as required by adding an optional bind-ID parameter to the ASSIGN_REQUESTs to extend an existing ruleset rather than creating a new one. Similarly, the FREE_REQUESTs would have to be extended by adding optional, local and remote, address and port parameters.
RSIP：RSIPは現在、1つのIPアドレスのみを許可する、またはアドレスとポート範囲は、バインドIDに割り当てられます。既存のルールセットを拡張するためにASSIGN_REQUESTsに、オプションのバインド-IDパラメータを追加するのではなく、新しいものを作成することによって、必要に応じRSIPは、ルールセットを実装することができます。同様に、FREE_REQUESTsは、オプションのローカルおよびリモートのアドレスとポートのパラメータを追加することによって拡張されなければなりません。
Megaco: The Megaco context can be used to group terminations to be managed together. For example, all of the terminations, each representing an instantiation of a Policy Rule, can be deleted in one command by doing a wildcarded Subtract from the context. However, the inherent idea of media flows between terminations of a context would be irrelevant in this application of the protocol.
MEGACO：MEGACOコンテキストをまとめて管理するグループの終端に使用することができます。例えば、終端の全ては、ポリシールールのインスタンス化を表すそれぞれが、文脈からワイルドカードの減算を行うことによって、1つのコマンドで削除することができます。しかし、メディアの固有のアイデアは、プロトコルのこの出願に無関係であろうコンテキストの終端間を流れます。
Diameter: Diameter allows message syntax definitions where multiple instances of the same AVP (for example, a Policy Rule AVP whose syntax and low-level semantics are defined by the IPFilterRule type definition) may be present. If a tighter grouping is required, the set of Diameter base types includes the Grouped type. MIDCOM can choose how to make use of these capabilities to meet the ruleset group requirement when defining its application extension to the Diameter protocol.
直径：直径は同じAVPの複数のインスタンス（たとえば、構文および低レベルのセマンティクスIPFilterRuleのタイプ定義によって定義されるポリシールールAVP）が存在することができるメッセージの構文の定義を可能にします。緊密なグループ化が必要とされる場合、直径基本型のセットをグループ化タイプを含みます。 MIDCOMは、Diameterプロトコルにそのアプリケーションの拡張子を定義するときにルールセットグループの要件を満たすために、これらの機能を利用するためにどのように選択することができます。
COPS: The COPS-PR Handle State may be used to associate the set of closely related policy objects. As the Middlebox learns additional requirements, the Middlebox adds these resource requirements under the same handle ID, which constitutes the required aggregation.
COPS：COPS-PRは、国家ハンドルは密接に関連したポリシーオブジェクトのセットを関連付けるために使用することができます。ミドルは、追加の要件を学習として、ミドルは、必要な集約を構成する同じハンドルID、下にこれらのリソース要件を追加します。
SNMP: P+, RSIP: T, Megaco: T, Diameter: T, COPS: P+
SNMP：P +、RSIP：T、Megacoの：T、直径：T、COPS：P +
SNMP: This requirement can be realized via the SNMP management framework by an appropriate definition of a MIB module. The SNMPConf WG has developed a Policy MIB module that includes a pmPolicySchedule object with a modifiable lifetime.
SNMP：この要件は、MIBモジュールの適切な定義によって、SNMP管理フレームワークを介して実現することができます。 SNMPCONF WGは、変更可能な寿命を持つpmPolicyScheduleオブジェクトを含むポリシーMIBモジュールを開発しました。
RSIP: A client may request an explicit lease time when a request is made to assign one or more IP addresses, ports or both. The server may grant the requested lease time, or assign one if none was requested. Subsequently, the lease time may be extended if a client's EXTEND_REQUEST is granted by the server.
RSIP：クライアントは、要求が1つ以上のIPアドレス、ポートまたはその両方を割り当てるために作られ、明示的なリース時間を要求することができます。サーバーは、要求されたリース時間を与える、または何も要求されなかった場合は、1つを割り当てることができます。クライアントのEXTEND_REQUESTがサーバーによって許可された場合はその後、リース期間を延長することができます。
Megaco: The MG can report the imminent expiry of a policy rule to the MGC, which can then extend or delete the corresponding Termination.
MEGACO：MGは、対応するターミネーションを拡張したり削除することができた、MGCにポリシールールの差し迫った有効期限を報告することができます。
Diameter: The Diameter concept of a session includes the session lifetime, grace period, and lifetime extension. It may make sense to associate the Diameter session with the lifetime of a MIDCOM Policy Rule, in which case support for lifetime extension comes ready-made.
直径：セッションの直径のコンセプトは、セッションの有効期間、猶予期間、および寿命の延長を含んでいます。これは、長寿命化のためのサポートは既製来た場合にはMIDCOM政策ルールの生涯と直径のセッションを関連付けるために意味をなさないことがあります。
COPS: COPS allows a PDP to send unsolicited decisions to the PEP. However, the unsolicited events will be relevant to the COPS MIDCOM specific client or the MIDCOM specific PIB which needs to be defined. This would allow the PDP to extend the lifetime of an existing ruleset.
COPS：COPS PDPはPEPへ未承諾の意思決定を送信することができます。しかし、迷惑なイベントを定義する必要がCOPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBに関連するだろう。これは、PDPは、既存のルールセットの寿命を延長することができるようになります。
SNMP: T, RSIP: T, Megaco: P+, Diameter: P+, COPS: T
SNMP：T、RSIP：T、Megacoの：Pの+、直径：Pの+、COPS：T
SNMP: Unknown attributes in a read operation are flagged as exceptions in the Response message, but the rest of the read succeeds. In a write operation (a SET request), all attributes are validated before the write is performed. If there are unknown attributes, the request fails and no writes are done. Unknown attributes are flagged as exceptions in the Response message, and the error status is reported.
SNMP：読み出し動作における未知の属性は、応答メッセージで例外としてフラグが立てられているが、読むの残りの部分は成功します。書き込みが実行される前に書き込み動作（SET要求）において、すべての属性が検証されています。不明な属性がある場合、要求は失敗し、書き込みが行われていません。不明な属性は、応答メッセージで例外としてフラグ付けされ、エラー状態が報告されています。
RSIP: All options of all requests are fully specified. Not understood parameters must be reported by an ERROR_RESPONSE with an EXTRA_PARM error value, with the entire request otherwise ignored.
RSIP：すべての要求のすべてのオプションが完全に指定されています。全体の要求はそれ以外の場合は無視して理解のパラメータは、EXTRA_PARMエラー値とERROR_RESPONSEによって報告されなければなりません。
Megaco: Megaco entities provide Error codes in response messages. If a command marked "Optional" in a transaction fails, the remaining commands will continue. However, the specified requirement deals with rules of processing properties that need definition in new Package.
MEGACO：MEGACOエンティティは、応答メッセージにエラーコードを提供しています。トランザクションで「オプション」と記されたコマンドが失敗した場合、残りのコマンドは続行されます。しかし、新しいパッケージで定義を必要とする加工特性の規則に指定された要件を扱っています。
Diameter: Indication of the mandatory or optional status of AVPs is fully supported, provided it is enabled in the AVP definition. No guidance is imposed regarding the return of diagnostic information for optional AVPs.
直径：のAVPの必須またはオプションのステータスの表示が完全にサポートされているが、それはAVP定義で有効になっていました。何ガイダンスは、オプションのAVPのための診断情報の復帰に関して課されません。
COPS: COPS provides for the exchange of capabilities and limitations between the PEP and PDP to ensure well-known outcomes are understood for scenarios with unknown attributes. There is also clear error handling for situations when the request is rejected.
COPS：COPSは、よく知られている結果は、未知の属性を持つシナリオで理解されるようにするPEPとPDPの間の能力と限界の交換を提供します。要求が拒否される状況に取り扱う明確なエラーもあります。
SNMP: T, RSIP: P+, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：Pの+、Megacoの：T、直径：T、COPS：T
SNMP: The SNMPv3 protocol returns error codes and exception codes in Response messages, to permit the requestor to modify their request. Errors and exceptions indicate the attribute that caused the error, and an error code identifies the nature of the error encountered.
SNMP：SNMPv3プロトコルは、彼らの要求を修正するために、リクエスタを可能にするために、応答メッセージにエラーコードと例外コードを返します。エラーと例外がエラーの原因となった属性を示し、エラーコードが発生したエラーの性質を特定します。
If desired, a MIB can be designed to provide additional data about error conditions either via asynchronous notifications or polled objects.
所望の場合、MIBは、非同期通知またはポーリングオブジェクトを介してのいずれかのエラー状態に関する追加データを提供するように設計することができます。
RSIP: RSIP defines a fairly large number of very specific error values. It is anticipated that additional error values will also have to be defined along with the new messages and parameters required for MIDCOM.
RSIP：RSIPは非常に特定のエラー値のかなり大きな数を定義します。追加のエラー値もMIDCOMに必要な新しいメッセージやパラメータと共に定義されなければならないことが予想されます。
Megaco: The MG can provide Error codes in response messages allowing the MGC to modify its behavior. Megaco uses transaction identifiers for correlation between a response and a command. If the same transaction id is received more than once, the receiving entity silently discards the message, thus providing some protection against replay attacks.
MEGACO：MGは、MGCは、その動作を変更することができ、応答メッセージにエラーコードを提供することができます。 MEGACOは、応答とコマンドの間の相関のためのトランザクション識別子を使用しています。同じトランザクションIDが複数回受信された場合、受信エンティティは黙っので、リプレイ攻撃に対する何らかの保護を提供し、メッセージを破棄します。
Diameter: Diameter provides an extensive set of failure reasons in the base protocol.
直径：直径は、ベースプロトコルの失敗の理由の拡張セットを提供します。
COPS: COPS uses an error object to identify a particular COPS protocol error. The error sub-code field may contain additional detailed COPS client (MIDCOM Middlebox) specific error codes.
COPS：COPSは、特定のCOPSプロトコルエラーを識別するために、エラーオブジェクトを使用します。エラーサブコードフィールドは、追加の詳細COPSクライアント（MIDCOMミドル）特定のエラーコードを含んでいてもよいです。
SNMP: T, RSIP: P, Megaco: P, Diameter: T, COPS: P
SNMP：T、RSIP：P、Megacoの：P、直径：T、COPS：P
SNMP: The SNMP framework supports multiple managers working on the same managed objects. The View-based Access Control Model (VACM, RFC 3415 [14]) even offers means to customize the access rights of different managers in a fine-grained way.
SNMP：SNMPフレームワークは、同じ管理対象オブジェクト上で動作する複数のマネージャをサポートしています。ビューベースアクセス制御モデル（VACM、RFC 3415 [14]）も、きめ細かな方法で、異なる管理者のアクセス権をカスタマイズするための手段を提供しています。
RSIP: RSIP neither explicitly permits nor precludes an operation on a binding by a host that had not originally create the binding. However, to support this requirement, the RSIP semantics must be extended to explicitly permit any authorized host to request operations on a binding; this does not require a change to the protocol.
RSIP：RSIPはどちらも明示的に許可したり、もともとバインディングを作成していなかったホストによって結合の操作を妨げます。しかし、この要件をサポートするために、RSIPセマンティクスが明示的バインディングの操作を要求するために、任意の認可のホストを許可するように拡張されなければなりません。これは、プロトコルの変更を必要としません。
Megaco: If the Megaco state machine on the Middle Box is decoupled from the Middle Box policy rule management, this requirement can be met with local policies on the Middle Box. However, this violates the spirit of the Megaco protocol, thus Megaco is considered partially compliant to this requirement.
MEGACO：中央のボックスにMegacoのステートマシンは、中央のボックスポリシールールの管理から切り離された場合は、この要件は、中央のボックスにローカルポリシーを満たすことができます。しかし、これは、このようにMegacoのは、この要件に部分的に準拠したとみなされ、Megacoのプロトコルの精神に違反します。
Diameter: The Diameter protocol, as currently defined, would allow multiple agents to operate on the same ruleset.
直径：Diameterプロトコルは、現在定義されているように、複数のエージェントが同じルールセット上で動作することを可能にします。
COPS: It is possible to use COPS to operate the same resource with multiple agents. An underlying resource management function, separate from the COPS state machine, on the Middlebox will handle the arbitration when resource conflicts happen.
COPS：それは、複数のエージェントと同じリソースを操作するためにCOPSを使用することが可能です。リソースの競合が発生したときにミドルのCOPSステートマシンから別の基本的なリソース管理機能は、仲裁を処理します。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP：P +、RSIP：P +、Megacoの：P +、直径：Pの+、COPS：Pの+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement.
SNMP：この要件はMIDCOM MIBモジュールの適切な定義によって満たすことができます。 SMI、MIBモジュールを定義するために使用される言語は、この要件のセマンティクスを満たすために、MIBモジュールの実装を可能にするのに十分に柔軟です。
RSIP: To support this requirement, a new optional enumeration parameter, transportProtocol, can be added to the RSIP ASSIGN_REQUESTs. When the parameter is included, the binding created applies only to the use of the bound addresses and ports, by the specific transportProtocol. When the parameter is not included, the binding applies to the use of all the bound addresses and ports, by any transport protocol, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：この要件は、新しいオプションの列挙パラメータをサポートするために、transportProtocolは、RSIP ASSIGN_REQUESTsに追加することができます。パラメータが含まれている場合、作成された特異的結合transportProtocolによって、唯一のバインドアドレスとポートの使用に適用されます。パラメータが含まれない場合、結合は、このようにRSIPの現在の定義との後方互換性を維持し、任意のトランスポートプロトコルによって、全ての結合したアドレスとポートの使用に適用されます。
Megaco: Megaco protocol can meet this requirement by defining a new property for the transport of filtering rules.
MEGACO：MEGACOプロトコルは、フィルタリングルールの輸送のための新しいプロパティを定義することによって、この要件を満たすことができます。
Diameter: While Diameter defines the promising IPFilterRule data type (see 2.1.12 above), there is no existing message, which would convey this to a Middlebox along with other required MIDCOM attributes. A new MIDCOM application extension of Diameter would have to be defined.
直径：直径は有望IPFilterRuleのデータタイプ（上記2.1.12を参照）を定義しているが、他の必要なMIDCOM属性と共にミドルにこれを伝えることになる既存のメッセージは、存在しません。直径の新しいMIDCOMアプリケーション拡張が定義されなければなりません。
COPS: The COPS protocol can meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルは、COPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用して、この要件を満たすことができます。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: P+, COPS: P+
SNMP：P +、RSIP：P +、Megacoの：P +、直径：Pの+、COPS：Pの+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module.
SNMP：この要件はMIDCOM MIBモジュールの適切な定義によって満たすことができます。
RSIP: To support this requirement, a new optional boolean parameter, portOddity, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the remote port number of the binding created would have the same oddity as the local port. If the parameter is not specified, or is FALSE, the remote port's oddity is independent of the local port's oddity, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：この要件をサポートするために、新しいオプションのブール・パラメータ、portOddityは、RSIP ASSIGN_REQUESTsに追加することができます。パラメータがTRUEの場合、結合作成のリモートポート番号、ローカルポートと同じ奇妙を持っているでしょう。パラメータが指定された、またはFALSEですされていない場合は、リモートポートの風変わりは、このようにRSIPの現在の定義との後方互換性を維持し、ローカルポートの風変わりとは無関係です。
Megaco: Megaco can be easily extended using a MIDCOM specific Package to support this feature.
MEGACO：Megacoのは、簡単にこの機能をサポートするためにMIDCOMの特定のパッケージを使用して拡張することができます。
Diameter: This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, MIDCOM could group it with other AVPs which add the missing information.
直径：この機能は現在IPFilterRuleの型定義の一部ではありません。 IPFilterRuleのタイプを変更するのではなく、MIDCOMが不足している情報を追加し、他のAVPを持つグループそれをできました。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルはCOPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用して、この要件を満たすために、すべての柔軟性を持っています。
SNMP: P+, RSIP: T, Megaco: P+, Diameter: P+, COPS: P+
SNMP：P +、RSIP：T、Megacoの：Pの+、直径：Pの+、COPS：Pの+
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module. SMI, the language used for defining MIB modules, is flexible enough to allow the implementation of a MIB module to meet the semantics of this requirement.
SNMP：この要件はMIDCOM MIBモジュールの適切な定義によって満たすことができます。 SMI、MIBモジュールを定義するために使用される言語は、この要件のセマンティクスを満たすために、MIBモジュールの実装を可能にするのに十分に柔軟です。
RSIP: The ports parameter of the RSIP ASSIGN_REQUESTs specifically allows multiple, consecutive port numbers to be specified.
RSIP：RSIP ASSIGN_REQUESTsのポートパラメータは、具体的には、複数の連続したポート番号が指定されることを可能にします。
Megaco: Megaco can be easily extended using a MIDCOM specific Package to support this feature.
MEGACO：Megacoのは、簡単にこの機能をサポートするためにMIDCOMの特定のパッケージを使用して拡張することができます。
Diameter: This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, MIDCOM could group it with other AVPs which add the missing information.
直径：この機能は現在IPFilterRuleの型定義の一部ではありません。 IPFilterRuleのタイプを変更するのではなく、MIDCOMが不足している情報を追加し、他のAVPを持つグループそれをできました。
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルはCOPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用して、この要件を満たすために、すべての柔軟性を持っています。
SNMP: P+, RSIP: P+, Megaco: P+, Diameter: T, COPS: P+
SNMP：P +、RSIP：P +、Megacoの：P +、直径：T、COPS：P +
SNMP: This requirement can be met by an appropriate definition of a MIDCOM MIB module.
SNMP：この要件はMIDCOM MIBモジュールの適切な定義によって満たすことができます。
RSIP: To support this requirement, a new optional boolean parameter, overlapOK, can be added to the RSIP ASSIGN_REQUESTs. If the parameter is TRUE, the binding may overlap with an existing binding. If the parameter is unspecified, or is FALSE, the binding will not overlap with an existing binding, thus maintaining backward compatibility with the current definition of RSIP.
RSIP：この要件をサポートするために、新しいオプションのブール・パラメータ、overlapOKは、RSIP ASSIGN_REQUESTsに追加することができます。パラメータがTRUEである場合、結合は、既存の結合と重複してもよいです。パラメータが指定されていない、またはFALSEである場合、結合は、このようにRSIPの現在の定義との後方互換性を維持し、既存の結合と重複しないであろう。
Megaco: This requirement would be met if the policy in the Middlebox allows contradictory, overlapping policy rules to be installed.
MEGACO：ミドルでの政策は矛盾し、重複ポリシールールをインストールすることを可能にする場合は、この要件が満たされることになります。
Diameter: Allowed by the IPFilterRule semantics described in Appendix D.
直径：付録D.で説明IPFilterRuleのセマンティクスによって可
COPS: The COPS protocol has all the flexibility to meet this requirement by using a COPS MIDCOM specific client or a MIDCOM specific PIB.
COPS：COPSプロトコルはCOPS MIDCOMの特定のクライアントかMIDCOMの特定のPIBを使用して、この要件を満たすために、すべての柔軟性を持っています。
This section contains the individual protocols as evaluated against the General Security requirements from section 2.3 of the requirements document [1]. A short description of each of the protocols is provided to substantiate the evaluation.
このセクションでは、要件ドキュメント[1]のセクション2.3から一般的なセキュリティ要件に照らして評価されるように個々のプロトコルが含まれています。プロトコルのそれぞれの短い説明が評価を実証するために設けられています。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: SNMPv3 includes the User-based Security Model (USM, RFC 3414 [11]), which defines three standardized methods for providing authentication, confidentiality, and integrity. Additionally, USM has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages.
SNMP：SNMPv3の認証、機密性、および完全性を提供するための3つの標準化されたメソッドを定義するユーザベースセキュリティモデル（USM、RFC 3414 [11]）を含みます。さらに、USMは、独自のプロトコルエンジンIDは、タイマーとメッセージの有効性のためのエンジンと時間窓あたりのカウンターなど、リプレイ攻撃を防ぐための具体的な組み込みのメカニズムがあります。
RSIP: This requirement can be met by operating RSIP over IPSec. The RSIP framework recommends all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and avoid replay attacks with an anti-replay counter. However, the message hash and replay counter parameters would need to be defined for the RSIP protocol.
RSIP：この要件は、IPSec上のオペレーティングRSIPによって満たすことができます。 RSIPフレームワークは、RSIPホストとゲートウェイの間のすべての通信を認証することをお勧めします。認証は、各RSIPプロトコルパケットの末尾に付加されたメッセージのハッシュの形で、互いにRSIPホストとゲートウェイを認証するメッセージの完全性を提供し、アンチリプレイカウンタとリプレイ攻撃を回避するために役立つことができます。しかし、メッセージのハッシュとリプレイカウンタパラメータはRSIPプロトコルのために定義される必要があるであろう。
Megaco: Megaco provides for these functions with the combined usage of IPSEC [22] or TLS [21].
MEGACO：MEGACOはIPSEC [22]またはTLS [21]の合成使用してこれらの機能を提供します。
Diameter: Diameter relies on either IPSEC or TLS for these functions.
直径：直径は、これらの機能のためにIPSECかTLSのどちらかに依存しています。
COPS: COPS has built-in message level security for authentication, replay protection, and message integrity. COPS can also use TLS or IPSec, thus reusing existing security mechanisms that have interoperated in the markets.
COPS：COPSは組み込まれていたメッセージレベルのセキュリティ認証、再生保護、およびメッセージの整合性のために。 COPSはまた、TLSまたはIPSecを使用するため、市場での相互運用している既存のセキュリティ・メカニズムを再利用することができます。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: SNMPv3 includes the User-based Security Model, which defines three standardized methods for providing authentication, confidentiality, and integrity, and is open to add further methods. The method to use can be optionally chosen.
SNMP：SNMPv3は認証、機密性、および完全性を提供するための3つの標準化されたメソッドを定義してユーザベースセキュリティモデルを含み、さらにメソッドを追加することが開いています。使用する方法は、任意に選択することができます。
RSIP: Refer to 2.3.1.
RSIPは：2.3.1を参照してください。
Megaco: Refer to 2.3.1
MEGACO：2.3.1を参照してください。
Diameter: Implementation support of IPSEC ESP (RFC 2406 [23]) in Diameter applications is not optional. Deployment of either IPSEC or TLS is optional.
直径：DiameterアプリケーションのIPsec ESP（RFC 2406 [23]）の実装サポートはオプションではありません。 IPSECかTLSのいずれかの展開はオプションです。
COPS: Refer to 2.3.1.
COPS：2.3.1を参照してください。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: The User-based Security Model of SNMPv3 defines three standardized methods for providing authentication, confidentiality, and integrity, and it is open to add further methods. These methods operate securely across untrusted domains.
SNMP：SNMPv3のユーザベースセキュリティモデルは、認証、機密性、および完全性を提供するための3つの標準化されたメソッドを定義し、さらにメソッドを追加することが開いています。これらのメソッドは、信頼されていないドメイン間で安全に動作します。
RSIP: Refer to 2.3.1.
RSIPは：2.3.1を参照してください。
Megaco: Refer to 2.3.1.
MEGACO：2.3.1を参照してください。
Diameter: The Diameter specification [24] recommends the use of TLS [21] across untrusted domains.
直径：直径仕様[24]は、信頼できないドメイン間でTLS [21]を使用することをお勧めします。
COPS: Refer to 2.3.1
COPS：2.3.1を参照してください。
SNMP: T, RSIP: T, Megaco: T, Diameter: T, COPS: T
SNMP：T、RSIP：T、Megacoの：T、直径：T、COPS：T
SNMP: The User-based Security Model for SNMPv3 has specific built-in mechanisms for preventing replay attacks including unique protocol engine IDs, timers and counters per engine and time windows for the validity of messages.
SNMP：SNMPv3のユーザベースセキュリティモデルは、独自のプロトコルエンジンIDは、タイマーとメッセージの有効性のためのエンジンと時間窓あたりのカウンターなど、リプレイ攻撃を防ぐための具体的な組み込みのメカニズムがあります。
RSIP: Refer to 2.3.1
RSIP：2.3.1を参照してください。
Megaco: Megaco commands and responses include matching transaction identifiers. The recipient receiving the same transaction id multiple times would discard the message, thus providing some protection against replay attacks. If even stronger protection against replay attack is needed, Megaco provides for the use of IPSec or TLS.
MEGACO：MEGACOコマンドと応答が一致するトランザクション識別子が含まれます。同じトランザクションIDを複数回受けた受信者は、このように、リプレイ攻撃に対する何らかの保護を提供し、メッセージを破棄します。リプレイ攻撃に対しても、強力な保護が必要な場合は、Megacoのは、IPSecまたはTLSの使用を提供します。
Diameter: Diameter requires that implementations support the replay protection mechanisms of IPSEC.
直径：直径は実装がIPSECのリプレイ保護メカニズムをサポートすることが必要です。
COPS: Refer to 2.3.1
COPS：2.3.1を参照してください。
The overall statistics with regards to the number of Fully Compliant, Partially Compliant (P+ and P) and Failing Compliancy requirements for each of the protocols is summarized in table 1.
完全準拠、一部準拠（P +およびP）およびプロトコルのそれぞれについて失敗の準拠要件の数に関して全体的な統計は、表1に要約されています。
T P+ P F
-----------------------------------------------------------------
SNMP 22 5 0 0
RSIP 17 7 3 0
Megaco 19 5 3 0
Diameter 21 5 1 0
COPS 20 5 2 0
Table 1: Totals across all Requirements
表1：すべての要件間の合計
In considering the P+ category of compliancy, an important aspect is the mechanism for support of extensibility. The extension mechanism provided by SNMP and COPS-PR using MIBs and PIBs respectively, provides extensions with no impact to the protocol. Diameter extensions require protocol changes, thus has a higher impact, although the extensions can be handled by other Diameter entities without being understood. Megaco's extension mechanisms of packages also requires protocol changes that must be understand by both sending and receiving entities, also being considered higher impact. The RSIP extension mechanism has the largest impact on the existing protocol and is based upon defining the necessary new parameters.
準拠のP +カテゴリを考える上で、重要な側面は、拡張性をサポートするための仕組みです。 SNMP及びMIBを使用してCOPS-PRそれぞれのPIBによって提供される拡張メカニズムは、プロトコルに影響を与えずに拡張機能を提供します。拡張が理解されることなく、他の直径エンティティによって処理することができるものの、直径の拡張は、より高い耐衝撃性を有し、プロトコルの変更を必要とします。パッケージのMEGACOの拡張メカニズムはまた、両方の送信側と受信側のエンティティ、また検討されているより高い衝撃によって理解されなければならないプロトコルの変更を必要とします。 RSIP拡張機構は、既存のプロトコルに最大の影響を有し、必要に応じて新しいパラメータの定義に基づいています。
The SNMP management framework meets all the specified MIDCOM protocol requirements with the appropriate design of a MIDCOM MIB module. SNMP is a proven technology with stable and proven development tools, already has extensions defined to support NAT configuration and policy-based management. SNMPv3 is a full standard, is more mature and has undergone more validation than the other protocols in the evaluation, and has been deployed to manage large-scale real-world networks (e.g., DOCSIS cable modem networks). The applicability of SNMP to the MIDCOM framework has a restriction in that it assumes the MIDCOM PDP is part of the Middlebox.
SNMP管理フレームワークはMIDCOM MIBモジュールの適切な設計により指定されたすべてのMIDCOMプロトコル要件を満たしています。 SNMPは、すでにNAT設定とポリシーベースの管理をサポートするために定義された拡張機能があり、安定的かつ実績のある開発ツールと実績のある技術です。 SNMPv3は、完全な標準がより成熟していると評価における他のプロトコルよりも多くの検証を受けている、大規模な実世界のネットワーク（例えば、DOCSISケーブルモデムネットワーク）を管理するために配備されています。 MIDCOMフレームワークにSNMPの適用性は、それがMIDCOM PDPがミドルの一部であると仮定という制限を有します。
RSIP fully meets many of the MIDCOM requirements. However, it does require additions and extensions to meet several of the requirements. RSIP would also require several framework elements to be added to the MIDCOM framework as identified in section 1.2.3. In addition, the tunneling required for RSIP as described in section 1.2.4, results in RSIP not being acceptable by the WG as the MIDCOM protocol.
RSIPは完全にMIDCOM要件の多くを満たしています。しかし、それは必要条件のいくつかを満たすための追加や拡張が必要です。 RSIPはまた、セクション1.2.3で識別されるMIDCOMフレームワークに追加するいくつかのフレームワークエレメントを必要とするであろう。加えて、セクション1.2.4で説明したように、トンネリングはRSIPのために必要な、RSIPの結果はMIDCOMプロトコルとしてWGによって許容されることはありません。
Megaco fully meets most of the key requirements for the MIDCOM Protocol. Additional extensions in the form of a new Termination / Package definition would be required for MIDCOM to meet several of the requirements. In order to meet the remaining requirements, modeling the underlying Middlebox resources (e.g., filters, policy rules) as separate elements from the Megaco entities might allow the usage of the protocol as-is, satisfying some of the resource access control requirements.
MEGACOは完全にMIDCOMプロトコルのための重要な要件のほとんどを満たしています。新しい終了/パッケージ定義の形で追加の拡張が要件のいくつかを満たすためにMIDCOMのために必要とされるであろう。残りの要件を満たすために、リソースのアクセス制御要件の一部を満たし、そのままプロトコルの使用を可能にするかもしれないMegacoのエンティティから別の要素として、基礎となるミドル・リソース（例えば、フィルタ、ポリシールール）をモデル化します。
The Diameter evaluation indicated a good overall fit. Some partially met requirements were identified that could be addressed by a new application extension. However, the Diameter architecture may be too heavy for the MIDCOM application and clearly much of the Diameter base is not needed. In addition, Diameter is the only protocol, at the time of this evaluation, for which the RFCs had not yet been published. Other than these reservations, the protocol is a good fit to MIDCOM requirements.
直径の評価は全体的に良好なフィット感を示しました。いくつかの部分的に満たさの要件は、新しいアプリケーションの拡張子によって対処することができることを同定しました。しかし、直径アーキテクチャはMIDCOMアプリケーションの重すぎるかもしれ、直径ベースの明確くらいは必要ありません。また、直径がRFCはまだ公開されていないいるため、この評価の時点で、唯一のプロトコルです。これらの予約以外に、プロトコルはMIDCOM要件にぴったりです。
The COPS evaluation indicates that the protocol meets the majority of the MIDCOM protocol requirements by using the protocol's native extension techniques, with COPS-PR being explicitly required to meet requirements 2.1.3 and 2.2.3. In order to fully satisfy one partially met requirement, 2.1.1, the COPS model would need to allow a PDP to establish communication with a PEP. While not explicitly prohibited by the COPS model, this would require additions, in the form of local policy, to ensure the proper establishment of an authorized association.
COPS評価は、プロトコルがCOPS-PRが明示的要件2.1.3と2.2.3を満たすために要求されると、プロトコルのネイティブ拡張技術を使用してMIDCOMプロトコル要件の大部分を満たしていることを示しています。完全に1つの部分的に満たさ要件、2.1.1を満たすためには、COPSモデルは、PDPは、PEPとの通信を確立できるようにする必要があります。明示的にCOPSモデルによって禁止されていないが、これは認可協会の適切な設置を確実にするために、ローカルポリシーの形で、添加物を必要とします。
Security considerations for the MIDCOM protocol are covered by the comparison against the specific Security requirements in the MIDCOM requirements document [1] and are specifically addressed by section 2.1.8 and section 2.3.
MIDCOMプロトコルのセキュリティ上の考慮事項[1] MIDCOM要件文書内の特定のセキュリティ要件との比較によって覆われており、具体的にはセクション2.1.8及びセクション2.3によって対処されます。
[1] Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore, "Middlebox Communications (MIDCOM) Protocol Requirements", RFC 3304, August 2002.
[1] Swale、R.、マート、P.、Sijben、P.、つば、S.、およびM.ショア、 "ミドル・コミュニケーションズ（MIDCOM）プロトコル要件"、RFC 3304、2002年8月。
[2] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox Communications Architecture and Framework", RFC 3303, August 2002.
[2] Srisuresh、P.、Kuthan、J.、ローゼンバーグ、J.、モリター、A.、およびA. Rayhan、 "ミドル通信アーキテクチャおよびフレームワーク"、RFC 3303、2002年8月。
[3] Rose, M. and K. McCloghrie, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[3]ローズ、M.、およびK. McCloghrie、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II"、STD 17、RFC 1213、1991年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[5] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", STD 62, RFC 3411, December 2002.
[5]ハリントン、D.、Presuhn、R.、およびB. Wijnenのを、 "SNMP管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[6] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[6] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[7] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[7] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[8] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[8] McCloghrie、K.、パーキンス、D.、およびJ. Schoenwaelder、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[9] Presuhn, R. (Ed.), "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[9] Presuhn、R.（編）、 "簡易ネットワーク管理プロトコル（SNMP）のためのマッピングを輸送します"、STD 62、RFC 3417、2002年12月。
[10] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[10]ケース、J.、ハリントンD.、Presuhn R.、およびB. Wijnenの、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、STD 62、RFC 3412、2002年12月。
[11] Blumenthal, U. and B. Wijnen, "User-based Security Model(USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[11]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、STD 62、RFC 3414、2002年12月。
[12] Presuhn, R. (Ed.), "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[12] Presuhn、R.（エド。）、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
[13] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", STD 62, RFC 3413, December 2002.
[13]レビ、D.、マイヤー、P.、およびB.スチュワート、 "SNMPv3のアプリケーション"、STD 62、RFC 3413、2002年12月。
[14] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[14] Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "ビューベースアクセス制御モデル（VACM）簡易ネットワーク管理プロトコル（SNMP）のために"、STD 62、RFC 3415、2002年12月。
[15] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-Standard Network Management Framework", RFC 3410, December 2002.
[15]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準ネットワーク管理フレームワークのバージョン3への序論"、RFC 3410、2002年12月。
[16] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[16]のRohit、R.、Srisuresh、P.、Raghunarayan、R.、パイ、N.、およびC.王は、RFC 4008、2005年3月の "ネットワークのための管理オブジェクトの定義は、翻訳者（NAT）アドレス"。
[17] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[17]ボレッラ、M.、ロー、J.、Grabelsky、D.、およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[18] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, "Realm Specific IP: Protocol Specification", RFC 3103, October 2001.
[18]ボレッラ、M.、Grabelsky、D.、ロー、J.、およびK.谷口、 "レルム特定IP：プロトコル仕様"、RFC 3103、2001年10月。
[19] Montenegro, G. and M. Borella, "RSIP Support for End-to-end Ipsec", RFC 3104, October 2001.
[19]モンテネグロ、G.およびM.ボレッラ、 "エンドツーエンドIPsecのRSIPサポート"、RFC 3104、2001年10月。
[20] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, October 2001.
[20]クエルボ、F.、グリーン、N.、Rayhan、A.、のHuitema、C.、ローゼン、B.、およびJ. Segers、 "Megacoのプロトコルバージョン1.0"、RFC 3015、2001年10月。
[21] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[21]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[23] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload", RFC 2406, November 1998.
[23]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード"、RFC 2406、1998年11月。
[24] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[24]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[25] Durham, D. (Ed.), Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[25]ダラム、D.（編）、ボイル、J.、コーエン、R.、ヘルツォーク、S.、ラジャン、R.、およびA. Sastry、 "COPS（共通オープンポリシーサービス）プロトコル"、RFC 2748年、2000年1月。
[26] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning", RFC 3084, March 2001.
[26]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス、「COPSポリシーのプロビジョニングのための使用法」、RFC 3084、2001年3月。
[27] Raz, D., Schoenwalder, J., and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.
、RFC 2962、2000年10月 "ペイロード・アドレス変換のためのSNMPアプリケーションレベルゲートウェイ" [27]ラズ、D.、Schoenwalder、J.、およびB. Sugla、。
[28] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[28] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
The editor would like to acknowledge the constructive feedback provided by Joel M. Halpern on the individual protocol evaluation contributions. In addition, a thanks to Elwyn Davies, Christopher Martin, Bob Penfield, Scott Brim and Martin Stiemerling for contributing to the mailing list discussion on the document content.
エディタは、個々のプロトコルの評価の貢献にジョエルM.ハルパーンが提供する建設的なフィードバックを承認したいと思います。また、文書の内容にメーリングリストの議論に貢献するためのエルウィン・デイヴィス、クリストファー・マーティン、ボブペンフィールド、スコット・ブリムとMartin Stiemerlingのおかげ。
Appendix A - SNMP Overview
付録A - SNMPの概要
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5つの主要コンポーネントから構成されています。
o An overall architecture, described in RFC 3411 [5]. A more detailed introduction and applicability statements for the SNMP Management Framework can be found in RFC 3410 [15].
RFC 3411に記載され、全体的なアーキテクチャ、O [5]。 SNMP管理フレームワークのための、より詳細な紹介と適用性の文は、RFC 3410 [15]に記載されています。
o Mechanisms for describing and naming objects and events for the purpose of management. The current version of this Structure of Management Information (SMI) is called SMIv2 and described in RFC 2578 [6], RFC 2579 [7] and RFC 2580 [8].
管理の目的のためにオブジェクトとイベントを記述し、命名するためのメカニズムO。現在の管理情報（SMI）のこのような構造のバージョンのSMIv2と呼ばれ、RFC 2578に記載されている[6]、RFC 2579 [7]及びRFC 2580 [8]。
o Message protocols for transferring management information. The current version of the message protocol is called SNMPv3 and described in RFC 3412 [10], RFC 3414 [11] and RFC 3417 [9].
管理情報を転送するためのOメッセージプロトコル。メッセージプロトコルの現在のバージョンは、SNMPv3のと呼ばれ、RFC 3412 [10]に記載されているRFC 3414 [11]およびRFC 3417 [9]。
o Protocol operations for accessing management information. The current version of the protocol operations and associated PDU formats is described in RFC 3416 [12].
管理情報にアクセスするためのOプロトコル操作。プロトコル操作と関連PDUフォーマットの現在のバージョンは、RFC 3416 [12]に記載されています。
o A set of fundamental applications described in RFC 3413 [13] and the view-based access control mechanism described in RFC 3415 [14].
O RFC 3413 [13]とビューベースアクセス制御メカニズムに記載の基本的なアプリケーションのセットは、RFC 3415 [14]に記載します。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されています。
A.1 SNMPv3 Proxy Forwarding
A.1 SNMPv3のプロキシ転送
SNMPv3 proxy forwarding (RFC 3413 [13]) provides a standardized mechanism to configure an intermediate node to forward SNMP messages. A command generating entity sends requests to a proxy forwarding entity that forwards the request to a third entity.
SNMPv3のプロキシ転送（RFC 3413 [13]）SNMPメッセージを転送する中間ノードを構成するための標準化されたメカニズムを提供します。コマンド生成エンティティは、第3のエンティティに要求を転送するプロキシ転送エンティティに要求を送信します。
One SNMP entity may serve both functions as the SNMP agent to monitor and configure the node on which it is resident, and as an intermediate node in a proxy relationship to permit monitoring and configuration of additional entities.
一つのSNMPエンティティは、それが常駐するノードを監視し、設定するSNMPエージェントとしての両方の機能を果たすことができる、およびプロキシ関係に中間ノードとして追加エンティティの監視および設定を許可します。
Each entity is identified by a unique engineID value, specifically to support proxy between addressing domains and/or trust domains. An SNMPv3 message contains two engineIDs- one to identify the database to be used for message security, and one to identify the source (or target) of the contained data. Message security is applied between the originator and the proxy, and then between the proxy and the end-target. The PDU contains the engineID of the node whose data is contained in the message, which passes end-to-end, unchanged by the proxy.
各エンティティは、具体的にアドレッシングドメインおよび/または信頼ドメイン間のプロキシをサポートするために、一意のエンジンID値によって識別されます。 SNMPv3のメッセージは、メッセージセキュリティのために使用するデータベースを識別するために、もう1つはソース（またはターゲット）を識別するために含まれているデータの2つのengineIDs-一方を含みます。メッセージセキュリティは、発信者とプロキシとの間に印加し、その後プロキシとエンドターゲットの間です。 PDUは、データのエンドツーエンド、プロキシによって不変を通過メッセージに含まれるノードのエンジンIDを含んでいます。
SNMPv3 proxy was designed to provide a standard SNMP approach to inserting an intermediate node in the middle of communications for a variety of scenarios. SNMPv3 proxy can support crossing addressing domains, such as IPv4 and IPv6, crossing SNMP version domains, such as SNMPv3 and SNMPv1, crossing security mechanism domains, such as DES and AES, and for providing a single point of management contact for a subset of the network, such as managing a private network through a NAT device or a VPN endpoint.
SNMPv3のプロキシは、さまざまなシナリオのための通信の途中で中間ノードを挿入するために、標準SNMPアプローチを提供するように設計しました。 SNMPv3のプロキシは、そのようなIPv4およびIPv6などのアドレッシングドメインを横切るようSNMPv3のとSNMPv1のようなSNMPバージョンドメインを、交差、例えばDESやAESなどのセキュリティメカニズムドメインを、交差、およびサブセットの管理単一の接点を提供するためにサポートすることができますネットワーク、NATデバイスまたはVPNエンドポイントを通じてプライベートネットワークの管理など。
A.2 Proxies Versus Application Level Gateways
アプリケーションレベルゲートウェイ対A.2のプロキシ
Proxies are generally preferred to Application Level Gateways for SNMP. ALGs typically modify the headers and content of messages. SNMP is a protocol designed for troubleshooting network (mis-) configurations. Because an operator needs to understand the actual configuration, the translation of addresses within SNMP data causes confusion, hiding the actual configuration of a managed device from the operator. ALGs also introduce security vulnerabilities, and other complexities related to modifying SNMP data.
プロキシは、一般的にSNMPのためのアプリケーションレベルゲートウェイに好まれます。 ALGは、一般的に、ヘッダーとメッセージの内容を変更します。 SNMPは、トラブルシューティング・ネットワーク（誤）構成のために設計されたプロトコルです。オペレータは実際の構成を理解する必要があるため、SNMPデータ内のアドレスの変換は、オペレータからの管理対象デバイスの実際の構成を隠し、混乱の原因となります。 ALGも、SNMPデータを変更するに関連するセキュリティ上の脆弱性、およびその他の複雑さを紹介します。
SNMP Proxies can modify message headers without modifying the contained data. This avoids the issues associated with translating the payload data, while permitting application level translation of addresses.
SNMPプロキシは、含まれるデータを変更することなく、メッセージヘッダを変更することができます。これは、アドレスのアプリケーションレベルの変換を可能にしながら、ペイロードデータを変換に関連する問題を回避します。
The issues of ALGs versus proxies for SNMP Payload Address Translation are discussed at length in RFC 2962 [27].
SNMPペイロードアドレス変換のためのプロキシ対のALGの問題は、RFC 2962 [27]の長さで議論されています。
Appendix B - RSIP with Tunneling
付録B - トンネリングとRSIP
NAT requires ALGs (Application Layer Gateways) in middleboxes without MIDCOM, and application modifications or agents for middleboxes with MIDCOM.
NATはMIDCOMなし中間装置でのALG（アプリケーション層ゲートウェイ）を必要とし、MIDCOMと中間装置のためのアプリケーションの変更または薬剤。
Support for NAT without tunneling could easily be added to the RSIP control protocol. NAT would be defined as a new, null tunnel type. Support for the NAT null tunnels could be implemented in hosts, or in applications or application agents.
トンネリングなしのNATのサポートが簡単にRSIP制御プロトコルに追加することができます。 NATは新しい、ヌルトンネル型として定義されます。 NATヌルトンネルのサポートは、宿主中で、またはアプリケーションまたはアプリケーションエージェントで実施することができます。
If support for NAT null tunnels were implemented in hosts, no modifications to applications would be required, and no application agents or ALGs would be required. This has obvious advantages. In addition to the NAT null tunnel, the host would have to implement an RSIP / MIDCOM client (or a STUN client) and the middlebox would have to implement an RSIP / MIDCOM server, or a STUN server would have to be available _beyond_ the middlebox. Note that the STUN client / server approach may not work with all types of middleboxes.
NATヌルトンネルのサポートがホストに実装された場合、アプリケーションへの修正は必要ないであろう、とNOアプリケーションエージェントまたはのALGは不要であろう。これは明白な利点があります。 NATヌルトンネルに加えて、ホストはRSIP / MIDCOMクライアント（またはSTUNクライアント）を実装しなければならないとミドルはRSIP / MIDCOMサーバを実装しなければならない、またはSTUNサーバが_beyond_ミドル利用可能でなければなりません。 STUNクライアント/サーバアプローチは、ミドルボックスのすべてのタイプでは動作しない場合があることに注意してください。
If support for NAT null tunnels were NOT implemented in hosts, then applications would have to be modified, or application agents or ALGs would have to be implemented. This has the advantage over tunnels (whether null or not) of not requiring modification to hosts, but would require the modification of host applications or the implementation of application agents, both of which would include an RSIP / MIDCOM client, and the implementation of an RSIP/MIDCOM server in the middlebox. Again, in some situations, STUN could be used instead of RSIP / MIDCOM.
NATヌルトンネルのサポートがホストに実装されていなかった場合、アプリケーションは修正しなければならないであろう、またはアプリケーション・エージェントまたはのALGを実装しなければならないであろう。これは、ホストに変更を必要としないトンネル（nullであるか否か）を超える利点を有するが、ホスト・アプリケーションまたはアプリケーションエージェントの実装の変更を必要とするであろう、RSIP / MIDCOMクライアントを含むであろうどちらも、および実装ミドルでRSIP / MIDCOMサーバ。ここでも、いくつかの状況では、STUNは、代わりにRSIP / MIDCOMの使用することができます。
Tunneled or not, an RSIP / MIDCOM server is needed in the middlebox. Tunneled, the host needs to be modified, but not the application. Untunneled, an agent must be added or the application must be modified, but there would be no host modifications. The advantages/disadvantages of tunneling would need to be evaluated in considering RSIP.
トンネリングされたかどうか、RSIP / MIDCOMサーバはミドルで必要とされます。トンネリングされ、ホストは、アプリケーションを変更する必要があるが、ありません。 Untunneled、剤を添加しなければならないか、またはアプリケーションを変更する必要があり、ないホスト変更はないだろう。トンネリングの長所/短所はRSIPを考慮して評価する必要があろう。
Appendix C - Megaco Modeling Approach
付録C - Megacoのモデル化アプローチ
To model the Middlebox functions such as firewall, NAT etc., a new Middlebox Termination type needs to be defined within Megaco. If policy-rule overlap or modification by multiple Agents is NOT required, then a policy rule is equivalent to a Termination (see Figure 1). The various components of a Policy rule such as filter, action, life-time, creator etc. are described as various properties of a Termination. Use of the Virtual Media Gateway (VMG) concept allows for conflict-free interaction of multiple MA's with the same MB.
など、ファイアウォール、NATなどのミドル機能をモデル化するために、新しいミドル終端タイプは、Megacoの内で定義する必要があります。複数のエージェントによってポリシールール重複または改変が必要とされない場合、ポリシールールが終了と等価である（図1参照）。等フィルタ、アクション、寿命、クリエーターとしてのポリシールールの様々な構成要素は、終端の様々な特性として記載されています。仮想メディアゲートウェイ（VMG）の概念を使用すると、複数のMAさんと同じMBとの競合のない対話が可能になります。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | |
+-------------|---------|----------|-----------+
| +---------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
----------| |Tx|-------+ +---|Ty|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| ....| | | +-------------+ |
| +---------+ | |
| +---------------------------------
| Middlebox | IF4
+----------------------------------------------+
Tx: Termination x = Policy rule x
Ty: Termination y = Policy rule y
Tz: Termination z = Policy rule z
MA: MIDCOM Agent
IF: Interface
Figure 1.
図1。
If it is required to allow multiple agents manipulate the same Middlebox resource (e.g., a Policy rule or a filter), the latter needs to be kept separate from the Termination (the Policy rule is manipulated by the MA by manipulating the properties of the associated Termination). For example, if overlapping policy rule manipulation is required, then a Termination shall be associated with a single policy rule, but a policy rule may be associated with more than one Termination. Thus, a Termination can share a policy rule with another Termination, or have a policy rule partially overlapping with that of another Termination. This model allows two MAs, controlling two distinct Terminations (see Figure 2), manipulate the same or overlapping policy rules. In Figure 2, policy rules 1 and 2 are overlapping and they are shared by MA-1 and MA-2.
複数のエージェントが同じミドルリソース（例えば、ポリシールールまたはフィルタ）を操作可能にするために必要とされる場合、後者のニーズは（ポリシールールが関連のプロパティを操作することによってMAによって操作される終了から別々に維持されます終了）。重複するポリシールールの操作が必要な場合、例えば、その終端は、単一のポリシールールに関連付けられなければならないが、ポリシールールは、複数の終端に関連付けることができます。したがって、終了は別の終了とポリシールールを共有する、または別の終了のものと部分的に重複するポリシールールを持つことができます。このモデルは、2つの別個の終端（図2参照）、同じまたは重複するポリシールールを操作を制御する二つのMAを可能にします。図2では、ポリシールール1及び2が重複しており、それらは、MA-1及びMA-2によって共有されます。
+-------+ +-------+
| MA-1 | | MA-2 |
| | | |
+-------+ |IF2 +-------+
| | | MB
+-------------|---------|----------|-----------+
| +-----------+ | +-------------+ |
IF1 |VMG1 | +--+ | | | +--+ +--+ |VMG2 |IF3
------------------|Ty|----+ +---|Tx|--|Tz|----------------
| | +--+ | | | +--+ +--+ | |
| .... | | | | +--/------\---+ |
| +-------|---+ | / \ |
| | +----/----------\------------------
| +------+----+------+ +------+ |IF4
| |Policy1 Policy2 | |Policy| |
| | | | | | 3 | |
| +----+------+------+ +------+ |
+----------------------------------------------+
Tx: Termination x
Ty: Termination y
Tz: Termination z
MA: MIDCOM Agent
IF: Interface
MB: Middlebox
Figure 2.
図2。
This requires that the Agent and the Middlebox adhere to the following principles:
これは、エージェントとミドルは以下の原則に従っている必要があります。
(1) Only one Termination has read/write access to a filter at any time.
（1）つだけ終了は、任意の時点でフィルタに読み取り/書き込みアクセスをしています。
(2) When the policy rule is being modified by a new agent (i.e., not the one that created the policy) the Middlebox makes a policy decision and decides whether to accept the requested modification or not. In the case the modification is accepted the initial MIDCOM agent may be notified.
（2）ポリシールールが新しいエージェント（すなわち、しないポリシーを作成したもの）によって修飾されているときミドルはポリシー決定を行い、要求された変更かどうかを受け入れるかどうかを決定します。場合には変更は、最初のMIDCOMエージェントに通知することができる受け入れられています。
Appendix D - Diameter IPFilter Rule
付録D - 直径のIPFilterルール
The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it:
IPFilterRuleのフォーマットはOctetStringにAVPベースフォーマットに由来します。これは、UTF-8エンコーディングを使用し、UTF8Stringを同じ要件があります。パケットは、それに関連付けられている以下の情報に基づいてフィルタリングすることができます。
Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types
方向（またはアウト）ソースおよび宛先IPアドレス（おそらくマスクされた）プロトコル送信元と宛先ポート（リストまたは範囲）TCPフラグIPフラグメントフラグIPオプションICMPタイプ
Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny.
適切な方向の規則は評価を終了最初に一致した規則と、順に評価されます。各パケットは一度だけ評価されます。ルールが一致しない場合は、最後に評価ルールが許可した、と最後のルールが拒否した場合は渡された場合、パケットはドロップされます。
IPFilterRule filters MUST follow the format:
IPFilterRuleのフィルタは、形式に従う必要があります。
action dir proto from src to dst [options]
srcからdstへのアクションのdirプロト[オプション]
action permit - Allow packets that match the rule. deny - Drop packets that match the rule.
アクション許可 - ルールに一致するパケットを許可します。拒否 - ルールに一致するパケットをドロップします。
dir "in" is from the terminal, "out" is to the terminal.
「の」dirが端末にある「OUT」、端末からです。
proto An IP protocol specified by number. The "ip" keyword means any protocol will match.
プロト番号で指定されたIPプロトコル。 「IP」のキーワードは、すべてのプロトコルが一致することを意味します。
src and dst <address/mask> [ports]
SRCとDST <アドレス/マスク> [ポート]
The <address/mask> may be specified as:
<アドレス/マスク>のように指定することができます。
ipno An IPv4 or IPv6 number in dotted-quad or canonical IPv6 form. Only this exact IP number will match the rule.
点線クワッドまたは正規のIPv6形式でIPv4またはIPv6番号ipno。これだけ正確なIP番号がルールに一致します。
ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask.
ipno /フォーム1.2.3.4/24のマスク幅が上記のようにIP番号をビット。この場合は、1.2.3.0から1.2.3.255へのすべてのIP番号が一致します。ビット幅は、IPバージョンに対して有効でなければなりませんし、IP番号がマスクを超えて設定されたビットを持ってはいけません。
For a match to occur, the same IP
version must be present in the
packet that was used in describing
the IP address. To test for a
particular IP version, the bits part
can be set to zero. The keyword
"any" is 0.0.0.0/0 or the IPv6
equivalent. The keyword "assigned"
is the address or set of addresses
assigned to the terminal. For IPv4,
a typical first rule is often
"deny in ip! assigned"
The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers.
マッチの意味は、モディファイないとアドレスの前で反転することができます（！）、他のすべてのアドレスが代わりにマッチさせます。これは、ポート番号の選択に影響を与えません。
With the TCP, UDP and SCTP protocols, optional ports may be specified as:
TCP、UDP、およびSCTPプロトコルを使用すると、オプションのポートはとして指定することができます。
{port|port-port}[,ports[,...]]
{ポート|ポートポート} [、ポート[、...]]
The '-' notation specifies a range of ports (including boundaries).
「 - 」の表記は、（境界を含む）ポートの範囲を指定します。
Fragmented packets that have a non-zero offset (i.e., not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets.
非ゼロオフセット（すなわち、ない最初のフラグメント）を有する断片化されたパケットは、一つ以上のポートの仕様を持つルールに一致することはありません。断片化されたパケットを照合についての詳細はfragオプションを参照してください。
options:
オプション：
frag Match if the packet is a fragment and this is not the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications.
FRAGマッチはパケットがフラグメントである場合、これはデータグラムの最初のフラグメントではありません。 FRAGはtcpflagsやTCP / UDPポート仕様のいずれかと組み合わせて使用することはできません。
ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are:
IPヘッダーが仕様で指定されたオプションのカンマ区切りのリストが含まれている場合ipoptionsはマッチをスペック。サポートされるIPオプションは次のとおりです。
ssrr (strict source route), lsrr (loose source
route), rr (record packet route) and ts
(timestamp). The absence of a particular option
may be denoted with a '!'.
tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are:
TCPヘッダーが仕様で指定されたオプションのカンマ区切りのリストが含まれている場合tcpoptionsはマッチをスペック。サポートされるTCPオプションは次のとおりです。
mss (maximum segment size), window (tcp window
advertisement), sack (selective ack), ts (rfc1323
timestamp) and cc (rfc1644 t/tcp connection
count). The absence of a particular option may
be denoted with a '!'.
established TCP packets only. Match packets that have the RST or ACK bits set.
確立されたTCPパケットのみ。設定RSTまたはACKビットを有するマッチパケット。
setup TCP packets only. Match packets that have the SYN bit set but no ACK bit.
セットアップTCPパケットのみ。 SYNビットがセットされますがありませんACKビットを持っているマッチパケット。
tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are:
スペックTCPパケットのみをtcpflags。 TCPヘッダがspecで指定するフラグのカンマ区切りのリストが含まれている場合に一致します。サポートされるTCPフラグは次のとおりです。
fin, syn, rst, psh, ack and urg. The absence of a
particular flag may be denoted with a '!'. A rule
that contains a tcpflags specification can never
match a fragmented packet that has a non-zero
offset. See the frag option for details on
matching fragmented packets.
icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are:
唯一のタイプのICMPパケットicmptypes。 ICMPタイプがリスト型である場合に一致します。リストには、範囲またはコンマで区切られた個々のタイプの任意の組み合わせとして指定することができます。両方の数値と下記の記号値を使用することができます。サポートされるICMPタイプは次のとおりです。
echo reply (0), destination unreachable (3),
source quench (4), redirect (5), echo request
(8), router advertisement (9), router
solicitation (10), time-to-live exceeded (11), IP
header bad (12), timestamp request (13),
timestamp reply (14), information request (15),
information reply (16), address mask request (17)
and address mask reply (18).
There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls.
アクセスデバイスは常に捨てなければなりませんパケットの一種であり、それは1のフラグメントオフセットを持つIPフラグメントです。これは有効なパケットですが、それだけでファイアウォールを回避しようとする一つの使用を持っています。
An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure.
拒否ルールを解釈または適用することができませんアクセスデバイスはセッションを終えなければなりません。許可ルールを解釈または適用することができませんアクセスデバイスは、より限定的なルールを適用することができます。アクセスデバイスは、アクセスデバイスの所有者のインフラを保護するために、例えば、供給ルールの前に、独自のルールを否定適用される場合があります。
The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations.
ルール構文は、FreeBSDからIPFW（8）の修飾されたサブセットであり、そしてipfw.cコードを実装するのに有用な基盤を提供することができます。
Contributors
協力者
The following identifies the key contributors who provided the primary content for this document in the form of individual documents for each protocol:
以下は、各プロトコルのための個々の文書の形で、この文書の主な内容を提供する主要な貢献者を識別します。
RSIP:
RSIP：
Jim Renkel
ジムRenk
SNMP:
SNMP：
Juergen Quittek NEC Europe Ltd. EMail: quittek@ccrle.nec.de
ユルゲンQuittek NECヨーロッパ社メールアドレス：quittek@ccrle.nec.de
David Harrington Co-chair SNMPv3 WG EMail: dbh@enterasys.com
デヴィッド・ハリントン共同議長のSNMPv3 WG Eメール：dbh@enterasys.com
Megaco:
MEGACO：
Sanjoy Sen
サンジョイセン
Cedric Aoun Nortel EMail: cedric.aoun@nortel.com
セドリックアウンノーテルEメール：cedric.aoun@nortel.com
Tom Taylor Nortel EMail: taylor@nortel.com
トムテイラーノーテルEメール：taylor@nortel.com
Diameter:
直径：
Tom Taylor Nortel EMail: taylor@nortel.com
トムテイラーノーテルEメール：taylor@nortel.com
COPS:
COPS：
Cedric Aoun Nortel EMail: cedric.aoun@nortel.com
セドリックアウンノーテルEメール：cedric.aoun@nortel.com
Kwok-Ho Chan Nortel EMail: khchan@nortel.com
クォック・ホーちゃんノーテルEメール：khchan@nortel.com
Louis-Nicolas Hamer
ルイ・ニコラ・ハマー
Reinaldo Penno EMail: rpenno@juniper.net
レイナルドPenno Eメール：rpenno@juniper.net
Sanjoy Sen
サンジョイセン
Author's Address
著者のアドレス
Mary Barnes Nortel 2201 Lakeside Blvd. Richardson, TX USA
メアリー・バーンズノーテル2201レイクサイドブルバードリチャードソン、TX USA
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
電話：1-972-684-5432 Eメール：mary.barnes@nortel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet gement
RFC Editor機能のための基金は現在、インターネットgementによって提供され