[要約] RFC 6632は、IETFネットワーク管理の標準についての概要を提供しています。このRFCの目的は、ネットワーク管理の基本原則と標準化されたプロトコルについての理解を促進することです。
Internet Engineering Task Force (IETF) M. Ersue, Ed.
Request for Comments: 6632 Nokia Siemens Networks
Category: Informational B. Claise
ISSN: 2070-1721 Cisco Systems, Inc.
June 2012
An Overview of the IETF Network Management Standards
IETFネットワーク管理標準の概要
Abstract
概要
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models.
このドキュメントは、IETFネットワーク管理標準の概要を示し、IETF標準追跡ネットワーク管理プロトコルとデータモデルの既存および進行中の開発を要約しています。このドキュメントは、存在する他の概要ドキュメントを参照し、方向付けを容易にするための標準を分類しています。このドキュメントの目的は、一方では、システム開発者とユーザーが適切な標準管理プロトコルとデータモデルを選択して、関連する管理ニーズに対処できるようにすることです。一方、このドキュメントは、IETF管理テクノロジとデータモデルの使用を計画している他の標準開発組織または団体による概要とガイドラインとして使用できます。このドキュメントでは、トンネルのOAM、MPLSトランスポートプロファイル（MPLS-TP）OAM、疑似配線、および対応する管理モデルなど、データパス上の運用、管理、保守（OAM）テクノロジーについては説明していません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6632.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6632で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope and Target Audience ..................................4
1.2. Related Work ...............................................5
1.3. Terminology ................................................6
2. Core Network Management Protocols ...............................8
2.1. Simple Network Management Protocol (SNMP) ..................8
2.1.1. Architectural Principles of SNMP ....................8
2.1.2. SNMP and Its Versions ...............................9
2.1.3. Structure of Managed Information (SMI) .............11
2.1.4. SNMP Security and Access Control Models ............12
2.1.4.1. Security Requirements on the SNMP
Management Framework ......................12
2.1.4.2. User-Based Security Model (USM) ...........12
2.1.4.3. View-Based Access Control Model (VACM) ....13
2.1.5. SNMP Transport Subsystem and Transport Models ......13
2.1.5.1. SNMP Transport Security Model .............14
2.2. Syslog Protocol ...........................................15
2.3. IP Flow Information eXport (IPFIX) and Packet
SAMPling (PSAMP) Protocols ................................16
2.4. Network Configuration .....................................19
2.4.1. Network Configuration Protocol (NETCONF) ...........19
2.4.2. YANG - NETCONF Data Modeling Language ..............21
3. Network Management Protocols and Mechanisms with
Specific Focus .................................................23
3.1. IP Address Management .....................................23
3.1.1. Dynamic Host Configuration Protocol (DHCP) .........23
3.1.2. Ad Hoc Network Autoconfiguration ...................24
3.2. IPv6 Network Operations ...................................25
3.3. Policy-Based Management ...................................26
3.3.1. IETF Policy Framework ..............................26
3.3.2. Use of Common Open Policy Service (COPS)
for Policy Provisioning (COPS-PR) ..................26
3.4. IP Performance Metrics (IPPM) .............................27
3.5. Remote Authentication Dial-In User Service (RADIUS) .......29
3.6. Diameter Base Protocol (Diameter) .........................31
3.7. Control and Provisioning of Wireless Access Points
(CAPWAP) ..................................................35
3.8. Access Node Control Protocol (ANCP) .......................36
3.9. Application Configuration Access Protocol (ACAP) ..........36
3.10. XML Configuration Access Protocol (XCAP) .................37
4. Network Management Data Models .................................38
4.1. IETF Network Management Data Models .......................39
4.1.1. Generic Infrastructure Data Models .................39
4.1.2. Link-Layer Data Models .............................40
4.1.3. Network-Layer Data Models ..........................40
4.1.4. Transport-Layer Data Models ........................40
4.1.5. Application-Layer Data Models ......................41
4.1.6. Network Management Infrastructure Data Models ......41
4.2. Network Management Data Models - FCAPS View ...............41
4.2.1. Fault Management ...................................42
4.2.2. Configuration Management ...........................44
4.2.3. Accounting Management ..............................45
4.2.4. Performance Management .............................46
4.2.5. Security Management ................................48
5. Security Considerations ........................................49
6. Contributors ...................................................51
7. Acknowledgements ...............................................52
8. Informative References .........................................52
Appendix A. High-Level Classification of Management Protocols
and Data Models .......................................77
A.1. Protocols Classified by Standards Maturity in the IETF .....77
A.2. Protocols Matched to Management Tasks ......................79
A.3. Push versus Pull Mechanism .................................80
A.4. Passive versus Active Monitoring ...........................80
A.5. Supported Data Model Types and Their Extensibility ........81
Appendix B. New Work Related to IETF Management Standards .........83
B.1. Energy Management (EMAN) ...................................83
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents where they exist and classifies the standards for easy orientation.
このドキュメントは、IETFネットワーク管理標準の概要を示し、IETF標準追跡ネットワーク管理プロトコルとデータモデルの既存および進行中の開発を要約しています。このドキュメントは、それらが存在する他の概要ドキュメントを参照し、方向付けを容易にするための標準を分類しています。
The target audience of the document is, on the one hand, IETF working groups, which aim to select appropriate standard management protocols and data models to address their needs concerning network management. On the other hand, the document can be used as an overview and guideline by non-IETF Standards Development Organizations (SDOs) planning to use IETF management technologies and data models for the realization of management applications. The document can also be used to initiate a discussion between the bodies with the goal to gather new requirements and to detect possible gaps. Finally, this document is directed to all interested parties that seek to get an overview of the current set of the IETF network management protocols such as network administrators or newcomers to the IETF.
このドキュメントの対象読者は、一方ではネットワーク管理に関するニーズに対応するために適切な標準管理プロトコルとデータモデルを選択することを目的としたIETFワーキンググループです。一方、このドキュメントは、管理アプリケーションの実現にIETF管理テクノロジとデータモデルを使用することを計画している非IETF標準開発機関（SDO）による概要とガイドラインとして使用できます。この文書は、新しい要件を収集し、ギャップの可能性を検出することを目的として、組織間の協議を開始するためにも使用できます。最後に、このドキュメントは、ネットワーク管理者やIETFの新規参入者など、IETFネットワーク管理プロトコルの現在のセットの概要を知りたいすべての関係者を対象としています。
Section 2 gives an overview of the IETF core network management standards with a special focus on Simple Network Management Protocol (SNMP), syslog, IP Flow Information eXport / Packet SAMPling (IPFIX/ PSAMP), and Network Configuration (NETCONF). Section 3 discusses IETF management protocols and mechanisms with a specific focus, e.g., IP address management or IP performance management. Section 4 discusses IETF data models, such as MIB modules, IPFIX Information Elements, Syslog Structured Data Elements, and YANG modules designed to address a specific set of management issues and provides two complementary overviews for the network management data models standardized within the IETF. Section 4.1 focuses on a broader view of models classified into categories such as generic and infrastructure data models as well as data models matched to different layers. Whereas Section 4.2 structures the data models following the management application view and maps them to the network management tasks fault, configuration, accounting, performance, and security management.
セクション2では、Simple Network Management Protocol（SNMP）、syslog、IP Flow Information eXport / Packet SAMPling（IPFIX / PSAMP）、およびNetwork Configuration（NETCONF）に特に重点を置いたIETFコアネットワーク管理標準の概要を示します。セクション3では、IPアドレス管理やIPパフォーマンス管理など、IETFの管理プロトコルとメカニズムについて具体的に説明します。セクション4では、MIBモジュール、IPFIX情報要素、Syslog構造化データ要素、YANGモジュールなどの特定の管理問題に対処するために設計されたIETFデータモデルについて説明し、IETF内で標準化されたネットワーク管理データモデルの2つの補足的な概要を示します。セクション4.1では、一般的なデータモデルやインフラストラクチャデータモデルなどのカテゴリに分類されたモデルと、さまざまなレイヤーに対応するデータモデルについて、より広い視野に焦点を当てています。セクション4.2は、管理アプリケーションビューに従ってデータモデルを構築し、ネットワーク管理タスクの障害、構成、アカウンティング、パフォーマンス、およびセキュリティ管理にマップします。
Appendix A guides the reader for the high-level selection of management standards. For this, the section classifies the protocols according to high-level criteria, such as push versus pull mechanisms, passive versus active monitoring, as well as categorizes the protocols concerning the network management task they address and their data model extensibility. If the reader is interested only in a subset of the IETF network management protocols and data models described in this document, Appendix A can be used as a dispatcher to the corresponding chapter. Appendix B gives an overview of the new work on Energy Management in the IETF.
付録Aは、管理基準の高レベルの選択について読者をガイドします。このために、このセクションでは、プッシュメカニズムとプルメカニズム、パッシブモニタリングとアクティブモニタリングなどの高レベルの基準に従ってプロトコルを分類し、それらが対処するネットワーク管理タスクとデータモデルの拡張性に関するプロトコルを分類します。このドキュメントで説明されているIETFネットワーク管理プロトコルとデータモデルのサブセットのみに関心がある場合は、対応する章のディスパッチャとして付録Aを使用できます。付録Bは、IETFのエネルギー管理に関する新しい作業の概要を示しています。
This document mainly refers to Proposed, Draft, or Internet Standard documents from the IETF (see [RFCSEARCH]). Whenever valuable, Best Current Practice (BCP) documents are referenced. In exceptional cases, and if the document provides substantial guideline for standard usage or fills an essential gap, Experimental and Informational RFCs are noticed and ongoing work is mentioned.
このドキュメントは主に、IETFからの提案、ドラフト、またはインターネット標準ドキュメントに言及しています（[RFCSEARCH]を参照）。貴重な場合はいつでも、Best Current Practice（BCP）ドキュメントが参照されます。例外的なケースで、ドキュメントが標準的な使用法に関する実質的なガイドラインを提供するか、または本質的なギャップを埋める場合、実験的および情報的RFCが通知され、進行中の作業が言及されます。
Information on active and concluded IETF working groups (e.g., their charters, published or currently active documents, and mail archives) can be found at [IETF-WGS]).
活動中および終了したIETFワーキンググループ（例えば、そのチャーター、公開済みまたは現在活動中の文書、およびメールアーカイブ）に関する情報は、[IETF-WGS]にあります。
Note that this document does not cover OAM technologies on the data-path including MPLS forwarding plane and control plane protocols (e.g., OAM of tunnels, MPLS-TP OAM, and pseudowire) as well as the corresponding management models and MIB modules. For a list of related work, see Section 1.2.
このドキュメントでは、MPLSフォワーディングプレーンおよびコントロールプレーンプロトコル（トンネルのOAM、MPLS-TP OAM、疑似配線など）を含むデータパス上のOAMテクノロジー、および対応する管理モデルとMIBモジュールについては取り上げません。関連する作業のリストについては、セクション1.2を参照してください。
"Internet Protocols for the Smart Grid" [RFC6272] gives an overview and guidance on the key protocols of the Internet Protocol Suite. In analogy to [RFC6272], this document gives an overview of the IETF network management standards and their usage scenarios.
「スマートグリッドのインターネットプロトコル」[RFC6272]は、インターネットプロトコルスイートの主要なプロトコルの概要とガイダンスを提供します。 [RFC6272]と同様に、このドキュメントはIETFネットワーク管理標準とその使用シナリオの概要を示します。
"Overview of the 2002 IAB Network Management Workshop" [RFC3535] documented strengths and weaknesses of some IETF management protocols. In choosing existing protocol solutions to meet the management requirements, it is recommended that these strengths and weaknesses be considered, even though some of the recommendations from the 2002 IAB workshop have become outdated, some have been standardized, and some are being worked on within the IETF.
「2002 IABネットワーク管理ワークショップの概要」[RFC3535]には、いくつかのIETF管理プロトコルの長所と短所が記載されています。管理要件を満たすために既存のプロトコルソリューションを選択する際には、2002年のIABワークショップからの推奨事項の一部が古くなっており、一部は標準化されており、一部は内部で作業されているにもかかわらず、これらの長所と短所を考慮することをお勧めしますIETF。
"Guidelines for Considering Operations and Management of New Protocols and Extensions" [RFC5706] recommends working groups consider operations and management needs and then select appropriate management protocols and data models. This document can be used to ease surveying the IETF Standards Track network management protocols and management data models.
「新しいプロトコルと拡張の運用と管理を検討するためのガイドライン」[RFC5706]は、作業グループが運用と管理のニーズを検討し、適切な管理プロトコルとデータモデルを選択することを推奨しています。このドキュメントを使用すると、IETF Standards Trackネットワーク管理プロトコルと管理データモデルを簡単に調査できます。
"Multiprotocol Label Switching (MPLS) Management Overview" [RFC4221] describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management, where "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks" [RFC6371] describes the OAM Framework for MPLS-based Transport Networks.
「マルチプロトコルラベルスイッチング（MPLS）管理の概要」[RFC4221]では、MPLSの管理アーキテクチャについて説明し、MPLSネットワーク管理に使用されるさまざまなMIBモジュール間の相互関係を示しています。「MPLSベースのトランスポートネットワークの操作、管理、およびメンテナンスフレームワーク」 [RFC6371]は、MPLSベースのトランスポートネットワークのOAMフレームワークについて説明しています。
"An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW] gives an overview of the OAM toolset for detecting and reporting connection failures or measuring connection performance parameters.
「操作、管理、保守（OAM）メカニズムの概要」[OAM-OVERVIEW]は、接続障害の検出と報告、または接続パフォーマンスパラメータの測定のためのOAMツールセットの概要を示しています。
"An Overview of the OAM Tool Set for MPLS-based Transport Networks" [OAM-ANALYSIS] provides an overview of the OAM toolset for MPLS-based Transport Networks including a brief summary of MPLS-TP OAM requirements and functions and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each MPLS-TP OAM tool are listed in separate documents, which are referenced.
「MPLSベースのトランスポートネットワーク用のOAMツールセットの概要」[OAM-ANALYSIS]は、MPLS-TP OAMの要件と機能、および作成された一般的なメカニズムの概要を含む、MPLSベースのトランスポートネットワーク用のOAMツールセットの概要を提供しますMPLSデータプレーンでは、OAMパケットをインバンドで実行し、運命をデータパケットと共有できます。各MPLS-TP OAMツールのプロトコル定義は、参照される個別のドキュメントにリストされています。
"MPLS-TP MIB-based Management Overview" [MPLSTP-MIB] describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required.
「MPLS-TP MIBベースの管理の概要」[MPLSTP-MIB]では、MPLS-TPのMIBベースのアーキテクチャについて説明し、MPLS-TPネットワーク管理に利用できるさまざまな既存のMIBモジュール間の相互関係を示し、追加の領域を特定しますMIBモジュールが必要です。
Note that so far, the IETF has not developed specific technologies for the management of sensor networks. IP-based sensors or constrained devices in such an environment, i.e., with very limited memory and CPU resources, can use, e.g., application-layer protocols to do simple resource management and monitoring.
これまでのところ、IETFはセンサーネットワークの管理のための特定のテクノロジーを開発していません。このような環境、つまりメモリとCPUリソースが非常に限られている環境にあるIPベースのセンサーまたは制約付きデバイスは、アプリケーション層プロトコルなどを使用して、単純なリソース管理と監視を行うことができます。
This document does not describe standard requirements. Therefore, key words from RFC 2119 [RFC2119] are not used in the document.
このドキュメントでは、標準的な要件については説明していません。したがって、RFC 2119 [RFC2119]のキーワードは、このドキュメントでは使用されていません。
o 3GPP: 3rd Generation Partnership Project, a collaboration between groups of telecommunications associations, to prepare the third-generation (3G) mobile phone system specification.
o 3GPP：第3世代（3G）携帯電話システム仕様を準備するための、電気通信団体のグループ間のコラボレーションである第3世代パートナーシッププロジェクト。
o Agent: A software module that performs the network management functions requested by network management stations. An agent may be implemented in any network element that is to be managed, such as a host, bridge, or router. The 'management server' in NETCONF terminology.
o エージェント：ネットワーク管理ステーションから要求されたネットワーク管理機能を実行するソフトウェアモジュール。エージェントは、ホスト、ブリッジ、ルーターなど、管理対象のネットワーク要素に実装できます。 NETCONF用語での「管理サーバー」。
o BCP: An IETF Best Current Practice document.
o BCP：IETF Best Current Practiceドキュメント。
o CLI: Command Line Interface. A management interface that system administrators can use to interact with networking equipment.
o CLI：コマンドラインインターフェース。システム管理者がネットワーク機器と対話するために使用できる管理インターフェース。
o Data model: A mapping of the contents of an information model into a form that is specific to a particular type of datastore or repository (see [RFC3444]).
o データモデル：情報モデルのコンテンツを、特定のタイプのデータストアまたはリポジトリに固有のフォームにマッピングすること（[RFC3444]を参照）。
o Event: An occurrence of something in the "real world". Events can be indicated to managers through an event message or notification.
o イベント：「現実の世界」で何かが発生。イベントは、イベントメッセージまたは通知を通じてマネージャに示すことができます。
o IAB: Internet Architecture Board
o IAB：インターネットアーキテクチャボード
o IANA: Internet Assigned Numbers Authority, an organization that oversees global IP address allocation, autonomous system number allocation, media types, and other IP-related code point allocations.
o IANA：Internet Assigned Numbers Authority。グローバルIPアドレス割り当て、自律システム番号割り当て、メディアタイプ、およびその他のIP関連コードポイント割り当てを監督する組織です。
o Information model: An abstraction and representation of entities in a managed environment, their properties, attributes, operations, and the way they relate to each other, independent of any specific repository, protocol, or platform (see [RFC3444]).
o 情報モデル：特定のリポジトリ、プロトコル、またはプラットフォームに関係なく、管理された環境のエンティティ、そのプロパティ、属性、操作、およびそれらが相互に関連する方法の抽象化と表現（[RFC3444]を参照）。
o ITU-T: International Telecommunication Union - Telecommunication Standardization Sector
o ITU-T：国際電気通信連合-電気通信標準化セクター
o Managed object: A management abstraction of a resource; a piece of management information in a MIB module. In the context of SNMP, a structured set of data variables that represent some resource to be managed or other aspect of a managed device.
o 管理対象オブジェクト：リソースの管理抽象概念。 MIBモジュール内の管理情報。 SNMPのコンテキストでは、管理対象のリソースまたは管理対象デバイスの他の側面を表す構造化されたデータ変数のセット。
o Manager: An entity that acts in a manager role, either a user or an application. The counterpart to an agent. A 'management client' in NETCONF terminology.
o マネージャー：ユーザーまたはアプリケーションのいずれかのマネージャーの役割で機能するエンティティ。エージェントのカウンターパート。 NETCONF用語での「管理クライアント」。
o Management Information Base (MIB): An information repository with a collection of related objects that represent the resources to be managed.
o 管理情報ベース（MIB）：管理対象のリソースを表す関連オブジェクトのコレクションを含む情報リポジトリ。
o MIB module: MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements in terms of appropriate object and event notification groups. A MIB that is provided by a management agent is typically composed of multiple instantiated MIB modules.
o MIBモジュール：通常、MIBモジュールにはオブジェクト定義が含まれ、イベント通知の定義が含まれる場合があり、適切なオブジェクトとイベント通知グループに関するコンプライアンスステートメントが含まれる場合があります。管理エージェントによって提供されるMIBは、通常、複数のインスタンス化されたMIBモジュールで構成されています。
o Modeling language: A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. Examples are Structure of Management Information Version 2 (SMIv2) [STD58], XML Schema Definition (XSD) [XSD-1], and YANG [RFC6020].
o モデリング言語：モデリング言語は、一貫した一連のルールによって定義された構造で情報、知識、またはシステムを表現するために使用できる人工的な言語です。例としては、管理情報バージョン2（SMIv2）の構造[STD58]、XMLスキーマ定義（XSD）[XSD-1]、YANG [RFC6020]があります。
o Notification: An unsolicited message sent by an agent to a management station to notify it of an unusual event.
o 通知：異常なイベントを通知するためにエージェントから管理ステーションに送信される非送信請求メッセージ。
o OAM: Operations, Administration, and Maintenance
o OAM：運用、管理、およびメンテナンス
o PDU: Protocol Data Unit, a unit of data, which is specified in a protocol of a given layer consisting protocol-control information and possibly layer-specific data.
o PDU：プロトコルデータユニット。データの単位であり、プロトコル制御情報と、場合によってはレイヤー固有のデータで構成される特定のレイヤーのプロトコルで指定されます。
o Principal: An application, an individual, or a set of individuals acting in a particular role, on whose behalf access to a service or MIB is allowed.
o プリンシパル：特定の役割で機能するアプリケーション、個人、または個人のセット。サービスまたはMIBへのアクセスが許可されます。
o RELAX NG: REgular LAnguage for XML Next Generation, a schema language for XML [RELAX-NG].
o RELAX NG：XMLのスキーマ言語であるXML Next Generation用の正規のLAnguage [RELAX-NG]。
o SDO: Standards Development Organization
o SDO：標準策定組織
o SMI: Structure of Managed Information, the notation and grammar for the managed information definition used to define MIB modules [STD58].
o SMI：管理情報の構造、MIBモジュールの定義に使用される管理情報定義の表記法と文法[STD58]。
o STDnn: An Internet Standard published at IETF, also referred as Standard, e.g., [STD62].
o STDnn：IETFで公開されたインターネット標準。Standardとも呼ばれます（例：[STD62]）。
o URI: Uniform Resource Identifier, a string of characters used to identify a name or a resource on the Internet [STD66]. Can be classified as locators (URLs), as names (URNs), or as both.
o URI：Uniform Resource Identifier、インターネット上の名前またはリソースを識別するために使用される文字列[STD66]。ロケーター（URL）、名前（URN）、またはその両方として分類できます。
o XPATH: XML Path Language, a query language for selecting nodes from an XML document [XPATH].
o XPATH：XMLドキュメントからノードを選択するためのクエリ言語であるXMLパス言語[XPATH]。
The SNMPv3 Framework [RFC3410], builds upon both the original SNMPv1 and SNMPv2 Frameworks. The basic structure and components for the SNMP Framework did not change between its versions and comprises the following components:
SNMPv3フレームワーク[RFC3410]は、元のSNMPv1フレームワークとSNMPv2フレームワークの両方に基づいています。 SNMPフレームワークの基本構造とコンポーネントは、バージョン間で変更はなく、次のコンポーネントで構成されています。
o managed nodes, each with an SNMP entity providing remote access to management instrumentation (the agent),
o 管理ノード（それぞれにSNMPエンティティーがあり、管理計装（エージェント）へのリモートアクセスを提供します）
o at least one SNMP entity with management applications (the manager), and
o 管理アプリケーション（マネージャー）を持つ少なくとも1つのSNMPエンティティ、および
o a management protocol used to convey management information between the SNMP entities and management information.
o SNMPエンティティと管理情報の間で管理情報を伝達するために使用される管理プロトコル。
During its evolution, the fundamental architecture of the SNMP Management Framework remained consistent based on a modular architecture, which consists of:
その進化の間、SNMP管理フレームワークの基本的なアーキテクチャは、以下で構成されるモジュラーアーキテクチャに基づいて一貫性を保ちました。
o a generic protocol definition independent of the data it is carrying,
o 運ぶデータに依存しない一般的なプロトコル定義、
o a protocol-independent data definition language,
o プロトコルに依存しないデータ定義言語
o an information repository containing a data set of management information definitions (the Management Information Base, or MIB), and
o 管理情報定義のデータセット（管理情報ベース、またはMIB）を含む情報リポジトリ、および
o security and administration.
o セキュリティと管理。
As such, the following standards build up the basis of the current SNMP Management Framework:
そのため、次の標準が現在のSNMP管理フレームワークの基礎を構築しています。
o the SNMPv3 protocol [STD62],
o SNMPv3プロトコル[STD62]、
o the modeling language SMIv2 [STD58], and
o モデリング言語SMIv2 [STD58]、および
o the MIB modules for different management issues.
o さまざまな管理問題のMIBモジュール。
The SNMPv3 Framework extends the architectural principles of SNMPv1 and SNMPv2 by:
SNMPv3フレームワークは、SNMPv1およびSNMPv2のアーキテクチャの原則を次のように拡張します。
o building on these three basic architectural components, in some cases, incorporating them from the SNMPv2 Framework by reference, and
o これらの3つの基本的なアーキテクチャコンポーネントに基づいて構築され、場合によっては、参照によりSNMPv2フレームワークからそれらを組み込みます。
o by using the same layering principles in the definition of new capabilities in the security and administration portion of the architecture.
o アーキテクチャのセキュリティおよび管理部分の新機能の定義に同じ階層化原則を使用する。
SNMP is based on three conceptual entities: Manager, Agent, and the Management Information Base (MIB). In any configuration, at least one manager node runs SNMP management software. Typically, network devices, such as bridges, routers, and servers, are equipped with an agent. The agent is responsible for providing access to a local MIB of objects that reflects the resources and activity at its node.
SNMPは、マネージャー、エージェント、および管理情報ベース（MIB）の3つの概念エンティティに基づいています。どの構成でも、少なくとも1つのマネージャーノードがSNMP管理ソフトウェアを実行します。通常、ブリッジ、ルーター、サーバーなどのネットワークデバイスにはエージェントが装備されています。エージェントは、ノードのリソースとアクティビティを反映するオブジェクトのローカルMIBへのアクセスを提供する責任があります。
Following the manager-agent paradigm, an agent can generate notifications and send them as unsolicited messages to the management application.
マネージャーとエージェントのパラダイムに従って、エージェントは通知を生成し、非請求メッセージとして管理アプリケーションに送信できます。
SNMPv2 enhances this basic functionality with an Inform PDU, a bulk transfer capability and other functional extensions like an administrative model for access control, security extensions, and Manager-to-Manager communication. SNMPv2 entities can have a dual role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers sufficient security features. To address the security deficiencies of SNMPv1/v2, SNMPv3 [STD62] has been issued.
SNMPv2は、Inform PDU、バルク転送機能、およびアクセス制御の管理モデル、セキュリティ拡張機能、Manager-to-Manager通信などの他の機能拡張により、この基本機能を強化します。 SNMPv2エンティティは、マネージャとエージェントの2つの役割を持つことができます。ただし、SNMPv1もSNMPv2も十分なセキュリティ機能を提供していません。 SNMPv1 / v2のセキュリティの欠陥に対処するために、SNMPv3 [STD62]が発行されました。
"Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" [BCP074] gives an overview of the relevant Standard documents on the three SNMP versions. The BCP document furthermore describes how to convert MIB modules from SMIv1 to SMIv2 format and how to translate notification parameters. It also describes the mapping between the message processing and security models.
「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、バージョン3の共存」[BCP074]は、3つのSNMPバージョンに関する関連する標準ドキュメントの概要を示しています。 BCPドキュメントには、MIBモジュールをSMIv1形式からSMIv2形式に変換する方法と、通知パラメーターを変換する方法がさらに記載されています。また、メッセージ処理とセキュリティモデル間のマッピングについても説明します。
SNMP utilizes the MIB, a virtual information store of modules of managed objects. Generally, standard MIB modules support common functionality in a device. Operators often define additional MIB modules for their enterprise or use the Command Line Interface (CLI) to configure non-standard data in managed devices and their interfaces.
SNMPは、管理対象オブジェクトのモジュールの仮想情報ストアであるMIBを利用します。一般に、標準MIBモジュールはデバイスの共通機能をサポートします。オペレーターは、多くの場合、企業に追加のMIBモジュールを定義するか、コマンドラインインターフェイス（CLI）を使用して、管理対象デバイスとそのインターフェイスに非標準データを構成します。
SNMPv2 Trap and Inform PDUs can alert an operator or an application when some aspects of a protocol fail or encounter an error condition, and the contents of a notification can be used to guide subsequent SNMP polling to gather additional information about an event.
SNMPv2トラップおよび通知PDUは、プロトコルの一部の側面が失敗したりエラー条件が発生したりした場合にオペレーターまたはアプリケーションにアラートを送信でき、通知の内容を使用して後続のSNMPポーリングをガイドし、イベントに関する追加情報を収集できます。
SNMP is widely used for the monitoring of fault and performance data and with its stateless nature, SNMP also works well for status polling and determining the operational state of specific functionality. The widespread use of counters in standard MIB modules permits the interoperable comparison of statistics across devices from different vendors. Counters have been especially useful in monitoring bytes and packets going in and out over various protocol interfaces. SNMP is often used to poll a basic parameter of a device (e.g., sysUpTime, which reports the time since the last re-initialization of the network management portion of the device) to check for operational liveliness and to detect discontinuities in counters. Some operators also use SNMP for configuration management in their environment (e.g., for systems based on Data Over Cable Service Interface Specification (DOCSIS) such as cable modems).
SNMPは障害データとパフォーマンスデータの監視に広く使用されており、そのステートレスな性質により、ステータスポーリングや特定の機能の動作状態の判別にも適しています。標準MIBモジュールでカウンタを広く使用すると、さまざまなベンダーのデバイス間で統計を相互運用可能に比較できます。カウンタは、さまざまなプロトコルインターフェイスを介して送受信されるバイトとパケットの監視に特に役立ちます。 SNMPは多くの場合、デバイスの基本的なパラメーター（sysUpTimeなど）をポーリングして、デバイスのネットワーク管理部分の最後の再初期化からの時間を報告して、稼働状態をチェックし、カウンターの不連続性を検出するために使用されます。一部の事業者は、環境内の構成管理にもSNMPを使用します（たとえば、ケーブルモデムなど、Data Over Cable Service Interface Specification（DOCSIS）に基づくシステム）。
SNMPv1 [RFC1157] has been declared Historic and its use is not recommended due to its lack of security features. "Introduction to Community-based SNMPv2" [RFC1901] is an Experimental RFC, which has been declared Historic, and its use is not recommended due to its lack of security features.
SNMPv1 [RFC1157]は歴史的であると宣言されており、セキュリティ機能がないため、その使用は推奨されません。 「Introduction to Community-based SNMPv2」[RFC1901]は実験的RFCであり、歴史的であると宣言されており、セキュリティ機能がないため、その使用は推奨されていません。
Use of SNMPv3 [STD62] is recommended due to its security features, including support for authentication, encryption, message timeliness and integrity checking, and fine-grained data access controls. An overview of the SNMPv3 document set is in [RFC3410].
認証、暗号化、メッセージの適時性と整合性チェックのサポート、きめ細かなデータアクセスコントロールなどのセキュリティ機能のため、SNMPv3 [STD62]の使用をお勧めします。 SNMPv3ドキュメントセットの概要は[RFC3410]にあります。
Standards exist to use SNMP over diverse transport and link-layer protocols, including Transmission Control Protocol (TCP) [STD07], User Datagram Protocol (UDP) [STD06], Ethernet [RFC4789], and others (see Section 2.1.5.1).
伝送制御プロトコル（TCP）[STD07]、ユーザーデータグラムプロトコル（UDP）[STD06]、イーサネット[RFC4789]など、さまざまなトランスポートおよびリンク層プロトコルでSNMPを使用するための標準が存在します（2.1.5.1を参照）。
SNMP MIB modules are defined with the notation and grammar specified as the Structure of Managed Information (SMI). The SMI uses an adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680].
SNMP MIBモジュールは、管理情報の構造（SMI）として指定された表記法と文法で定義されます。 SMIは、抽象構文記法1（ASN.1）[ITU-X680]の適応サブセットを使用します。
The SMI is divided into three parts: module definitions, object definitions, and notification definitions.
SMIは、モジュール定義、オブジェクト定義、通知定義の3つの部分に分かれています。
o Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module.
o モジュール定義は、情報モジュールを説明するときに使用されます。 ASN.1マクロMODULE-IDENTITYは、情報モジュールのセマンティクスを簡潔に伝えるために使用されます。
o Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object.
o オブジェクト定義は、管理対象オブジェクトを説明するときに使用されます。 ASN.1マクロOBJECT-TYPEは、管理対象オブジェクトの構文とセマンティクスを簡潔に伝えるために使用されます。
o Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification.
o 通知定義は、管理情報の一方的な送信を記述するときに使用されます。 ASN.1マクロのNOTIFICATION-TYPEは、通知の構文とセマンティクスを簡潔に伝えるために使用されます。
SMIv1 is specified in "Structure and Identification of Management Information for TCP/IP-based Internets" [RFC1155] and "Concise MIB Definitions" [RFC1212], both part of [STD16]. [RFC1215] specifies conventions for defining SNMP traps. Note that SMIv1 is outdated and its use is not recommended.
SMIv1は、[STD16]の一部である「TCP / IPベースのインターネットの管理情報の構造と識別」[RFC1155]および「簡潔なMIB定義」[RFC1212]で指定されています。 [RFC1215]は、SNMPトラップを定義するための規則を指定します。 SMIv1は古く、その使用は推奨されないことに注意してください。
SMIv2 is the new notation for managed information definitions and should be used to define MIB modules. SMIv2 is specified in the following RFCs. With the exception of BCP 74, they are all part of [STD58]:
SMIv2は管理情報定義の新しい表記法であり、MIBモジュールの定義に使用する必要があります。 SMIv2は、次のRFCで指定されています。 BCP 74を除いて、これらはすべて[STD58]の一部です。
o [RFC2578] defines Version 2 of the Structure of Management Information (SMIv2),
o [RFC2578]は、管理情報の構造（SMIv2）のバージョン2を定義します。
o [RFC2579] defines the textual conventions macro for defining new types and it provides a core set of generally useful textual convention definitions,
o [RFC2579]は、新しい型を定義するためのテキスト表記法マクロを定義し、一般的に有用なテキスト表記法定義のコアセットを提供します。
o [RFC2580] defines conformance statements and requirements for defining agent and manager capabilities, and
o [RFC2580]は、エージェントとマネージャの機能を定義するための適合性ステートメントと要件を定義し、
o [BCP074] defines the mapping rules for and the conversion of MIB modules between SMIv1 and SMIv2 formats.
o [BCP074]は、SMIv1とSMIv2フォーマット間のMIBモジュールのマッピングルールと変換を定義します。
Several of the classical threats to network protocols are applicable to management problem space and therefore are applicable to any security model used in an SNMP Management Framework. This section lists primary and secondary threats, and threats that are of lesser importance (see [RFC3411] for the detailed description of the security threats).
ネットワークプロトコルに対する従来の脅威のいくつかは、管理問題領域に適用できるため、SNMP管理フレームワークで使用されるすべてのセキュリティモデルに適用できます。このセクションでは、主要な脅威と二次的な脅威、およびそれほど重要ではない脅威をリストします（セキュリティの脅威の詳細については、[RFC3411]を参照してください）。
The primary threats against which SNMP Security Models can provide protection are, "modification of information" by an unauthorized entity, and "masquerade", i.e., the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal.
SNMPセキュリティモデルが保護を提供できる主な脅威は、無許可のエンティティによる「情報の変更」と「なりすまし」です。つまり、あるプリンシパルに対して許可されていない管理操作が別のプリンシパルのIDを引き継ぐことによって試行される危険性。
Secondary threats against which SNMP Security Models can provide protection are "message stream modification", e.g., reordering, delay, or replay of messages, and "disclosure", i.e., the danger of eavesdropping on the exchanges between SNMP engines.
SNMPセキュリティモデルが保護を提供できる二次的な脅威は、「メッセージストリームの変更」（メッセージの並べ替え、遅延、再生など）と「開示」（SNMPエンジン間のやり取りの盗聴の危険性）です。
There are two threats against which the SNMP Security Model does not protect, since they are deemed to be of lesser importance in this context: Denial of Service and Traffic Analysis (see [RFC3411]).
これらの脅威は、このコンテキストではそれほど重要ではないと見なされているため、SNMPセキュリティモデルでは保護されない2つの脅威があります。それは、サービス拒否とトラフィック分析です（[RFC3411]を参照）。
SNMPv3 [STD62] introduced the User-based Security Model (USM). USM is specified in [RFC3414] and provides authentication and privacy services for SNMP. Specifically, USM is designed to secure against the primary and secondary threats discussed in Section 2.1.4.1. USM does not secure against Denial of Service and attacks based on Traffic Analysis.
SNMPv3 [STD62]では、ユーザーベースのセキュリティモデル（USM）が導入されました。 USMは[RFC3414]で指定されており、SNMPの認証およびプライバシーサービスを提供します。具体的には、USMは、2.1.4.1項で説明した主要な脅威と二次的な脅威から保護するように設計されています。 USMは、トラフィック分析に基づくサービス拒否攻撃および攻撃から保護しません。
The USM supports following security services:
USMは以下のセキュリティサービスをサポートしています。
o Data integrity is the provision of the property that data has not been altered or destroyed in an unauthorized manner, nor have data sequences been altered to an extent greater than can occur non-maliciously.
o データの整合性とは、データが不正に変更または破壊されていないこと、データシーケンスが悪意なく発生する可能性のある範囲を超えて変更されていないことの特性の規定です。
o Data origin authentication is the provision of the property that the claimed identity of the user on whose behalf received data was originated is supported.
o データ発信元認証は、受信したデータの発信元であるユーザーの主張されたIDがサポートされているプロパティの提供です。
o Data confidentiality is the provision of the property that information is not made available or disclosed to unauthorized individuals, entities, or processes.
o データの機密性とは、権限のない個人、エンティティ、またはプロセスに対して情報が利用可能にされたり、開示されたりしないという特性の提供です。
o Message timeliness and limited replay protection is the provision of the property that a message whose generation time is outside of a specified time window is not accepted.
o メッセージの適時性と制限された再生保護は、生成時間が指定された時間枠の外にあるメッセージが受け入れられないというプロパティの提供です。
See [RFC3414] for a detailed description of SNMPv3 USM.
SNMPv3 USMの詳細な説明については、[RFC3414]を参照してください。
SNMPv3 [STD62] introduced the View-based Access Control (VACM) facility. The VACM is defined in [RFC3415] and enables the configuration of agents to provide different levels of access to the agent's MIB. An agent entity can restrict access to a certain portion of its MIB, e.g., restrict some principals to view only performance-related statistics or disallow other principals to read those performance-related statistics. An agent entity can also restrict the access to monitoring (read-only) as opposed to monitoring and configuration (read-write) of a certain portion of its MIB, e.g., allowing only a single designated principal to update configuration parameters.
SNMPv3 [STD62]は、ビューベースのアクセス制御（VACM）機能を導入しました。 VACMは[RFC3415]で定義されており、エージェントの構成でエージェントのMIBへのさまざまなレベルのアクセスを提供できます。エージェントエンティティは、MIBの特定の部分へのアクセスを制限できます。たとえば、一部のプリンシパルを制限して、パフォーマンス関連の統計のみを表示したり、他のプリンシパルがそれらのパフォーマンス関連の統計を読み取れないようにしたりできます。エージェントエンティティは、MIBの特定の部分の監視および構成（読み取り/書き込み）ではなく、監視（読み取り専用）へのアクセスを制限することもできます。
VACM defines five elements that make up the Access Control Model: groups, security level, contexts, MIB views, and access policy. Access to a MIB module is controlled by means of a MIB view.
VACMは、アクセス制御モデルを構成する5つの要素（グループ、セキュリティレベル、コンテキスト、MIBビュー、およびアクセスポリシー）を定義します。 MIBモジュールへのアクセスは、MIBビューによって制御されます。
See [RFC3415] for a detailed description of SNMPv3 VACM.
SNMPv3 VACMの詳細な説明については、[RFC3415]を参照してください。
The User-based Security Model (USM) was designed to be independent of other existing security infrastructures to ensure it could function when third-party authentication services were not available. As a result, USM utilizes a separate user and key-management infrastructure. Operators have reported that the deployment of a separate user and key-management infrastructure in order to use SNMPv3 is costly and hinders the deployment of SNMPv3.
ユーザーベースのセキュリティモデル（USM）は、サードパーティの認証サービスが利用できない場合でも機能できるように、他の既存のセキュリティインフラストラクチャから独立するように設計されています。その結果、USMは個別のユーザーとキー管理インフラストラクチャを利用します。オペレーターは、SNMPv3を使用するための個別のユーザーおよびキー管理インフラストラクチャの導入はコストがかかり、SNMPv3の導入を妨げると報告しています。
SNMP Transport Subsystem [RFC5590] extends the original SNMP architecture and Transport Model and enables the use of transport protocols to provide message security unifying the administrative security management for SNMP and other management interfaces.
SNMPトランスポートサブシステム[RFC5590]は、元のSNMPアーキテクチャとトランスポートモデルを拡張し、トランスポートプロトコルを使用して、SNMPおよびその他の管理インターフェイスの管理セキュリティ管理を統合するメッセージセキュリティを提供します。
Transport Models are tied into the SNMP Framework through the Transport Subsystem. The Transport Security Model [RFC5591] has been designed to work on top of lower-layer, secure Transport Models.
トランスポートモデルは、トランスポートサブシステムを介してSNMPフレームワークに関連付けられています。トランスポートセキュリティモデル[RFC5591]は、下位層の安全なトランスポートモデルの上で機能するように設計されています。
The SNMP Transport Model defines an alternative to existing standard transport mappings described in [RFC3417], e.g., for SNMP over UDP, in [RFC4789] for SNMP over IEEE 802 networks, and in the Experimental RFC [RFC3430] defining SNMP over TCP.
SNMPトランスポートモデルは、[RFC3417]で説明されている既存の標準トランスポートマッピングの代替を定義します。たとえば、SNMP over UDP、[RFC4789]、SNMP over IEEE 802ネットワーク、および実験的RFC [RFC3430]でSNMP over TCPを定義しています。
The SNMP Transport Security Model [RFC5591] is an alternative to the existing SNMPv1 and SNMPv2 Community-based Security Models [BCP074], and the User-based Security Model [RFC3414], part of [STD62].
SNMPトランスポートセキュリティモデル[RFC5591]は、既存のSNMPv1およびSNMPv2コミュニティベースのセキュリティモデル[BCP074]、および[STD62]の一部であるユーザーベースのセキュリティモデル[RFC3414]の代替です。
The Transport Security Model utilizes one or more lower-layer security mechanisms to provide message-oriented security services. These include authentication of the sender, encryption, timeliness checking, and data integrity checking.
トランスポートセキュリティモデルは、1つ以上の下位層セキュリティメカニズムを利用して、メッセージ指向のセキュリティサービスを提供します。これには、送信者の認証、暗号化、適時性チェック、およびデータ整合性チェックが含まれます。
A secure Transport Model sets up an authenticated and possibly encrypted session between the Transport Models of two SNMP engines. After a transport-layer session is established, SNMP messages can be sent through this session from one SNMP engine to the other. The new Transport Model supports the sending of multiple SNMP messages through the same session to amortize the costs of establishing a security association.
セキュアなトランスポートモデルは、2つのSNMPエンジンのトランスポートモデル間に認証済みの暗号化されたセッションをセットアップします。トランスポート層セッションが確立された後、SNMPメッセージは、このセッションを通じて1つのSNMPエンジンから他のエンジンに送信できます。新しいトランスポートモデルは、セキュリティアソシエーションを確立するコストを償却するために、同じセッションを介した複数のSNMPメッセージの送信をサポートしています。
The Secure Shell (SSH) Transport Model [RFC5592] and the Transport Layer Security (TLS) Transport Model [RFC6353] are current examples of Transport Security Models.
セキュアシェル（SSH）トランスポートモデル[RFC5592]およびトランスポート層セキュリティ（TLS）トランスポートモデル[RFC6353]は、トランスポートセキュリティモデルの現在の例です。
The SSH Transport Model makes use of the commonly deployed SSH security and key-management infrastructure. Furthermore, [RFC5592] defines MIB objects for monitoring and managing the SSH Transport Model for SNMP.
SSHトランスポートモデルは、一般的に配備されているSSHセキュリティとキー管理インフラストラクチャを利用します。さらに、[RFC5592]は、SNMPのSSHトランスポートモデルを監視および管理するためのMIBオブジェクトを定義しています。
The Transport Layer Security (TLS) Transport Model [RFC6353] uses either the TLS protocol [RFC5246] or the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. The TLS Transport Model supports the sending of SNMP messages over TLS and TCP and over DTLS and UDP. Furthermore, [RFC6353] defines MIB objects for managing the TLS Transport Model for SNMP.
トランスポート層セキュリティ（TLS）トランスポートモデル[RFC6353]は、TLSプロトコル[RFC5246]またはデータグラムトランスポート層セキュリティ（DTLS）プロトコル[RFC6347]のいずれかを使用します。 TLSおよびDTLSプロトコルは、SNMPアプリケーションに認証およびプライバシーサービスを提供します。 TLSトランスポートモデルは、TLSとTCP、およびDTLSとUDPを介したSNMPメッセージの送信をサポートしています。さらに、[RFC6353]は、SNMPのTLSトランスポートモデルを管理するためのMIBオブジェクトを定義しています。
[RFC5608] describes the use of a Remote Authentication Dial-In User Service (RADIUS) service by SNMP secure Transport Models for authentication of users and authorization of services. Access control authorization, i.e., how RADIUS attributes and messages are applied to the specific application area of SNMP Access Control Models, and VACM in particular has been specified in [RFC6065].
[RFC5608]は、ユーザーの認証とサービスの承認のための、SNMPセキュアトランスポートモデルによるリモート認証ダイヤルインユーザーサービス（RADIUS）サービスの使用について説明しています。アクセス制御認証、つまり、RADIUS属性とメッセージがSNMPアクセス制御モデルの特定のアプリケーション領域に適用される方法、特にVACMは、[RFC6065]で指定されています。
Syslog is a mechanism for distribution of logging information initially used on Unix systems (see [RFC3164] for BSD syslog). The IETF Syslog Protocol [RFC5424] introduces a layered architecture allowing the use of any number of transport protocols, including reliable and secure transports, for transmission of syslog messages.
Syslogは、Unixシステムで最初に使用されるロギング情報を配布するためのメカニズムです（BSD syslogについては[RFC3164]を参照）。 IETF Syslogプロトコル[RFC5424]は、syslogメッセージの送信のために、信頼性の高い安全なトランスポートを含む、任意の数のトランスポートプロトコルを使用できるようにする階層化アーキテクチャを導入しています。
The Syslog protocol enables a machine to send system log messages across networks to event message collectors. The protocol is simply designed to transport and distribute these event messages. By default, no acknowledgements of the receipt are made, except the reliable delivery extensions specified in [RFC3195] are used. The Syslog protocol and process does not require a stringent coordination between the transport sender and the receiver. Indeed, the transmission of syslog messages may be started on a device without a receiver being configured, or even actually physically present. Conversely, many devices will most likely be able to receive messages without explicit configuration or definitions.
Syslogプロトコルにより、マシンはネットワークを介してシステムログメッセージをイベントメッセージコレクターに送信できます。プロトコルは、これらのイベントメッセージを転送および配信するように設計されています。デフォルトでは、[RFC3195]で指定されている信頼できる配信拡張機能が使用されることを除いて、受信確認は行われません。 Syslogプロトコルとプロセスは、トランスポート送信側と受信側の間の厳密な調整を必要としません。実際、syslogメッセージの送信は、レシーバーが設定されていない、または実際に物理的に存在していないデバイスで開始される場合があります。逆に、多くのデバイスは、明示的な構成や定義がなくてもメッセージを受信できる可能性が最も高くなります。
BSD syslog had little uniformity for the message format and the content of syslog messages. The body of a BSD syslog message has traditionally been unstructured text. This content is human friendly, but difficult to parse for applications. With the Syslog Protocol [RFC5424], the IETF has standardized a new message header format, including timestamp, hostname, application, and message ID, to improve filtering, interoperability, and correlation between compliant implementations.
BSD syslogは、メッセージ形式とsyslogメッセージの内容にほとんど統一性がありませんでした。 BSD Syslogメッセージの本文は、従来、構造化されていないテキストでした。このコンテンツは人間に優しいですが、アプリケーションで解析するのは困難です。 Syslogプロトコル[RFC5424]により、IETFはタイムスタンプ、ホスト名、アプリケーション、メッセージIDを含む新しいメッセージヘッダー形式を標準化し、フィルタリング、相互運用性、および準拠した実装間の相関を改善しました。
The Syslog protocol [RFC5424] also introduces a mechanism for defining Structured Data Elements (SDEs). The SDEs allow vendors to define their own structured data elements to supplement standardized elements. [RFC5675] defines a mapping from SNMP notifications to syslog messages. [RFC5676] defines an SNMP MIB module to represent syslog messages for the purpose of sending those syslog messages as notifications to SNMP notification receivers. [RFC5674] defines the way alarms are sent in syslog, which includes the mapping of ITU-perceived severities onto syslog message fields and a number of alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF Alarm MIB [RFC3877].
Syslogプロトコル[RFC5424]では、構造化データ要素（SDE）を定義するためのメカニズムも導入されています。 SDEを使用すると、ベンダーは独自の構造化データ要素を定義して、標準化された要素を補足できます。 [RFC5675]は、SNMP通知からsyslogメッセージへのマッピングを定義しています。 [RFC5676]は、SNMP MIBモジュールを定義して、これらのsyslogメッセージをSNMP通知受信者への通知として送信することを目的として、syslogメッセージを表します。 [RFC5674]は、syslogでアラームが送信される方法を定義します。これには、syslogメッセージフィールドへのITU認識重大度のマッピングと、ITU-T X.733 [ITU-X733]およびIETFアラームMIBからの多数のアラーム固有の定義が含まれます[RFC3877]。
"Signed Syslog Messages" [RFC5848] defines a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages to be used in conjunction with the Syslog protocol.
「署名されたSyslogメッセージ」[RFC5848]は、送信元の認証、メッセージの整合性、再生耐性、メッセージの順序付け、および欠落メッセージの検出を、Syslogプロトコルと組み合わせて使用される送信されたsyslogメッセージに追加するメカニズムを定義しています。
The Syslog protocol's layered architecture provides support for a number of transport mappings. For interoperability purposes and especially in managed networks, where the network path has been explicitly provisioned for UDP syslog traffic, the Syslog protocol can be used over UDP [RFC5426]. However, to support congestion control and reliability, [RFC5426] strongly recommends the use of the TLS transport.
Syslogプロトコルの階層化アーキテクチャは、多数のトランスポートマッピングをサポートしています。相互運用性の目的で、特にネットワークパスがUDP syslogトラフィック用に明示的にプロビジョニングされている管理対象ネットワークでは、SyslogプロトコルをUDP [RFC5426]で使用できます。しかしながら、輻輳制御と信頼性をサポートするために、[RFC5426]はTLSトランスポートの使用を強く推奨します。
Furthermore, the IETF defined the TLS Transport Mapping for syslog in [RFC5425], which provides a secure connection for the transport of syslog messages. [RFC5425] describes the security threats to syslog and how TLS can be used to counter such threats. [RFC6012] defines the Datagram Transport Layer Security (DTLS) Transport Mapping for syslog, which can be used if a connectionless transport is desired.
さらに、IETFは[RFC5425]でsyslogのTLSトランスポートマッピングを定義しました。これは、syslogメッセージのトランスポートのための安全な接続を提供します。 [RFC5425]は、syslogに対するセキュリティの脅威と、TLSを使用してそのような脅威に対抗する方法について説明しています。 [RFC6012]は、syslogのデータグラムトランスポート層セキュリティ（DTLS）トランスポートマッピングを定義します。これは、コネクションレス型トランスポートが必要な場合に使用できます。
For information on MIB modules related to syslog, see Section 4.2.1.
syslogに関連するMIBモジュールについては、セクション4.2.1を参照してください。
2.3. IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP) Protocols
2.3. IPフロー情報eXport（IPFIX）およびパケットサンプリング（PSAMP）プロトコル
"Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information" (the IPFIX Protocol) [RFC5101] defines a push-based data export mechanism for transferring IP flow information in a compact binary format from an Exporter to a Collector.
「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」（IPFIXプロトコル）[RFC5101]は、エクスポーターからコンパクトバイナリ形式でIPフロー情報を転送するためのプッシュベースのデータエクスポートメカニズムを定義しますコレクターに。
"Architecture for IP Flow Information Export" (the IPFIX Architecture) [RFC5470] defines the components involved in IP flow measurement and reporting of information on IP flows, particularly, a Metering Process generating Flow Records, an Exporting Process that sends metered flow information using the IPFIX protocol, and a Collecting Process that receives flow information as IPFIX Data Records.
「IPフロー情報エクスポートのアーキテクチャ」（IPFIXアーキテクチャ）[RFC5470]は、IPフローの測定とIPフローに関する情報のレポートに関連するコンポーネントを定義します。 IPFIXプロトコル、およびフロー情報をIPFIXデータレコードとして受信する収集プロセス。
After listing the IPFIX requirements in [RFC3917], NetFlow Version 9 [RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX architecture.
IPFIX要件を[RFC3917]にリストした後、NetFlowバージョン9 [RFC3954]がIPFIXプロトコルとIPFIXアーキテクチャの基礎として採用されました。
IPFIX can run over different transport protocols. The IPFIX Protocol [RFC5101] specifies Stream Control Transmission Protocol (SCTP) [RFC4960] as the mandatory transport protocol to implement. Optional alternatives are TCP [STD07] and UDP [STD06].
IPFIXは、さまざまなトランスポートプロトコルで実行できます。 IPFIXプロトコル[RFC5101]は、実装する必須のトランスポートプロトコルとしてストリーム制御伝送プロトコル（SCTP）[RFC4960]を指定しています。オプションの選択肢は、TCP [STD07]とUDP [STD06]です。
SCTP is used with its Partial Reliability extension (PR-SCTP) specified in [RFC3758]. [RFC6526] specifies an extension to [RFC5101], when using the PR-SCTP [RFC3758]. The extension offers several advantages over IPFIX export, e.g., the ability to calculate Data Record losses for PR-SCTP, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process.
SCTPは、[RFC3758]で指定されている部分信頼性拡張（PR-SCTP）とともに使用されます。 [RFC6526]は、PR-SCTP [RFC3758]を使用する場合の[RFC5101]の拡張を指定します。拡張機能は、PR-SCTPのデータレコード損失を計算する機能、SCTPストリーム内でのテンプレートIDの即時再利用、データレコード損失の可能性の低減、収集プロセスへの要求の低減など、IPFIXエクスポートに勝るいくつかの利点を提供します。
IPFIX transmits IP flow information in Data Records containing IPFIX Information Elements (IEs) defined by the IPFIX Information Model [RFC5102]. IPFIX IEs are quantities with unit and semantics defined by the Information Model. When transmitted over the IPFIX protocol, only their values need to be carried in Data Records. This compact encoding allows efficient transport of large numbers of measured flow values. Remaining redundancy in Data Records can be further reduced by the methods described in [RFC5473] (for further discussion on IPFIX IEs, see Section 4).
IPFIXは、IPFIX情報モデル[RFC5102]によって定義されたIPFIX情報要素（IE）を含むデータレコードでIPフロー情報を送信します。 IPFIX IEは、情報モデルによって定義された単位とセマンティクスを持つ数量です。 IPFIXプロトコルを介して送信される場合、それらの値のみをデータレコードに含める必要があります。このコンパクトなエンコーディングにより、多数の測定された流量値を効率的に転送できます。データレコードの残りの冗長性は、[RFC5473]で説明されている方法でさらに削減できます（IPFIX IEの詳細については、セクション4を参照）。
The IPFIX Information Model is extensible. New IEs can be registered at IANA (see "IPFIX Information Elements" in [IANA-PROT]). IPFIX also supports the use of proprietary, i.e., enterprise-specific IEs.
IPFIX情報モデルは拡張可能です。新しいIEはIANAで登録できます（[IANA-PROT]の「IPFIX情報要素」を参照）。 IPFIXは、独自仕様の、つまり企業固有のIEの使用もサポートしています。
The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of transferring information on individual packets. [RFC5475] specifies a set of sampling and filtering techniques for IP packet selection, based on the PSAMP Framework [RFC5474]. The PSAMP Information Model [RFC5477] provides a set of basic IEs for reporting packet information with the IPFIX/PSAMP protocol.
PSAMPプロトコル[RFC5476]は、個々のパケットの情報を転送することによってIPFIXプロトコルを拡張します。 [RFC5475]は、PSAMPフレームワーク[RFC5474]に基づいて、IPパケット選択のための一連のサンプリングおよびフィルタリング技術を指定しています。 PSAMP情報モデル[RFC5477]は、IPFIX / PSAMPプロトコルでパケット情報を報告するための基本的なIEのセットを提供します。
The IPFIX model of an IP traffic flow is unidirectional. [RFC5103] adds means of reporting bidirectional flows to IPFIX, for example, both directions of packet flows of a TCP connection.
IPトラフィックフローのIPFIXモデルは単方向です。 [RFC5103]は、双方向のフローをレポートする手段を追加します。たとえば、TCP接続のパケットフローの両方向です。
When enterprise-specific IEs are transmitted with IPFIX, a Collector receiving Data Records may not know the type of received data and cannot choose the right format for storing the contained information. [RFC5610] provides a means of exporting extended type information for enterprise-specific Information Elements from an Exporter to a Collector.
企業固有のIEがIPFIXで送信される場合、データレコードを受信するコレクターは、受信したデータのタイプを認識できず、含まれている情報を格納するための正しい形式を選択できません。 [RFC5610]は、企業固有の情報要素の拡張タイプ情報をエクスポーターからコレクターにエクスポートする手段を提供します。
Collectors may store received flow information in files. The IPFIX file format [RFC5655] can be used for storing IP flow information in a way that facilitates exchange of traffic flow information between different systems and applications.
コレクターは、受信したフロー情報をファイルに保存できます。 IPFIXファイル形式[RFC5655]は、異なるシステムとアプリケーション間のトラフィックフロー情報の交換を容易にする方法でIPフロー情報を格納するために使用できます。
In terms of IPFIX and PSAMP configurations, the Metering and Exporting Processes are configured out of band. As the IPFIX protocol is a push mechanism only, IPFIX cannot configure the Exporter. The actual configuration of selection processes, caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant monitoring devices is executed using the NETCONF protocol [RFC6241] (see Section 2.4.1). The "Configuration Data Model for IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL] has been specified using Unified Modeling Language (UML) class diagrams. The data model is formally defined using the YANG modeling language [RFC6020] (see Section 2.4.2).
IPFIXおよびPSAMP構成に関しては、メータリングおよびエクスポートプロセスは帯域外で構成されます。 IPFIXプロトコルはプッシュメカニズムのみであるため、IPFIXはエクスポーターを構成できません。 IPFIXおよびPSAMP準拠の監視デバイスの選択プロセス、キャッシュ、エクスポートプロセス、収集プロセスの実際の構成は、NETCONFプロトコル[RFC6241]を使用して実行されます（セクション2.4.1を参照）。 「IPFIXおよびPSAMPの構成データモデル」（IPFIX構成データモデル）[CONF-MODEL]は、統一モデリング言語（UML）クラス図を使用して指定されています。データモデルは、YANGモデリング言語[RFC6020]を使用して正式に定義されています（セクション2.4.2を参照）。
At the time of this writing, a framework for IPFIX flow mediation is in preparation, which addresses the need for mediation of flow information in IPFIX applications in large operator networks, e.g., for aggregating huge amounts of flow data and for anonymization of flow information (see the problem statement in [RFC5982]).
この記事の執筆時点では、IPFIXフローメディエーションのフレームワークが準備されています。これは、大規模なオペレーターネットワークのIPFIXアプリケーションにおけるフロー情報のメディエーションの必要性に対処します。たとえば、大量のフローデータの集約やフロー情報の匿名化（ [RFC5982]の問題ステートメントを参照してください）。
The IPFIX Mediation Framework [RFC6183] defines the intermediate device between Exporters and Collectors, which provides an IPFIX mediation by receiving a record stream from, e.g., a Collecting Process, hosting one or more Intermediate Processes to transform this stream, and exporting the transformed record stream into IPFIX messages via an Exporting Process.
IPFIXメディエーションフレームワーク[RFC6183]は、エクスポーターとコレクターの間の中間デバイスを定義します。これは、たとえば収集プロセスからレコードストリームを受け取り、1つ以上の中間プロセスをホストしてこのストリームを変換し、変換されたレコードをエクスポートすることにより、IPFIXメディエーションを提供します。エクスポートプロセスを介してIPFIXメッセージにストリーミングします。
Examples for mediation functions are flow aggregation, flow selection, and anonymization of traffic information (see [RFC6235]).
仲介機能の例は、フロー集約、フロー選択、およびトラフィック情報の匿名化です（[RFC6235]を参照）。
Privacy, integrity, and authentication of the Exporter and Collector are important security requirements for IPFIX [RFC3917]. Confidentiality, integrity, and authenticity of IPFIX data transferred from an Exporting Process to a Collecting Process must be ensured. The IPFIX and PSAMP protocols do not define any new security mechanisms and rely on the security mechanism of the underlying transport protocol, such as TLS [RFC5246] and DTLS [RFC6347].
エクスポーターとコレクターのプライバシー、整合性、および認証は、IPFIX [RFC3917]の重要なセキュリティ要件です。エクスポートプロセスから収集プロセスに転送されるIPFIXデータの機密性、整合性、および信頼性を確保する必要があります。 IPFIXプロトコルとPSAMPプロトコルは新しいセキュリティメカニズムを定義せず、TLS [RFC5246]やDTLS [RFC6347]などの基になるトランスポートプロトコルのセキュリティメカニズムに依存しています。
The primary goal of IPFIX is the reporting of the flow accounting for flexible flow definitions and usage-based accounting. As described in the IPFIX Applicability Statement [RFC5472], there are also other applications such as traffic profiling, traffic engineering, intrusion detection, and QoS monitoring, that require flow-based traffic measurements and can be realized using IPFIX. Furthermore, the IPFIX Applicability Statement explains the relation of IPFIX to other framework and protocols such as PSAMP, RMON (Remote Network Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics, Section 3.4)). Similar flow information could be also used for security monitoring. The addition of Performance Metrics in the IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to performance management.
IPFIXの主な目的は、柔軟なフロー定義と使用量ベースのアカウンティングのためのフローアカウンティングのレポートです。 IPFIX Applicability Statement [RFC5472]で説明されているように、トラフィックプロファイリング、トラフィックエンジニアリング、侵入検知、QoSモニタリングなど、フローベースのトラフィック測定を必要とし、IPFIXを使用して実現できる他のアプリケーションもあります。さらに、IPFIXの適用に関する声明では、IPFIXとPSAMP、RMON（リモートネットワーク監視MIB、セクション4.2.1）、IPPM（IPパフォーマンスメトリック、セクション3.4）などの他のフレームワークおよびプロトコルとの関係について説明しています。同様のフロー情報は、セキュリティの監視にも使用できます。 IPFIX IANAレジストリ[IANA-IPFIX]にパフォーマンスメトリックを追加すると、IPFIXの使用例がパフォーマンス管理に拡張されます。
Note that even if the initial IPFIX focus has been around IP flow information exchange, non-IP-related IEs are now specified in the IPFIX IANA registration (e.g., MAC (Media Access Control) address, MPLS (Multiprotocol Label Switching) labels, etc.). At the time of this writing, there are requests to widen the focus of IPFIX and to export non-IP related IEs (such as SIP monitoring IEs).
最初のIPFIXの焦点がIPフロー情報交換にあった場合でも、IP以外のIEがIPFIX IANA登録（MAC（Media Access Control）アドレス、MPLS（Multiprotocol Label Switching）ラベルなど）で指定されるようになりました。 。）。この記事の執筆時点では、IPFIXの焦点を広げ、IPに関連しないIE（SIP監視IEなど）をエクスポートするように要求されています。
The IPFIX structured data [RFC6313] is an extension to the IPFIX protocol, which supports hierarchical structured data and lists (sequences) of Information Elements in Data Records. This extension allows the definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between templates. Furthermore, the extension provides the semantics to express the relationship among multiple list elements in a structured Data Record.
IPFIX構造化データ[RFC6313]は、IPFIXプロトコルの拡張であり、データレコード内の情報要素の階層構造化データとリスト（シーケンス）をサポートします。この拡張により、可変長リストなどの複雑なデータ構造の定義や、テンプレート間の階層的な包含関係の指定が可能になります。さらに、拡張機能は、構造化データレコード内の複数のリスト要素間の関係を表すセマンティクスを提供します。
For information on data models related to the management of the IPFIX and PSAMP protocols, see Sections 4.2.1 and 4.2.2. For information on IPFIX/PSAMP IEs, see Section 4.2.3.
IPFIXおよびPSAMPプロトコルの管理に関連するデータモデルの詳細については、セクション4.2.1および4.2.2を参照してください。 IPFIX / PSAMP IEについては、セクション4.2.3を参照してください。
The IAB workshop on Network Management [RFC3535] determined advanced requirements for configuration management:
ネットワーク管理に関するIABワークショップ[RFC3535]は、構成管理の高度な要件を決定しました。
o robustness: Minimizing disruptions and maximizing stability,
o 堅牢性：混乱を最小限に抑え、安定性を最大限に高める
o a task-oriented view,
o タスク指向のビュー、
o extensibility for new operations,
o 新しいオペレーションの拡張性
o standardized error handling,
o 標準化されたエラー処理、
o clear distinction between configuration data and operational state,
o 構成データと運用状態の明確な区別
o distribution of configurations to devices under transactional constraints,
o トランザクションの制約下でのデバイスへの構成の配布
o single- and multi-system transactions and scalability in the number of transactions and managed devices,
o 単一システムおよびマルチシステムのトランザクション、およびトランザクション数と管理対象デバイスの数におけるスケーラビリティ
o operations on selected subsets of management data,
o 管理データの選択されたサブセットに対する操作、
o dumping and reloading a device configuration in a textual format in a standard manner across multiple vendors and device types,
o 複数のベンダーおよびデバイスタイプにまたがる標準的な方法で、テキスト形式のデバイス構成をダンプおよびリロードします。
o a human interface and a programmatic interface,
o ヒューマンインターフェイスとプログラムインターフェイス
o a data modeling language with a human-friendly syntax,
o 人にやさしい構文のデータモデリング言語、
o easy conflict detection and configuration validation, and
o 簡単な競合の検出と構成の検証、および
o secure transport, authentication, and robust access control.
o 安全なトランスポート、認証、堅牢なアクセスコントロール。
The NETCONF protocol [RFC6241] provides mechanisms to install, manipulate, and delete the configuration of network devices and aims to address the configuration management requirements pointed out in the IAB workshop. It uses an XML-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple and reliable Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native command-line interface of the device.
NETCONFプロトコル[RFC6241]は、ネットワークデバイスの構成をインストール、操作、および削除するメカニズムを提供し、IABワークショップで指摘された構成管理要件に対処することを目的としています。構成データとプロトコルメッセージにXMLベースのデータエンコーディングを使用します。 NETCONFプロトコル操作は、シンプルで信頼性の高いリモートプロシージャコール（RPC）層の上に実現されます。 NETCONFの重要な側面は、管理プロトコルの機能がデバイスのネイティブコマンドラインインターフェイスを厳密に反映できることです。
The NETCONF working group developed the NETCONF Event Notifications Mechanism as an optional capability, which provides an asynchronous message notification delivery service for NETCONF [RFC5277]. The NETCONF notification mechanism enables using general purpose notification streams, where the originator of the notification stream can be any managed device (e.g., SNMP notifications).
NETCONFワーキンググループは、NETCONF [RFC5277]の非同期メッセージ通知配信サービスを提供するオプション機能として、NETCONFイベント通知メカニズムを開発しました。 NETCONF通知メカニズムにより、汎用通知ストリームを使用できるようになります。通知ストリームの発信元は、任意の管理対象デバイス（SNMP通知など）にすることができます。
The NETCONF Partial Locking specification introduces fine-grained locking of the configuration datastore to enhance NETCONF for fine-grained transactions on parts of the datastore [RFC5717].
NETCONF部分ロック仕様では、構成データストアのきめ細かなロックを導入して、データストアの部分でのきめ細かいトランザクションのNETCONFを強化しています[RFC5717]。
The NETCONF working group also defined the necessary data model to monitor the NETCONF protocol [RFC6022], by using the modeling language YANG [RFC6020] (see Section 2.4.2). The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server.
NETCONFワーキンググループは、モデリング言語YANG [RFC6020]を使用して、NETCONFプロトコル[RFC6022]を監視するために必要なデータモデルも定義しました（セクション2.4.2を参照）。監視データモデルには、NETCONFデータストア、セッション、ロック、および統計に関する情報が含まれ、NETCONFサーバーの管理を容易にします。
NETCONF connections are required to provide authentication, data integrity, confidentiality, and replay protection. NETCONF depends on the underlying transport protocol for this capability. For example, connections can be encrypted in TLS or SSH, depending on the underlying protocol.
NETCONF接続は、認証、データの整合性、機密性、およびリプレイ保護を提供するために必要です。 NETCONFは、この機能の基盤となるトランスポートプロトコルに依存しています。たとえば、基になるプロトコルに応じて、接続をTLSまたはSSHで暗号化できます。
The NETCONF working group defined the SSH transport protocol as the mandatory transport binding [RFC6242]. Other optional transport bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol (BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP) over HTTP over TLS [RFC4743].
NETCONFワーキンググループは、SSHトランスポートプロトコルを必須のトランスポートバインディング[RFC6242]として定義しました。その他のオプションのトランスポートバインディングは、TLS [RFC5539]、TLS上のブロック拡張交換プロトコル（BEEP）[RFC4744]、およびHTTP over TLS上のシンプルオブジェクトアクセスプロトコル（SOAP）[RFC4743]です。
The NETCONF Access Control Model (NACM) [RFC6536] provides standard mechanisms to restrict protocol access to particular users with a pre-configured subset of operations and content.
NETCONFアクセス制御モデル（NACM）[RFC6536]は、事前に構成された操作とコンテンツのサブセットを使用して、プロトコルアクセスを特定のユーザーに制限する標準メカニズムを提供します。
Following the guidelines of the IAB management workshop [RFC3535], the NETMOD working group developed a data modeling language defining the semantics of operational and configuration data, notifications, and operations [RFC6020]. The new data modeling language, called YANG, maps directly to XML-encoded content (on the wire) and will serve as the normative description of NETCONF data models.
IAB管理ワークショップ[RFC3535]のガイドラインに従って、NETMODワーキンググループは、運用および構成データ、通知、および運用の意味論を定義するデータモデリング言語を開発しました[RFC6020]。 YANGと呼ばれる新しいデータモデリング言語は、XMLエンコードされたコンテンツ（ネットワーク上）に直接マップされ、NETCONFデータモデルの規範的な記述として機能します。
YANG has the following properties addressing specific requirements on a modeling language for configuration management:
YANGには、構成管理のモデリング言語に関する特定の要件に対処する次のプロパティがあります。
o YANG provides the means to define hierarchical data models. It supports reusable data types and groupings, i.e., a set of schema nodes that can be reused across module boundaries.
o YANGは、階層データモデルを定義する手段を提供します。再利用可能なデータ型とグループ化、つまりモジュールの境界を越えて再利用できる一連のスキーマノードをサポートしています。
o YANG supports the distinction between configuration and state data. In addition, it provides support for modeling event notifications and the specification of operations that extend the base NETCONF operations.
o YANGは、構成データと状態データの区別をサポートしています。さらに、イベント通知のモデリングと、基本のNETCONF操作を拡張する操作の仕様をサポートします。
o YANG allows the expression of constraints on data models by means of type restrictions and XML Path Language (XPATH) 1.0 [XPATH] expressions. XPATH expressions can also be used to make certain portions of a data model conditional.
o YANGでは、型の制限とXMLパス言語（XPATH）1.0 [XPATH]式を使用して、データモデルの制約を表現できます。 XPATH式を使用して、データモデルの特定の部分を条件付きにすることもできます。
o YANG supports the integration of standard- and vendor-defined data models. YANG's augmentation mechanism allows the seamless augmentation of standard data models with proprietary extensions.
o YANGは、標準およびベンダー定義のデータモデルの統合をサポートしています。 YANGの拡張メカニズムにより、独自の拡張機能を備えた標準データモデルのシームレスな拡張が可能になります。
o YANG data models can be partitioned into collections of features, allowing low-end devices only to implement the core features of a data model while high-end devices may choose to support all features. The supported features are announced via the NETCONF capability exchange to management applications.
o YANGデータモデルは機能のコレクションに分割できるため、ローエンドデバイスはデータモデルのコア機能のみを実装でき、ハイエンドデバイスはすべての機能のサポートを選択できます。サポートされる機能は、NETCONF機能交換を介して管理アプリケーションに通知されます。
o The syntax of the YANG language is compact and optimized for human readers. An associated XML-based syntax called the YANG Independent Notation (YIN) [RFC6020] is available to allow the processing of YANG data models with XML-based tools. The mapping rules for the translation of YANG data models into Document Schema Definition Languages (DSDL), of which RELAX NG is a major component, are defined in [RFC6110].
o YANG言語の構文はコンパクトで、人間の読者向けに最適化されています。 YANG Independent Notation（YIN）[RFC6020]と呼ばれる関連するXMLベースの構文を使用して、XMLベースのツールでYANGデータモデルを処理できます。 YANGデータモデルをRELAX NGが主要コンポーネントであるドキュメントスキーマ定義言語（DSDL）に変換するためのマッピングルールは、[RFC6110]で定義されています。
o Devices implementing standard data models can document deviations from the data model in separate YANG modules. Applications capable of discovering deviations can make allowances that would otherwise not be possible.
o 標準データモデルを実装するデバイスは、データモデルからの逸脱を個別のYANGモジュールに文書化できます。逸脱を発見できるアプリケーションは、他の方法では不可能な手当を作成できます。
A collection of common data types for IETF-related standards is provided in [RFC6021]. This standard data type library has been derived to a large extend from common SMIv2 data types, generalizing them to a less-constrained NETCONF Framework.
IETF関連の標準の一般的なデータ型のコレクションは、[RFC6021]で提供されています。この標準データタイプライブラリは、一般的なSMIv2データタイプから大幅に拡張され、制約の少ないNETCONFフレームワークに一般化されています。
The document "An Architecture for Network Management using NETCONF and YANG" describes how NETCONF and YANG can be used to build network management applications that meet the needs of network operators [RFC6244].
ドキュメント「NETCONFとYANGを使用したネットワーク管理のアーキテクチャ」では、NETCONFとYANGを使用して、ネットワークオペレーターのニーズを満たすネットワーク管理アプリケーションを構築する方法について説明しています[RFC6244]。
The Experimental RFC [RFC6095] specifies extensions for YANG, introducing language abstractions such as class inheritance and recursive data structures.
試験的RFC [RFC6095]は、YANGの拡張を指定し、クラスの継承や再帰的なデータ構造などの言語の抽象化を導入しています。
[RFC6087] gives guidelines for the use of YANG within the IETF and other standardization organizations.
[RFC6087]は、IETFおよびその他の標準化組織内でのYANGの使用に関するガイドラインを提供します。
Work is underway to standardize a translation of SMIv2 data models into YANG data models preserving investments into SNMP MIB modules, which are widely available for monitoring purposes [SMI-YANG].
SMIv2データモデルからYANGデータモデルへの変換を標準化し、SNMP MIBモジュールへの投資を維持する作業が進行中です。SNMPMIBモジュールは、監視目的で広く利用できます[SMI-YANG]。
Several independent and open source implementations of the YANG data modeling language and associated tools are available.
YANGデータモデリング言語と関連ツールのいくつかの独立したオープンソース実装が利用可能です。
While YANG is a relatively recent data modeling language, some data models have already been produced. The specification of the base NETCONF protocol operations has been revised and uses YANG as the normative modeling language to specify its operations [RFC6241]. The IPFIX working group prepared the normative model for configuring and monitoring IPFIX- and PSAMP-compliant monitoring devices using the YANG modeling language [CONF-MODEL].
YANGは比較的最近のデータモデリング言語ですが、一部のデータモデルはすでに作成されています。基本NETCONFプロトコル操作の仕様が改訂され、その操作を指定するための規範的なモデリング言語としてYANGが使用されています[RFC6241]。 IPFIXワーキンググループは、YANGモデリング言語[CONF-MODEL]を使用して、IPFIXおよびPSAMP準拠の監視デバイスを構成および監視するための規範モデルを準備しました。
At the time of this writing, the NETMOD working group is developing core system and interface data models. Following the example of the IPFIX configuration model, IETF working groups will prepare models for their specific needs.
この記事の執筆時点で、NETMODワーキンググループはコアシステムとインターフェイスデータモデルを開発しています。 IPFIX構成モデルの例に従って、IETFワーキンググループは、特定のニーズに合わせてモデルを準備します。
For information on data models developed using the YANG modeling language, see Sections 4.2.1 and 4.2.2.
YANGモデリング言語を使用して開発されたデータモデルの詳細については、セクション4.2.1および4.2.2を参照してください。
This section reviews additional protocols the IETF offers for management and discusses for which applications they were designed and/or have already been successfully deployed. These are protocols that have mostly reached Proposed Standard status or higher within the IETF.
このセクションでは、IETFが管理用に提供する追加のプロトコルを確認し、それらが設計されたアプリケーション、および/または既に正常に展開されているアプリケーションについて説明します。これらは、IETF内で主にProposed Standardステータス以上に達したプロトコルです。
Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network and, as such, enables autoconfiguration in IP networks. In addition to IP address management, DHCP can also provide other configuration information, such as default routers, the IP addresses of recursive DNS servers, and the IP addresses of NTP servers. As described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address Allocation and Assignment as well as for Service Discovery.
動的ホスト構成プロトコル（DHCP）[RFC2131]は、TCP / IPネットワーク上のホストに構成情報を渡すためのフレームワークを提供し、IPネットワークでの自動構成を可能にします。 DHCPは、IPアドレス管理に加えて、デフォルトルーター、再帰DNSサーバーのIPアドレス、NTPサーバーのIPアドレスなど、他の構成情報も提供できます。 [RFC6272]で説明されているように、DHCPはIPv4およびIPv6アドレスの割り当てと割り当て、およびサービスディスカバリに使用できます。
There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently defined to accommodate new functions required by IPv6 such as assignment of multiple addresses to an interface and to address limitations in the design of DHCPv4 resulting from its origins in BOOTP. While both versions bear the same name and perform the same functionality, the details of DHCPv4 and DHCPv6 are sufficiently different that they can be considered separate protocols.
DHCPには2つのバージョンがあります。1つはIPv4（DHCPv4）[RFC2131]、もう1つはIPv6（DHCPv6）[RFC3315]です。 DHCPv4は、BOOTP（ブートストラッププロトコル）[RFC0951]の拡張機能として定義されました。 DHCPv6はその後、インターフェイスへの複数のアドレスの割り当てなどのIPv6に必要な新機能に対応し、BOOTPの起源に起因するDHCPv4の設計における制限に対処するために定義されました。どちらのバージョンも同じ名前で同じ機能を実行しますが、DHCPv4とDHCPv6の詳細は十分に異なるため、別々のプロトコルと見なすことができます。
In addition to the assignment of IP addresses and other configuration information, DHCP options like the Relay Agent Information option (DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315] are widely used by ISPs.
IPアドレスやその他の構成情報の割り当てに加えて、リレーエージェント情報オプション（DHCPv4）[RFC3046]やインターフェイスIDオプション（DHCPv6）[RFC3315]などのDHCPオプションは、ISPで広く使用されています。
DHCPv6 includes Prefix Delegation [RFC3633], which is used to provision a router with an IPv6 prefix for use in the subnetwork supported by the router.
DHCPv6には、プレフィックス委任[RFC3633]が含まれています。これは、ルーターがサポートするサブネットワークで使用するIPv6プレフィックスをルーターにプロビジョニングするために使用されます。
The following are examples of DHCP options that provide configuration information or access to specific servers. A complete list of DHCP options is available at [IANA-PROT].
以下は、構成情報または特定のサーバーへのアクセスを提供するDHCPオプションの例です。 DHCPオプションの完全なリストは、[IANA-PROT]で入手できます。
o "DNS Configuration options for Dynamic Host Configuration Protocol for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing a list of available DNS recursive name servers and a domain search list to a client.
o 「IPV6の動的ホスト構成プロトコル（DHCPv6）のDNS構成オプション」[RFC3646]では、使用可能なDNS再帰ネームサーバーのリストとドメイン検索リストをクライアントに渡すためのDHCPv6オプションについて説明しています。
o "DHCP Options for Service Location Protocol" [RFC2610] describes DHCPv4 options and methods through which entities using the Service Location Protocol can find out the address of Directory Agents in order to transact messages and how the assignment of scope for configuration of Service Location Protocol (SLP) User and Service Agents can be achieved.
o 「サービスロケーションプロトコルのDHCPオプション」[RFC2610]では、サービスロケーションプロトコルを使用するエンティティがメッセージを処理するためにディレクトリエージェントのアドレスを検索できるDHCPv4オプションと方法、およびサービスロケーションプロトコルの構成スコープの割り当て（ SLP）ユーザーおよびサービスエージェントを実現できます。
o "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6 options that allow SIP clients to locate a local SIP server that is to be used for all outbound SIP requests, a so-called "outbound proxy server".
o 「セッション開始プロトコル（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション」[RFC3319]は、SIPクライアントがすべての発信SIP要求に使用されるローカルSIPサーバー、いわゆる「」を検索できるようにするDHCPv6オプションを指定しますアウトバウンドプロキシサーバー」。
o "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers" [RFC4280] defines DHCPv6 options to discover the Broadcast and Multicast Service (BCMCS) controller in an IP network.
o 「ブロードキャストおよびマルチキャスト制御サーバーの動的ホスト構成プロトコル（DHCP）オプション」[RFC4280]は、IPネットワーク内のブロードキャストおよびマルチキャストサービス（BCMCS）コントローラーを検出するためのDHCPv6オプションを定義しています。
Built directly on UDP and IP, DHCP itself has no security provisions. There are two different classes of potential security issues related to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients. The recommended solutions to these risks generally involve providing security at lower layers, e.g., careful control over physical access to the network, security techniques implemented at Layer 2 but also IPsec at Layer 3 can be used to provide authentication.
UDPおよびIP上に直接構築されたDHCP自体には、セキュリティ機能はありません。 DHCPに関連する潜在的なセキュリティ問題には、2つの異なるクラスがあります。不正なDHCPサーバーと不正なDHCPクライアントです。これらのリスクに対する推奨されるソリューションには、一般に、下位層でのセキュリティの提供が含まれます。たとえば、ネットワークへの物理アクセスの注意深い制御、レイヤー2で実装されているセキュリティ技術だけでなく、レイヤー3でのIPsecを使用して認証を提供できます。
Ad hoc nodes need to configure their network interfaces with locally unique addresses as well as globally routable IPv6 addresses, in order to communicate with devices on the Internet. The IETF AUTOCONF working group developed [RFC5889], which describes the addressing model for ad hoc networks and how nodes in these networks configure their addresses.
アドホックノードは、インターネット上のデバイスと通信するために、ローカルで一意のアドレスとグローバルにルーティング可能なIPv6アドレスを使用してネットワークインターフェイスを構成する必要があります。 IETF AUTOCONFワーキンググループは[RFC5889]を開発しました。これは、アドホックネットワークのアドレス指定モデルと、これらのネットワーク内のノードがアドレスを構成する方法を説明しています。
The ad hoc nodes under consideration are expected to be able to support multi-hop communication by running MANET (Mobile Ad Hoc Network) routing protocols as developed by the IETF MANET working group.
検討中のアドホックノードは、IETF MANETワーキンググループによって開発されたMANET（モバイルアドホックネットワーク）ルーティングプロトコルを実行することにより、マルチホップ通信をサポートできることが期待されています。
From the IP layer perspective, an ad hoc network presents itself as a Layer 3 multi-hop network formed over a collection of links. The addressing model aims to avoid problems for parts of the system that are ad hoc unaware, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes.
IPレイヤーの観点から見ると、アドホックネットワークは、リンクのコレクション上に形成されたレイヤー3マルチホップネットワークとして存在します。アドレッシングモデルは、アドホックノードまたはアドホックノードに接続された通常のインターネットノードで実行されている標準アプリケーションなど、アドホックに認識されないシステムの部分の問題を回避することを目的としています。
The IPv6 Operations (V6OPS) working group develops guidelines for the operation of a shared IPv4/IPv6 Internet and provides operational guidance on how to deploy IPv6 into existing IPv4-only networks, as well as into new network installations.
IPv6運用（V6OPS）ワーキンググループは、共有IPv4 / IPv6インターネットの運用に関するガイドラインを作成し、IPv6を既存のIPv4専用ネットワークや新しいネットワークインストールに展開する方法に関する運用ガイダンスを提供します。
o "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213] specifies IPv4 compatibility mechanisms for dual-stack and configured tunneling that can be implemented by IPv6 hosts and routers. "Dual stack" implies providing complete implementations of both IPv4 and IPv6, and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.
o 「IPv6ホストとルーターの基本的な移行メカニズム」[RFC4213]は、IPv6ホストとルーターで実装できるデュアルスタックおよび構成済みトンネリングのIPv4互換性メカニズムを指定しています。 「デュアルスタック」は、IPv4とIPv6の両方の完全な実装を提供することを意味し、設定されたトンネリングは、変更されていないIPv4ルーティングインフラストラクチャ上でIPv6パケットを伝送する手段を提供します。
o "Transition Scenarios for 3GPP Networks" [RFC3574] lists different scenarios in 3GPP defined packet network that would need IPv6 and IPv4 transition, where "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks" [RFC4215] does a more detailed analysis of the transition scenarios that may come up in the deployment phase of IPv6 in 3GPP packet networks.
o 「3GPPネットワークの移行シナリオ」[RFC3574]は、IPv6とIPv4の移行が必要な3GPP定義のパケットネットワークのさまざまなシナリオを示しています。「第3世代パートナーシッププロジェクト（3GPP）ネットワークでのIPv6移行の分析」[RFC4215]は、より詳細な分析を行います。 3GPPパケットネットワークでのIPv6の展開フェーズで発生する可能性のある移行シナリオの例。
o "Scenarios and Analysis for Introducing IPv6 into ISP Networks" [RFC4029] describes and analyzes different scenarios for the introduction of IPv6 into an ISP's existing IPv4 network. "IPv6 Deployment Scenarios in 802.16 Networks" [RFC5181] provides a detailed description of IPv6 deployment, integration methods, and scenarios in wireless broadband access networks (802.16) in coexistence with deployed IPv4 services. [RFC4057] describes the scenarios for IPv6 deployment within enterprise networks.
o 「ISPネットワークにIPv6を導入するためのシナリオと分析」[RFC4029]は、ISPの既存のIPv4ネットワークにIPv6を導入するためのさまざまなシナリオを説明および分析します。 「802.16ネットワークでのIPv6展開シナリオ」[RFC5181]では、IPv6の展開、統合方法、および展開されたIPv4サービスと共存するワイヤレスブロードバンドアクセスネットワーク（802.16）でのシナリオについて詳しく説明しています。 [RFC4057]は、エンタープライズネットワーク内でのIPv6展開のシナリオについて説明しています。
o "Application Aspects of IPv6 Transition" [RFC4038] specifies scenarios and application aspects of IPv6 transition considering how to enable IPv6 support in applications running on IPv6 hosts, and giving guidance for the development of IP-version-independent applications.
o 「IPv6移行のアプリケーションの側面」[RFC4038]は、IPv6ホストで実行されているアプリケーションでIPv6サポートを有効にする方法を検討し、IPバージョンに依存しないアプリケーションの開発に関するガイダンスを提供する、IPv6移行のシナリオとアプリケーションの側面を指定します。
o "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] updates RFC 5735 and requested the allocation of an IPv4/10 address block to be used as "Shared Carrier-Grade Network Address Translation (CGN) Space" by Service Providers to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).
o「共有アドレススペースのIANA予約IPv4プレフィックス」[RFC6598]はRFC 5735を更新し、サービスプロバイダーがIPv4 / 10アドレスブロックの割り当てを「共有キャリアグレードネットワークアドレス変換（CGN）スペース」として使用するように要求しました。 CGNデバイスを顧客宅内機器（CPE）に接続するインターフェースに番号を付けます。
The IETF specified a general policy framework [RFC2753] for managing, sharing, and reusing policies in a vendor-independent, interoperable, and scalable manner. [RFC3460] specifies the Policy Core Information Model (PCIM) as an object-oriented information model for representing policy information. PCIM has been developed jointly in the IETF Policy Framework (POLICY) working group and the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). PCIM has been published as extensions to CIM [DMTF-CIM].
IETFは、ベンダーに依存せず、相互運用可能でスケーラブルな方法でポリシーを管理、共有、再利用するための一般的なポリシーフレームワーク[RFC2753]を指定しました。 [RFC3460]は、ポリシー情報を表すためのオブジェクト指向の情報モデルとして、ポリシーコア情報モデル（PCIM）を指定しています。 PCIMは、IETF Policy Framework（POLICY）ワーキンググループと、Distributed Management Task Force（DMTF）のCommon Information Model（CIM）活動で共同で開発されました。 PCIMはCIM [DMTF-CIM]の拡張機能として公開されています。
The IETF Policy Framework is based on a policy-based admission control specifying two main architectural elements: the Policy Enforcement Point (PEP) and the Policy Decision Point (PDP). For the purpose of network management, policies allow an operator to specify how the network is to be configured and monitored by using a descriptive language. Furthermore, it allows the automation of a number of management tasks, according to the requirements set out in the policy module.
IETFポリシーフレームワークは、2つの主要なアーキテクチャ要素であるポリシー実施ポイント（PEP）とポリシー決定ポイント（PDP）を指定するポリシーベースのアドミッションコントロールに基づいています。ネットワーク管理の目的で、ポリシーにより、オペレーターは記述言語を使用してネットワークを構成およびモニターする方法を指定できます。さらに、ポリシーモジュールで設定された要件に従って、多くの管理タスクを自動化できます。
The IETF Policy Framework has been accepted by the industry as a standard-based policy management approach and has been adopted by different SDOs, e.g., for 3GGP charging standards.
IETFポリシーフレームワークは業界で標準ベースのポリシー管理アプローチとして受け入れられており、たとえば3GGP課金標準などのさまざまなSDOで採用されています。
3.3.2. Use of Common Open Policy Service (COPS) for Policy Provisioning (COPS-PR)
3.3.2. ポリシープロビジョニング（COPS-PR）のためのCommon Open Policy Service（COPS）の使用
[RFC3159] defines the Structure of Policy Provisioning Information (SPPI), an extension to the SMIv2 modeling language used to write Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the Common Open Policy Service (COPS) protocol [RFC2748] for the provisioning of policy information. COPS provides a simple client/ server model for supporting policy control over QoS signaling protocols. The COPS-PR specification is independent of the type of policy being provisioned (QoS, security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between policy-decision-points (PDPs) and policy enforcement points (PEPs). Policy data is modeled using PIB modules.
[RFC3159]は、ポリシープロビジョニング情報（SPPI）の構造を定義しています。これは、ポリシー情報ベース（PIB）モジュールの記述に使用されるSMIv2モデリング言語の拡張機能です。 COPS-PR [RFC3084]は、ポリシー情報のプロビジョニングにCommon Open Policy Service（COPS）プロトコル[RFC2748]を使用します。 COPSは、QoSシグナリングプロトコルに対するポリシー制御をサポートするためのシンプルなクライアント/サーバーモデルを提供します。 COPS-PR仕様は、プロビジョニングされるポリシーのタイプ（QoS、セキュリティなど）に依存しませんが、ポリシー決定ポイント（PDP）とポリシー実施ポイント（PEP）の間でプロビジョニングされた情報を伝達するために使用されるメカニズムと規則に焦点を当てています。ポリシーデータは、PIBモジュールを使用してモデル化されます。
COPS-PR has not been widely deployed, and operators have stated that its use of binary encoding for management data makes it difficult to develop automated scripts for simple configuration management tasks in most text-based scripting languages. In the IAB Workshop on Network Management [RFC3535], the consensus of operators and protocol developers indicated a lack of interest in PIB modules for use with COPS-PR.
COPS-PRは広く展開されておらず、管理データにバイナリエンコーディングを使用すると、ほとんどのテキストベースのスクリプト言語で簡単な構成管理タスク用の自動スクリプトを開発することが困難になると、事業者は述べています。ネットワーク管理に関するIABワークショップ[RFC3535]で、オペレーターとプロトコル開発者のコンセンサスは、COPS-PRで使用するPIBモジュールへの関心の欠如を示しました。
As a result, even if COPS-PR and the Structure of Policy Provisioning Information (SPPI) were initially approved as Proposed Standards, the IESG has not approved any PIB modules as Proposed Standard, and the use of COPS-PR is not recommended.
その結果、COPS-PRおよびポリシープロビジョニング情報の構造（SPPI）が最初に提案された標準として承認された場合でも、IESGはPIBモジュールを提案された標準として承認していないため、COPS-PRの使用は推奨されません。
The IPPM working group has defined metrics for accurately measuring and reporting the quality, performance, and reliability of Internet data delivery. The metrics include connectivity, one-way delay and loss, round-trip delay and loss, delay variation, loss patterns, packet reordering, bulk transport capacity, and link bandwidth capacity.
IPPMワーキンググループは、インターネットデータ配信の品質、パフォーマンス、および信頼性を正確に測定および報告するためのメトリックを定義しています。メトリックには、接続性、一方向の遅延と損失、往復の遅延と損失、遅延変動、損失パターン、パケットの並べ替え、バルク転送容量、リンク帯域幅容量が含まれます。
These metrics are designed for use by network operators and their customers, and they provide unbiased quantitative measures of performance. The IPPM metrics have been developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most of the metrics can be used inside a passive context as well. At the time of this writing, there is no work planned in the area of passive measurement.
これらのメトリックは、ネットワークオペレーターとその顧客が使用するために設計されており、パフォーマンスの公平な定量的測定を提供します。 IPPMメトリックはアクティブな測定コンテキスト内で開発されました。つまり、メトリックの測定に使用されるデバイスは独自のトラフィックを生成します。ただし、ほとんどのメトリックはパッシブコンテキスト内でも使用できます。この記事の執筆時点では、パッシブ測定の領域で計画された作業はありません。
As a property, individual IPPM performance and reliability metrics need to be well defined and concrete: thus, implementable. Furthermore, the methodology used to implement a metric needs to be repeatable with consistent measurements.
プロパティとして、個々のIPPMのパフォーマンスと信頼性の指標は明確に定義され、具体的である必要があります。つまり、実装可能です。さらに、メトリックの実装に使用される方法論は、一貫した測定で再現可能である必要があります。
IPPMs have been adopted by different organizations, e.g., the Metro Ethernet Forum.
IPPMは、メトロイーサネットフォーラムなどのさまざまな組織で採用されています。
Note that this document does not aim to cover OAM technologies on the data-path and, as such, the discussion of IPPM-based active versus passive monitoring as well as the data plane measurement and its diagnostics is rather incomplete. For a detailed overview and discussion of IETF OAM standards and IPPM measurement mechanisms, the reader is referred to the documents listed at the end of Section 1.2 ("Related Work") but especially to [OAM-OVERVIEW].
このドキュメントはデータパス上のOAMテクノロジーをカバーすることを目的としていないことに注意してください。そのため、IPPMベースのアクティブモニタリングとパッシブモニタリング、およびデータプレーン測定とその診断についての議論はかなり不完全です。 IETF OAM標準とIPPM測定メカニズムの詳細な概要と説明については、セクション1.2（「関連作業」）の最後にリストされているドキュメント、特に[OAM-OVERVIEW]を参照してください。
The following are essential IPPM documents:
以下は、重要なIPPMドキュメントです。
o "Framework for IP Performance Metrics" [RFC2330] defines a general framework for particular metrics developed by the IPPM working group, and it defines the fundamental concepts of 'metric' and 'measurement methodology'. It also discusses the issue of measurement uncertainties and errors as well as introduces the notion of empirically defined metrics and how metrics can be composed.
o 「IPパフォーマンスメトリックのフレームワーク」[RFC2330]は、IPPMワーキンググループによって開発された特定のメトリックの一般的なフレームワークを定義し、「メトリック」および「測定方法論」の基本概念を定義します。また、測定の不確実性とエラーの問題について説明し、経験的に定義されたメトリックの概念と、メトリックの構成方法を紹介します。
o "A One-way Delay Metric for IPPM" [RFC2679] defines a metric for the one-way delay of packets across Internet paths. It builds on notions introduced in the IPPM Framework document.
o 「IPPMの片方向遅延メトリック」[RFC2679]は、インターネットパス間のパケットの片方向遅延のメトリックを定義します。これは、IPPMフレームワークドキュメントで導入された概念に基づいています。
o "A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric for the round-trip delay of packets across network paths and closely follows the corresponding metric for one-way delay.
o 「IPPMの往復遅延メトリック」[RFC2681]は、ネットワークパス間のパケットの往復遅延のメトリックを定義し、一方向遅延の対応するメトリックに厳密に従います。
o "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)" [RFC3393] refers to a metric for variation in the delay of packets across network paths and is based on the difference in the one-way-delay of selected packets called "IP Packet Delay Variation (ipdv)".
o 「IPパフォーマンスメトリック（IPPM）のIPパケット遅延変動メトリック」[RFC3393]は、ネットワークパス間でのパケットの遅延変動のメトリックを参照し、「IP」と呼ばれる選択されたパケットの一方向遅延の差に基づいています。パケット遅延変動（ipdv）」。
o "A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric for one-way packet loss across Internet paths.
o 「IPPMの一方向パケット損失メトリック」[RFC2680]は、インターネットパス全体の一方向パケット損失のメトリックを定義します。
o "A One-Way Packet Duplication Metric" [RFC5560] defines a metric for the case where multiple copies of a packet are received, and it discusses methods to summarize the results of streams.
o 「一方向パケット複製メトリック」[RFC5560]は、パケットの複数のコピーが受信される場合のメトリックを定義し、ストリームの結果を要約する方法について説明します。
o "Packet Reordering Metrics" [RFC4737] defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis and discusses the measurement issues, including the context information required for all metrics.
o 「パケット順序変更メトリクス」[RFC4737]は、ネットワークがパケット単位でパケットの順序を維持しているかどうかを評価するメトリクスを定義し、すべてのメトリクスに必要なコンテキスト情報を含む測定の問題について説明します。
o "IPPM Metrics for Measuring Connectivity" [RFC2678] defines a series of metrics for connectivity between a pair of Internet hosts.
o 「接続を測定するためのIPPMメトリック」[RFC2678]は、インターネットホストのペア間の接続に関する一連のメトリックを定義しています。
o "Framework for Metric Composition" [RFC5835] describes a detailed framework for composing and aggregating metrics.
o 「メトリック構成のフレームワーク」[RFC5835]は、メトリックを構成および集約するための詳細なフレームワークについて説明しています。
o "Guidelines for Considering New Performance Metric Development" [BCP170] describes the framework and process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols.
o 「新しいパフォーマンスメトリックの開発を検討するためのガイドライン」[BCP170]では、IETFで指定されたプロトコルを介して転送されるプロトコルおよびアプリケーションのパフォーマンスメトリックを開発するためのフレームワークとプロセスについて説明します。
To measure these metrics, two protocols and a sampling method have been standardized:
これらの測定基準を測定するために、2つのプロトコルとサンプリング方法が標準化されています。
o "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures unidirectional characteristics such as one-way delay and one-way loss between network devices and enables the interoperability of these measurements. OWAMP is discussed in more detail in [OAM-OVERVIEW].
o 「一方向アクティブ測定プロトコル（OWAMP）」[RFC4656]は、ネットワークデバイス間の一方向遅延や一方向損失などの一方向特性を測定し、これらの測定の相互運用性を実現します。 OWAMPについては、[OAM-OVERVIEW]で詳しく説明しています。
o "A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds round-trip or two-way measurement capabilities to OWAMP. TWAMP is discussed in more detail in [OAM-OVERVIEW].
o 「双方向アクティブ測定プロトコル（TWAMP）」[RFC5357]は、OWAMPに往復または双方向の測定機能を追加します。 TWAMPについては、[OAM-OVERVIEW]で詳しく説明しています。
o "Network performance measurement with periodic streams" [RFC3432] describes a periodic sampling method and relevant metrics for assessing the performance of IP networks, as an alternative to the Poisson sampling method described in [RFC2330].
o 「定期的なストリームによるネットワークパフォーマンス測定」[RFC3432]では、[RFC2330]で説明されているポアソンサンプリング方法の代替として、定期的なサンプリング方法とIPネットワークのパフォーマンスを評価するための関連するメトリックについて説明しています。
For information on MIB modules related to IP Performance Metrics see Section 4.2.4.
IPパフォーマンスメトリックに関連するMIBモジュールについては、セクション4.2.4を参照してください。
"Remote Authentication Dial In User Service (RADIUS)" [RFC2865] describes a client/server protocol for carrying authentication, authorization, and configuration information between a Network Access Server (NAS), which desires to authenticate its links, and a shared authentication server. The companion document "Radius Accounting" [RFC2866] describes a protocol for carrying accounting information between a NAS and a shared accounting server. [RFC2867] adds required new RADIUS accounting attributes and new values designed to support the provision of tunneling in dial-up networks.
「リモート認証ダイヤルインユーザーサービス（RADIUS）」[RFC2865]は、リンクを認証する必要があるネットワークアクセスサーバー（NAS）と共有認証サーバーの間で認証、承認、および構成情報を伝送するためのクライアント/サーバープロトコルについて説明しています。関連ドキュメント「Radius Accounting」[RFC2866]には、NASと共有アカウンティングサーバーの間でアカウンティング情報を伝送するためのプロトコルが記載されています。 [RFC2867]は、必要な新しいRADIUSアカウンティング属性と、ダイヤルアップネットワークでのトンネリングのプロビジョニングをサポートするように設計された新しい値を追加します。
The RADIUS protocol is widely used in environments like enterprise networks, where a single administrative authority manages the network and protects the privacy of user information. RADIUS is deployed in the networks of fixed broadband access provider as well as cellular broadband operators.
RADIUSプロトコルは、単一の管理機関がネットワークを管理し、ユーザー情報のプライバシーを保護する企業ネットワークなどの環境で広く使用されています。 RADIUSは、固定ブロードバンドアクセスプロバイダーのネットワークとセルラーブロードバンドオペレーターに導入されています。
RADIUS uses attributes to carry the specific authentication, authorization, information, and configuration details. RADIUS is extensible with a known limitation of a maximum of 255 attribute codes and 253 octets as attribute content length. RADIUS has Vendor-Specific Attributes (VSAs), which have been used both for vendor-specific purposes (as an addition to standardized attributes) as well as to extend the limited attribute code space.
RADIUSは属性を使用して、特定の認証、承認、情報、および構成の詳細を伝達します。 RADIUSは拡張可能であり、最大255の属性コードと253オクテットの属性コンテンツ長として既知の制限があります。 RADIUSには、ベンダー固有の属性（VSA）があり、ベンダー固有の目的（標準化された属性への追加として）と、限られた属性コードスペースの拡張の両方に使用されています。
The RADIUS protocol uses a shared secret along with the MD5 hash algorithm to secure passwords [RFC1321]. Based on the known threads, additional protection like IPsec tunnels [RFC4301] are used to further protect the RADIUS traffic. However, building and administering large IPsec-protected networks may become a management burden, especially when the IPsec-protected RADIUS infrastructure should provide inter-provider connectivity. Moving towards TLS-based security solutions [RFC5246] and establishing dynamic trust relationships between RADIUS servers has become a trend. Since the introduction of TCP transport for RADIUS [RFC6613], it became natural to have TLS support for RADIUS. An ongoing work is "Transport Layer Security (TLS) encryption for RADIUS" [RFC6614].
RADIUSプロトコルは、MD5ハッシュアルゴリズムと共に共有秘密を使用して、パスワードを保護します[RFC1321]。既知のスレッドに基づいて、IPsecトンネル[RFC4301]のような追加の保護がRADIUSトラフィックをさらに保護するために使用されます。ただし、特にIPsecで保護されたRADIUSインフラストラクチャがプロバイダー間接続を提供する必要がある場合は、大規模なIPsecで保護されたネットワークを構築および管理することが管理上の負担になる可能性があります。 TLSベースのセキュリティソリューション[RFC5246]に移行し、RADIUSサーバー間の動的な信頼関係を確立することがトレンドになっています。 RADIUSのTCPトランスポート[RFC6613]の導入以来、RADIUSのTLSサポートが当たり前になりました。現在進行中の作業は、「RADIUS用のトランスポート層セキュリティ（TLS）暗号化」[RFC6614]です。
"RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a number of RADIUS attributes designed to support the compulsory provision of tunneling in dial-up network access. Some applications involve compulsory tunneling, i.e., the tunnel is created without any action from the user and without allowing the user any choice in the matter. In order to provide this functionality, specific RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points. "Signalling Connection Control Part User Adaptation Layer (SUA)" [RFC3868] defines the necessary attributes, attribute values, and the required IANA registries.
「トンネルプロトコルサポートのRADIUS属性」[RFC2868]は、ダイヤルアップネットワークアクセスでのトンネリングの強制的なプロビジョニングをサポートするように設計された、いくつかのRADIUS属性を定義しています。一部のアプリケーションには強制的なトンネリングが含まれます。つまり、トンネルはユーザーからのアクションなしで作成され、ユーザーが問題を選択することもできません。この機能を提供するには、RADIUSサーバーからトンネルエンドポイントにトンネリング情報を伝送するための特定のRADIUS属性が必要です。 「Signaling Connection Control Part User Adaptation Layer（SUA）」[RFC3868]は、必要な属性、属性値、および必要なIANAレジストリを定義します。
"RADIUS and IPv6" [RFC3162] specifies the operation of RADIUS over IPv6 and the RADIUS attributes used to support the IPv6 network access. "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] describes how to transport delegated IPv6 prefix information over RADIUS.
「RADIUS and IPv6」[RFC3162]は、IPv6上のRADIUSの動作と、IPv6ネットワークアクセスをサポートするために使用されるRADIUS属性を指定します。 「RADIUS Delegated-IPv6-Prefix Attribute」[RFC4818]では、委任されたIPv6プレフィックス情報をRADIUS経由で転送する方法について説明しています。
"RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675] defines additional attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks usable with RADIUS and diameter.
「仮想LANのRADIUS属性と優先度サポート」[RFC4675]は、RADIUSと直径で使用可能なIEEE 802ローカルエリアネットワークへのアクセスのプロビジョニングに使用するための、動的仮想LAN割り当てと優先順位付けの追加属性を定義します。
"Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes" [RFC5080] describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, unclear statements and errors in previous RADIUS specifications are clarified. People designing extensions to RADIUS protocol for various deployment cases should get familiar with "RADIUS Design Guidelines" [RFC6158] in order to avoid, e.g., known interoperability challenges.
「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と推奨される修正」[RFC5080]では、RADIUSの実装に見られる一般的な問題について説明し、いくつかの修正を提案しています。該当する場合は、以前のRADIUS仕様の不明確なステートメントとエラーが明確にされています。さまざまな導入事例向けにRADIUSプロトコルの拡張を設計する人々は、たとえば既知の相互運用性の課題を回避するために、「RADIUS設計ガイドライン」[RFC6158]に精通する必要があります。
"RADIUS Extension for Digest Authentication" [RFC5090] defines an extension to the RADIUS protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP.
「ダイジェスト認証のRADIUS拡張機能」[RFC5090]は、セッション開始プロトコル（SIP）やHTTPなどのHTTPスタイルのプロトコルで使用するために、ダイジェスト認証のサポートを有効にするRADIUSプロトコルの拡張機能を定義します。
"Carrying Location Objects in RADIUS and DIAMETER" [RFC5580] describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in RADIUS and diameter.
「RADIUSとDIAMETERでのロケーションオブジェクトの持ち運び」[RFC5580]は、RADIUSと直径の都市および地理空間ロケーションフォーマットに基づいて、アクセスネットワークの所有権とロケーション情報を伝達する手順を説明しています。
"Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management" [RFC5607] specifies required RADIUS attributes and their values for authorizing a management access to a NAS. Both local and remote management are supported, with access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols, such as SNMP and NETCONF, and for management access over a secure transport protocol.
「ネットワークアクセスサーバー（NAS）管理のためのリモート認証ダイヤルインユーザーサービス（RADIUS）承認」[RFC5607]は、NASへの管理アクセスを承認するために必要なRADIUS属性とその値を指定します。ローカルとリモートの両方の管理がサポートされており、アクセス権と管理権限が付与されています。 SNMPやNETCONFなどのフレーム化された管理プロトコルを介したリモート管理、および安全なトランスポートプロトコルを介した管理アクセスのために、特定のプロビジョニングが行われます。
"RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)" [RFC3579] describes how to use RADIUS to convey an EAP [RFC3748] payload between the authenticator and the EAP server using RADIUS. RFC 3579 is widely implemented, for example, in WLAN and 802.1 X environments. "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines" [RFC3580] describes how to use RADIUS with IEEE 802.1X authenticators. In the context of 802.1X and EAP-based authentication, the VSAs described in [RFC2458] have been widely accepted by the industry. "RADIUS Extensions" [RFC2869] is another important RFC related to EAP use. RFC 2869 describes additional attributes for carrying AAA information between a NAS and a shared accounting server using RADIUS. It also defines attributes to encapsulate EAP message payload.
「拡張認証プロトコル（EAP）のRADIUS（リモート認証ダイヤルインユーザーサービス）サポート」[RFC3579]では、RADIUSを使用して、認証システムとRADIUSを使用するEAPサーバーの間でEAP [RFC3748]ペイロードを伝達する方法について説明しています。 RFC 3579は、WLANおよび802.1 X環境などで広く実装されています。 「IEEE 802.1Xリモート認証ダイヤルインユーザーサービス（RADIUS）使用ガイドライン」[RFC3580]では、IEEE 802.1XオーセンティケーターでRADIUSを使用する方法について説明しています。 802.1XおよびEAPベースの認証のコンテキストでは、[RFC2458]で説明されているVSAは業界で広く受け入れられています。 「RADIUS Extensions」[RFC2869]は、EAPの使用に関連するもう1つの重要なRFCです。 RFC 2869は、RADIUSを使用してNASと共有アカウンティングサーバーの間でAAA情報を伝送するための追加の属性について説明しています。また、EAPメッセージペイロードをカプセル化する属性も定義します。
There are different MIB modules defined for multiple purposes to use with RADIUS (see Sections 4.2.3 and 4.2.5).
RADIUSで使用するために複数の目的で定義されたさまざまなMIBモジュールがあります（セクション4.2.3および4.2.5を参照）。
Diameter [RFC3588] provides an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in local AAA and in roaming scenarios. Diameter provides an upgrade path for RADIUS but is not directly backwards compatible.
Diameter [RFC3588]は、ネットワークアクセスやIPモビリティなどのアプリケーションに認証、認可、アカウンティング（AAA）フレームワークを提供します。 Diameterは、ローカルAAAおよびローミングシナリオで機能することも目的としています。 DiameterはRADIUSのアップグレードパスを提供しますが、直接の下位互換性はありません。
Diameter is designed to resolve a number of known problems with RADIUS. Diameter supports server failover, reliable transport over TCP and SCTP, well-documented functions for proxy, redirect and relay agent functions, server-initiated messages, auditability, and capability negotiation. Diameter also provides a larger attribute space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS. Diameter features make it especially appropriate for environments, where the providers of services are in different administrative domains than the maintainer (protector) of confidential user information.
Diameterは、RADIUSに関するいくつかの既知の問題を解決するように設計されています。 Diameterは、サーバーのフェイルオーバー、TCPおよびSCTPを介した信頼性の高いトランスポート、十分に文書化されたプロキシ機能、リダイレクトおよびリレーエージェント機能、サーバー起動メッセージ、監査機能、機能ネゴシエーションをサポートしています。 Diameterは、RADIUSよりも属性と値のペア（AVP）と識別子に大きな属性スペースも提供します。 Diameter機能は、サービスのプロバイダーが機密のユーザー情報の管理者（保護者）とは異なる管理ドメインにある環境に特に適しています。
Other notable differences to RADIUS are as follows:
RADIUSの他の注目すべき違いは次のとおりです。
o Network and Transport Layer Security (IPsec or TLS),
o ネットワークおよびトランスポート層セキュリティ（IPsecまたはTLS）、
o Stateful and stateless models,
o ステートフルモデルとステートレスモデル
o Dynamic discovery of peers (using DNS Service Record (SRV) and Naming Authority Pointer (NAPTR)),
o ピアの動的検出（DNSサービスレコード（SRV）およびネーミングオーソリティポインター（NAPTR）を使用）、
o Concept of an application that describes how a specific set of commands and Attribute-Value Pairs (AVPs) are treated by diameter nodes. Each application has an IANA-assigned unique identifier,
o 特定のコマンドセットと属性値ペア（AVP）が直径ノードによってどのように処理されるかを説明するアプリケーションの概念。各アプリケーションには、IANAによって割り当てられた一意の識別子があります。
o Support of application layer acknowledgements, failover methods and state machines,
o アプリケーション層の確認、フェイルオーバー方法、および状態マシンのサポート
o Basic support for user-sessions and accounting,
o ユーザーセッションとアカウンティングの基本的なサポート
o Better roaming support,
o より良いローミングのサポート、
o Error notification, and
o エラー通知、および
o Easy extensibility.
o 簡単な拡張性。
The Diameter protocol is designed to be extensible to support, e.g., proxies, brokers, mobility and roaming, Network Access Servers (NASREQ), and Accounting and Resource Management. Diameter applications extend the Diameter base protocol by adding new commands and/or attributes. Each application is defined by a unique IANA-assigned application identifier and can add new command codes and/or new mandatory AVPs.
Diameterプロトコルは、プロキシ、ブローカー、モビリティとローミング、ネットワークアクセスサーバー（NASREQ）、アカウンティングおよびリソース管理などをサポートするように拡張できるように設計されています。 Diameterアプリケーションは、新しいコマンドや属性を追加することにより、Diameter基本プロトコルを拡張します。各アプリケーションは、IANAによって割り当てられた一意のアプリケーション識別子によって定義され、新しいコマンドコードや新しい必須AVPを追加できます。
The Diameter application identifier space has been divided into Standards Track and 'First Come First Served' vendor-specific applications. The following are examples of Diameter applications published at IETF:
Diameterアプリケーション識別子スペースは、標準トラックと「先着順」のベンダー固有のアプリケーションに分割されています。以下は、IETFで公開されているDiameterアプリケーションの例です。
o Diameter Base Protocol Application [RFC3588]: Required support from all Diameter implementations.
o Diameterベースプロトコルアプリケーション[RFC3588]：すべてのDiameter実装からの必須サポート。
o Diameter Base Accounting Application [RFC3588]: A Diameter application using an accounting protocol based on a server-directed model with capabilities for real-time delivery of accounting information.
o Diameterベースアカウンティングアプリケーション[RFC3588]：アカウンティング情報のリアルタイム配信機能を備えたサーバー主導モデルに基づくアカウンティングプロトコルを使用するDiameterアプリケーション。
o Diameter Mobile IPv4 Application [RFC4004]: A Diameter application that allows a Diameter server to authenticate, authorize, and collect accounting information for Mobile IPv4 services rendered to a mobile node.
o DiameterモバイルIPv4アプリケーション[RFC4004]：Diameterサーバーがモバイルノードに提供されるモバイルIPv4サービスの認証情報、認証、およびアカウンティング情報を収集できるようにするDiameterアプリケーション。
o Diameter Network Access Server Application (NASREQ, [RFC4005]): A Diameter application used for AAA services in the NAS environment.
o Diameterネットワークアクセスサーバーアプリケーション（NASREQ、[RFC4005]）：NAS環境でAAAサービスに使用されるDiameterアプリケーション。
o Diameter Extensible Authentication Protocol Application [RFC4072]: A Diameter application that carries EAP packets between a NAS and a back-end authentication server.
o Diameter拡張認証プロトコルアプリケーション[RFC4072]：NASとバックエンド認証サーバーの間でEAPパケットを運ぶDiameterアプリケーション。
o Diameter Credit-Control Application [RFC4006]: A Diameter application that can be used to implement real-time credit-control for a variety of end-user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.
o Diameterクレジット制御アプリケーション[RFC4006]：ネットワークアクセス、セッション開始プロトコル（SIP）サービス、メッセージングサービス、ダウンロードなどのさまざまなエンドユーザーサービスのリアルタイムクレジット制御を実装するために使用できるDiameterアプリケーションサービス。
o Diameter Session Initiation Protocol Application [RFC4740]: A Diameter application designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server.
o Diameterセッション開始プロトコルアプリケーション[RFC4740]：SIPと組み合わせて使用するように設計されたDiameterアプリケーションは、SIPサーバーと同じ場所に配置されたDiameterクライアントに、ユーザーの認証とSIPリソースの使用の承認を要求する機能を提供します。 Diameterサーバー。
o Diameter Quality-of-Service Application [RFC5866]: A Diameter application allowing network elements to interact with Diameter servers when allocating QoS resources in the network.
o Diameterサービス品質アプリケーション[RFC5866]：ネットワークにQoSリソースを割り当てるときに、ネットワーク要素がDiameterサーバーと対話できるようにするDiameterアプリケーション。
o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A Diameter application that enables the interaction between a Mobile IP home agent and a Diameter server and is used when the mobile node is authenticated and authorized using IKEv2 [RFC5996].
o DiameterモバイルIPv6 IKE（MIP6I）アプリケーション[RFC5778]：モバイルIPホームエージェントとDiameterサーバー間の対話を可能にし、IKEv2 [RFC5996]を使用してモバイルノードが認証および承認されるときに使用されるDiameterアプリケーション。
o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A Diameter application that enables the interaction between a Mobile IP home agent and a Diameter server and is used when the mobile node is authenticated and authorized using the Mobile IPv6 Authentication Protocol [RFC4285].
o DiameterモバイルIPv6認証（MIP6A）アプリケーション[RFC5778]：モバイルIPホームエージェントとDiameterサーバー間の対話を可能にし、モバイルノードがモバイルIPv6認証プロトコル[RFC4285]を使用して認証および承認されるときに使用されるDiameterアプリケーション。
The large majority of Diameter applications are vendor-specific and mainly used in various SDOs outside the IETF. One example SDO using diameter extensively is 3GPP (e.g., 3GPP 'IP Multimedia Subsystem' (IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]). Recently, during the standardization of the '3GPP Evolved Packet Core' [3GPPEPC], diameter was chosen as the only AAA signaling protocol.
Diameterアプリケーションの大多数はベンダー固有であり、主にIETF以外のさまざまなSDOで使用されます。直径を広範囲に使用するSDOの1つの例は3GPPです（たとえば、3GPP 'IP Multimedia Subsystem'（IMS）は直径ベースのインターフェース（Cxなど）を使用します[3GPPIMS]）。最近、「3GPP Evolved Packet Core」[3GPPEPC]の標準化中に、唯一のAAAシグナリングプロトコルとして直径が選択されました。
One part of diameter's extensibility mechanism is an easy and consistent way of creating new commands for the need of applications. RFC 3588 proposed to define diameter command code allocations with a new RFC. This policy decision caused undesired use and redefinition of existing command codes within SDOs. Diverse RFCs have been published as simple command code allocations for other SDO purposes (see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]). [RFC5719] changed the command code policy and added a range for vendor-specific command codes to be allocated on a 'First Come First Served' basis by IANA.
直径の拡張メカニズムの一部は、アプリケーションの必要性に応じて新しいコマンドを作成する簡単で一貫した方法です。 RFC 3588は、新しいRFCで直径コマンドコード割り当てを定義することを提案しました。このポリシーの決定により、SDO内の既存のコマンドコードの望ましくない使用と再定義が発生しました。さまざまなRFCが、他のSDO目的のための単純なコマンドコード割り当てとして公開されています（[RFC3589]、[RFC5224]、[RFC5431]、および[RFC5516]を参照）。 [RFC5719]はコマンドコードポリシーを変更し、ベンダー固有のコマンドコードの範囲を追加して、IANAによって「先着順」で割り当てられるようにしました。
The implementation and deployment experience of diameter has led to the ongoing development of an update of the base protocol [DIAMETER], which introduces TLS as the preferred security mechanism and deprecates the in-band security negotiation for TLS.
Diameterの実装と展開の経験により、基本プロトコル[DIAMETER]の更新が継続的に開発され、推奨されるセキュリティメカニズムとしてTLSが導入され、TLSのインバンドセキュリティネゴシエーションが廃止されました。
Some Diameter protocol enhancements and clarifications that logically fit better into [DIAMETER], are also needed on the existing deployments based on RFC 3588. Therefore, protocol extensions specifically usable in large inter-provider roaming network scenarios are made available for RFC 3588. Two currently existing specifications are mentioned below:
[DIAMETER]に論理的に適合するいくつかのDiameterプロトコルの機能強化と説明も、RFC 3588に基づく既存の展開で必要です。したがって、大規模なプロバイダー間ローミングネットワークシナリオで特に使用可能なプロトコル拡張機能がRFC 3588で利用可能になります。現在2つ既存の仕様は次のとおりです。
o "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm" [RFC5729] defines the behavior required for Diameter agents to route requests when the User-Name AVP contains a NAI formatted with multiple realms. These multi-realm Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms.
o 「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」[RFC5729]は、ユーザー名AVPに複数のレルムでフォーマットされたNAIが含まれている場合に、Diameterエージェントがリクエストをルーティングするために必要な動作を定義します。これらのマルチレルムネットワークアクセス識別子は、仲介レルムの事前定義されたリストを介して要求メッセージのルーティングを強制するために使用されます。
o "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage" [RFC6408] describes an improved DNS-based dynamic Diameter agent discovery mechanism without having to do diameter capability exchange beforehand with a number of agents.
o 「Diameter Straightforward-Naming Authority Pointer（S-NAPTR）Usage」[RFC6408]は、多数のエージェントと事前にDiameter機能を交換する必要がない、改良されたDNSベースの動的Diameterエージェント検出メカニズムを説明しています。
There have been a growing number of Diameter Framework documents from the IETF that basically are just a collection of AVPs for a specific purpose or a system architecture with semantic AVP descriptions and a logic for "imaginary" applications. From a standardization point of view, this practice allows the development of larger system architecture documents that do not need to reference AVPs or application logic outside the IETF. Below are examples of a few recent AVP and Framework documents: o "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" [RFC5447] describes the bootstrapping of the Mobile IPv6 framework and the support of interworking with existing AAA infrastructures by using the diameter NAS-to-home-AAA server interface.
IETFから、基本的に特定の目的のAVPのコレクション、またはセマンティックAVP記述と「架空の」アプリケーションのロジックを備えたシステムアーキテクチャであるDiameterフレームワークドキュメントが増えています。標準化の観点から見ると、この手法により、IETFの外部のAVPやアプリケーションロジックを参照する必要のない、より大きなシステムアーキテクチャドキュメントの開発が可能になります。以下は、最近のいくつかのAVPおよびフレームワークドキュメントの例です。o「DiameterモバイルIPv6：ネットワークアクセスサーバーとDiameterサーバーの相互作用のサポート」[RFC5447]は、モバイルIPv6フレームワークのブートストラップと、既存のAAAインフラストラクチャとのインターワークのサポートについて説明しています。直径NASからホームAAAサーバーへのインターフェース。
o "Traffic Classification and Quality of Service (QoS) Attributes for Diameter" [RFC5777] defines a number of Diameter AVPs for traffic classification with actions for filtering and QoS treatment.
o 「Diameterのトラフィック分類とサービス品質（QoS）属性」[RFC5777]は、フィルタリングとQoS処理のアクションを備えたトラフィック分類用のいくつかのDiameter AVPを定義しています。
o "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server" [RFC5779] defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) entities (MAG and LMA) and a AAA server within a PMIPv6 Domain.
o 「DiameterプロキシモバイルIPv6：モバイルアクセスゲートウェイとDiameterサーバーとのローカルモビリティアンカーの相互作用」[RFC5779]は、プロキシモバイルIPv6（PMIPv6）エンティティ（MAGおよびLMA）とPMIPv6ドメイン内のAAAサーバー間のAAA相互作用を定義します。
For information on MIB modules related to diameter, see Section 4.2.5.
直径に関連するMIBモジュールについては、4.2.5項を参照してください。
Wireless LAN (WLAN) product architectures have evolved from single autonomous Access Points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller, where an Access Point pulls the information from the AC.
ワイヤレスLAN（WLAN）製品のアーキテクチャは、単一の自律アクセスポイントから、集中型アクセスコントローラー（AC）とワイヤレスターミネーションポイント（WTP）で構成されるシステムに進化しました。集中制御アーキテクチャの一般的な目標は、ユーザー認証と承認、モビリティ管理、無線管理を含むアクセス制御を、単一のアクセスポイントから、アクセスポイントがACから情報を引き出す集中コントローラに移動することです。
Based on "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4118], the CAPWAP working group developed the CAPWAP protocol [RFC5415] to facilitate control, management, and provisioning of WTPs specifying the services, functions, and resources relating to 802.11 WLAN Termination Points in order to allow for interoperable implementations of WTPs and ACs. The protocol defines the CAPWAP control plane, including the primitives to control data access. The protocol document also specifies how configuration management of WTPs can be done and defines CAPWAP operations responsible for debugging, gathering statistics, logging, and managing firmware as well as discusses operational and transport considerations.
CAPWAPワーキンググループは、「ワイヤレスアクセスポイントの制御とプロビジョニングのためのアーキテクチャ分類法（CAPWAP）」[RFC4118]に基づいて、サービス、機能、およびリソースを指定するWTPの制御、管理、プロビジョニングを容易にするCAPWAPプロトコル[RFC5415]を開発しました。 WTPとACの相互運用可能な実装を可能にするための802.11 WLANターミネーションポイントに関連します。プロトコルは、データアクセスを制御するプリミティブを含むCAPWAPコントロールプレーンを定義します。プロトコルドキュメントは、WTPの構成管理を行う方法を指定し、デバッグ、統計の収集、ロギング、およびファームウェアの管理を担当するCAPWAP操作を定義し、操作とトランスポートの考慮事項について説明します。
The CAPWAP protocol is prepared to be independent of Layer 2 technologies, and meets the objectives in "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate binding extensions enable the use with additional wireless technologies. [RFC5416] defines the CAPWAP Protocol Binding for IEEE 802.11.
CAPWAPプロトコルは、レイヤー2テクノロジーから独立するように準備されており、「ワイヤレスアクセスポイントの制御とプロビジョニング（CAPWAP）の目的」[RFC4564]の目的を満たしています。個別のバインディング拡張により、追加のワイヤレステクノロジーを使用できます。 [RFC5416]は、IEEE 802.11のCAPWAPプロトコルバインディングを定義しています。
CAPWAP Control messages, and optionally CAPWAP Data messages, are secured using DTLS [RFC6347]. DTLS is used as a tightly integrated, secure wrapper for the CAPWAP protocol.
CAPWAP制御メッセージ、およびオプションでCAPWAPデータメッセージは、DTLS [RFC6347]を使用して保護されます。 DTLSは、CAPWAPプロトコルの緊密に統合された安全なラッパーとして使用されます。
For information on MIB modules related to CAPWAP, see Section 4.2.2.
CAPWAPに関連するMIBモジュールについては、セクション4.2.2を参照してください。
The Access Node Control Protocol (ANCP) [RFC6320] realizes a control plane between a service-oriented Layer 3 edge device, the NAS and a Layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module (DSLAM). As such, ANCP operates in a multi-service reference architecture and communicates QoS-, service-, and subscriber-related configuration and operation information between a NAS and an AN.
アクセスノードコントロールプロトコル（ANCP）[RFC6320]は、サービス指向のレイヤー3エッジデバイス、NASとレイヤー2アクセスノード（AN）、たとえばデジタル加入者線アクセスモジュール（DSLAM）間のコントロールプレーンを実現します。そのため、ANCPはマルチサービスリファレンスアーキテクチャで動作し、NASとANの間でQoS、サービス、および加入者関連の構成と動作の情報を通信します。
The main goal of this protocol is to configure and manage access equipment and allow them to report information to the NAS in order to enable and optimize configuration.
このプロトコルの主な目的は、アクセス機器を構成および管理し、構成を有効にして最適化するために、NASに情報を報告できるようにすることです。
The framework and requirements for an AN control mechanism and the use cases for ANCP are documented in [RFC5851].
AN制御メカニズムのフレームワークと要件、およびANCPの使用例は、[RFC5851]に文書化されています。
ANCP offers authentication and authorization between AN and NAS nodes and provides replay protection and data-origin authentication. The ANCP solution is also robust against Denial-of-Service (DoS) attacks. Furthermore, the ANCP solution is recommended to offer confidentiality protection. Security Threats and Security Requirements for ANCP are discussed in [RFC5713].
ANCPは、ANノードとNASノード間の認証と承認を提供し、再生保護とデータ発信元認証を提供します。 ANCPソリューションは、サービス拒否（DoS）攻撃に対しても堅牢です。さらに、ANCPソリューションは機密保護を提供するために推奨されます。 ANCPのセキュリティ脅威とセキュリティ要件は、[RFC5713]で説明されています。
The Application Configuration Access Protocol (ACAP) [RFC2244] is designed to support remote storage and access of program option, configuration, and preference information. The datastore model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server reconfiguration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance", which can be used to manage default values for configuration settings and access control lists that allow interesting personal information to be shared and group information to be restricted.
アプリケーション構成アクセスプロトコル（ACAP）[RFC2244]は、リモートストレージとプログラムオプション、構成、および設定情報へのアクセスをサポートするように設計されています。データストアモデルは、クライアントが関心のあるデータに比較的簡単にアクセスできるようにし、サーバーを再構成せずに新しい情報を簡単に追加できるようにし、標準化されたデータとカスタムデータまたは専用データの両方の使用を促進するように設計されています。主な機能には「継承」が含まれ、これを使用して構成設定のデフォルト値とアクセス制御リストを管理し、興味深い個人情報を共有したりグループ情報を制限したりできます。
ACAP's primary purpose is to allow applications access to their configuration data from multiple network-connected computers. Users can then use any network-connected computer, run any ACAP-enabled application, and have access to their own configuration data. To enable wide usage client simplicity has been preferred to server or protocol simplicity whenever reasonable.
ACAPの主な目的は、ネットワークに接続された複数のコンピューターからアプリケーションが構成データにアクセスできるようにすることです。ユーザーは、ネットワークに接続されたコンピュータを使用し、ACAP対応のアプリケーションを実行し、独自の構成データにアクセスできます。幅広い用途を可能にするために、合理的な場合は常に、サーバーまたはプロトコルの単純化よりもクライアントの単純化が好まれてきました。
The ACAP 'authenticate' command uses Simple Authentication and Security Layer (SASL) [RFC4422] to provide basic authentication, authorization, integrity, and privacy services. All ACAP implementations are required to implement the CRAM-MD5 (Challenge-Response Authentication Mechanism) [RFC2195] for authentication, which can be disabled based on the site security policy.
ACAPの「authenticate」コマンドは、Simple Authentication and Security Layer（SASL）[RFC4422]を使用して、基本的な認証、承認、整合性、およびプライバシーサービスを提供します。すべてのACAP実装は、認証のためにCRAM-MD5（チャレンジ-レスポンス認証メカニズム）[RFC2195]を実装する必要があり、サイトのセキュリティポリシーに基づいて無効にすることができます。
The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] has been designed for and is commonly used with SIP-based solutions, in particular, for instant messages, presence, and SIP conferences. XCAP is a protocol that allows a client to read, write, and modify application configuration data stored in XML format on a server, where the main functionality is provided by so-called "XCAP Application Usages".
拡張マークアップ言語（XML）構成アクセスプロトコル（XCAP）[RFC4825]は、特にインスタントメッセージ、プレゼンス、SIP会議用に設計され、SIPベースのソリューションで一般的に使用されています。 XCAPは、クライアントがサーバー上にXML形式で保存されているアプリケーション構成データの読み取り、書き込み、および変更を可能にするプロトコルであり、主な機能は、いわゆる「XCAPアプリケーション使用法」によって提供されます。
XCAP is a protocol that can be used to manipulate per-user data. XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. Like ACAP, XCAP supports the configuration needs for a multiplicity of applications.
XCAPは、ユーザーごとのデータを操作するために使用できるプロトコルです。 XCAPは、XMLドキュメントとドキュメントコンポーネントをHTTP URIにマッピングするための一連の規則、1つのリソースの変更が別のリソースにどのように影響するかに関するルール、データ検証の制約、およびそれらのリソースへのアクセスに関連付けられた承認ポリシーです。この構造のため、通常のHTTPプリミティブを使用してデータを操作できます。 ACAPと同様に、XCAPは多数のアプリケーションの構成ニーズをサポートします。
All XCAP servers are required to implement HTTP Digest Authentication [RFC2617]. Furthermore, XCAP servers are required to implement HTTP over TLS (HTTPS) [RFC2818]. It is recommended that administrators use an HTTPS URI as the XCAP root URI, so that the digest client authentication occurs over TLS.
HTTPダイジェスト認証[RFC2617]を実装するには、すべてのXCAPサーバーが必要です。さらに、XCAPサーバーはHTTP over TLS（HTTPS）[RFC2818]を実装する必要があります。 TLSを介してダイジェストクライアント認証が行われるように、管理者はXCAPルートURIとしてHTTPS URIを使用することをお勧めします。
The following list summarizes important XCAP application usages:
以下のリストは、XCAPアプリケーションの重要な使用法をまとめたものです。
o XCAP server capabilities [RFC4825] can be read by clients to determine which extensions, application usages, or namespaces a server supports.
o クライアントがXCAPサーバー機能[RFC4825]を読み取って、サーバーがサポートする拡張機能、アプリケーションの使用法、または名前空間を判別できます。
o A resource lists application is any application that needs access to a list of resources, identified by a URI, to which operations, such as subscriptions, can be applied [RFC4826].
o リソースリストアプリケーションは、サブスクリプションなどの操作を適用できる、URIで識別されるリソースのリストにアクセスする必要のあるアプリケーションです[RFC4826]。
o A Resource List Server (RLS) Services application is a SIP application, where a server receives SIP SUBSCRIBE requests for resources and generates subscriptions towards the resource list [RFC4826].
o リソースリストサーバー（RLS）サービスアプリケーションはSIPアプリケーションであり、サーバーはリソースに対するSIP SUBSCRIBE要求を受信し、リソースリスト[RFC4826]へのサブスクリプションを生成します。
o A Presence Rules application uses authorization policies, also known as authorization rules, to specify what presence information can be given to which watchers, and when [RFC4827].
o プレゼンスルールアプリケーションは、承認ポリシーとも呼ばれる承認ポリシーを使用して、どのウォッチャーにいつどのプレゼンス情報を提供できるかを指定します[RFC4827]。
o A 'pidf-manipulation' application defines how XCAP is used to manipulate the contents of PIDF-based presence documents [RFC4827].
o 「pidf-manipulation」アプリケーションは、XCAPを使用してPIDFベースのプレゼンスドキュメントのコンテンツを操作する方法を定義します[RFC4827]。
This section provides two complementary overviews for the network management data models standardized at IETF. The first subsection focuses on a broader view of models classified into categories such as generic and infrastructure data models as well as data models matched to different layers. The second subsection is structured following the management application view and focuses mainly on the data models for the network management tasks fault, configuration, accounting, performance, and security management (see [FCAPS]).
このセクションでは、IETFで標準化されたネットワーク管理データモデルの2つの補足的な概要を示します。最初のサブセクションでは、ジェネリックデータモデルやインフラストラクチャデータモデルなどのカテゴリに分類されたモデルと、さまざまなレイヤーに一致するデータモデルの幅広いビューに焦点を当てています。 2番目のサブセクションは、管理アプリケーションビューに従って構成され、主にネットワーク管理タスクの障害、構成、アカウンティング、パフォーマンス、およびセキュリティ管理のデータモデルに焦点を当てています（[FCAPS]を参照）。
Note that the IETF does not use the FCAPS view as an organizing principle for its data models. However, the FCAPS view is used widely outside of the IETF for the realization of management tasks and applications. Section 4.2 aims to address the FCAPS view to enable people outside of the IETF to understand the relevant data models in the IETF.
IETFはFCAPSビューをそのデータモデルの編成原則として使用しないことに注意してください。ただし、FCAPSビューは、管理タスクとアプリケーションの実現のために、IETFの外部で広く使用されています。セクション4.2は、FCAPSビューに対処して、IETFの外部の人々がIETFの関連データモデルを理解できるようにすることを目的としています。
The different data models covered in this section are MIB modules, IPFIX Information Elements, Syslog Structured Data Elements, and YANG modules. There are many technology-specific IETF data models, such as transmission and protocol MIBs, which are not mentioned in this document and can be found at [RFCSEARCH].
このセクションで説明するさまざまなデータモデルは、MIBモジュール、IPFIX情報要素、Syslog構造化データ要素、およびYANGモジュールです。このドキュメントには記載されておらず、[RFCSEARCH]に記載されている、伝送MIBやプロトコルMIBなど、多くの技術固有のIETFデータモデルがあります。
This section gives an overview of management data models that have reached Draft or Proposed Standard status at the IETF. In exceptional cases, important Informational RFCs are referenced. The advancement process for management data models beyond Proposed Standard status, has been defined in [BCP027] with a more pragmatic approach and special considerations on data model specification interoperability. However, most IETF management data models never advanced beyond Proposed Standard.
このセクションでは、IETFでドラフトまたは提案された標準ステータスに達した管理データモデルの概要を示します。例外的なケースでは、重要な情報RFCが参照されます。 [BCP027]では、データモデル仕様の相互運用性に関するより実用的なアプローチと特別な考慮事項により、Proposed Standardステータスを超える管理データモデルの高度化プロセスが定義されています。ただし、ほとんどのIETF管理データモデルは、提案された標準を超えることはありません。
The data models defined by the IETF can be broadly classified into the following categories depicted in Figure 1.
IETFによって定義されたデータモデルは、図1に示す次のカテゴリに大きく分類できます。
+-----------+ +-------------------------------+ +-----------+
| | | application-layer data models | | network |
| generic | +-------------------------------+ | management|
| infra- | | transport-layer data models | | infra- |
| structure | +-------------------------------+ | structure |
| data | | network-layer data models | | data |
| models | +-------------------------------+ | models |
| | | link-layer data models | | |
+-----------+ +-------------------------------+ +-----------+
Figure 1: Categories of Network Management Data Models
図1：ネットワーク管理データモデルのカテゴリ
Each of the categories is briefly described below. Note that the classification used here is intended to provide orientation and reflects how most data models have been developed in the IETF by the various working groups. This classification does not aim to classify correctly all data models that have been defined by the IETF so far. The network layering model in the middle of Figure 1 follows the four-layer model of the Internet as defined in [RFC1021].
各カテゴリについて、以下で簡単に説明します。ここで使用する分類は、方向付けを提供することを目的としており、さまざまなワーキンググループによってIETFでほとんどのデータモデルがどのように開発されたかを反映していることに注意してください。この分類は、これまでにIETFによって定義されたすべてのデータモデルを正しく分類することを目的としたものではありません。図1の中央にあるネットワークレイヤーモデルは、[RFC1021]で定義されているインターネットの4レイヤーモデルに従います。
The network management object identifiers for use with IETF MIB modules defined in the IETF can be found under the IANA registry at [SMI-NUMBERS].
IETFで定義されたIETF MIBモジュールで使用するネットワーク管理オブジェクト識別子は、[SMI-NUMBERS]のIANAレジストリの下にあります。
Generic infrastructure data models provide core abstractions that many other data models are built upon. The most important example is the interfaces data model defined in the IF-MIB [RFC2863]. It provides the basic notion of network interfaces and allows expressing stacking/layering relationships between interfaces. The interfaces data model also provides basic monitoring objects that are widely used for performance and fault management.
ジェネリックインフラストラクチャデータモデルは、他の多くのデータモデルが構築されているコアな抽象化を提供します。最も重要な例は、IF-MIB [RFC2863]で定義されているインターフェイスデータモデルです。これは、ネットワークインターフェイスの基本的な概念を提供し、インターフェイス間のスタッキング/レイヤー関係を表すことができます。インターフェースデータモデルは、パフォーマンスと障害管理に広く使用されている基本的な監視オブジェクトも提供します。
The second important infrastructure data model is defined in the Entity MIB [RFC4133]. It exports the containment hierarchy of the physical entities (slots, modules, ports) that make up a networking device and, as such, it is a key data model for inventory management. Physical entities can have pointers to other data models that provide more specific information about them (e.g., physical ports usually point to the related network interface). Entity MIB extensions exist for physical sensors such as temperature sensors embedded on line cards or sensors that report fan rotation speeds [RFC3433]. The Entity State MIB [RFC4268] models states and alarms of physical entities. Some vendors have extended the basic Entity MIB with several proprietary data models.
2番目の重要なインフラストラクチャデータモデルは、エンティティMIB [RFC4133]で定義されています。ネットワーキングデバイスを構成する物理エンティティ（スロット、モジュール、ポート）の包含階層をエクスポートするため、在庫管理の重要なデータモデルです。物理エンティティは、それらに関するより具体的な情報を提供する他のデータモデルへのポインターを持つことができます（たとえば、物理ポートは通常、関連するネットワークインターフェイスを指します）。エンティティMIB拡張は、ラインカードに埋め込まれた温度センサーやファンの回転速度を報告するセンサーなどの物理センサー用に存在します[RFC3433]。エンティティ状態MIB [RFC4268]は、物理エンティティの状態とアラームをモデル化します。一部のベンダーは、いくつかの独自のデータモデルで基本エンティティMIBを拡張しています。
A number of data models exist in the form of MIB modules covering the link layers IP runs over, such as Asymmetric Bit-Rate DSL (ADSL) [RFC4706], Very high bit-rate Digital Subscriber Line (VDSL) [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515] [RFC3606], Cable Modems [RFC4546], or Ethernet [RFC4188] [RFC4318] [RFC4363]. These so-called transmission data models typically extend the generic network interfaces data model with interface type specific information. Most of the link-layer data models focus on monitoring capabilities that can be used for performance and fault management functions and, to some lesser extent, for accounting and security management functions. Meanwhile, the IEEE has taken over the responsibility to maintain and further develop data models for the IEEE 802 family of protocols [RFC4663]. The cable modem industry consortium DOCSIS is working with the IETF to publish data models for cable modem networks as IETF Standards Track specifications.
非対称ビットレートDSL（ADSL）[RFC4706]、超高ビットレートデジタル加入者線（VDSL）[RFC5650]、GMPLSなど、IPがリンクリンク層をカバーするMIBモジュールの形式で存在する多くのデータモデル[RFC4803]、ISDN [RFC2127]、ATM [RFC2515] [RFC3606]、ケーブルモデム[RFC4546]、またはイーサネット[RFC4188] [RFC4318] [RFC4363]。これらのいわゆる伝送データモデルは、通常、一般的なネットワークインターフェイスデータモデルを、インターフェイスタイプ固有の情報で拡張します。ほとんどのリンク層データモデルは、パフォーマンスおよび障害管理機能に使用できる監視機能に焦点を当てていますが、ある程度は、アカウンティングおよびセキュリティ管理機能にも使用できます。一方、IEEEは、IEEE 802ファミリのプロトコル[RFC4663]のデータモデルを維持し、さらに開発する責任を引き継ぎました。ケーブルモデム業界コンソーシアムDOCSISは、IETFと協力して、ケーブルモデムネットワークのデータモデルをIETF標準トラック仕様として公開しています。
There are data models in the form of MIB modules covering IP/ICMP [RFC4293] [RFC4292] network protocols and their extensions (e.g., Mobile IP), the core protocols of the Internet. In addition, there are data models covering popular unicast routing protocols (OSPF [RFC4750], IS-IS [RFC4444], BGP-4 [RFC4273]) and multicast routing protocols (PIM [RFC5060]).
IP / ICMP [RFC4293] [RFC4292]ネットワークプロトコルとその拡張（モバイルIPなど）をカバーするMIBモジュールの形式のデータモデルがあり、これはインターネットのコアプロトコルです。さらに、一般的なユニキャストルーティングプロトコル（OSPF [RFC4750]、IS-IS [RFC4444]、BGP-4 [RFC4273]）およびマルチキャストルーティングプロトコル（PIM [RFC5060]）をカバーするデータモデルがあります。
Detailed models also exist for performance measurements in the form of IP Performance Metrics [RFC2330] (see Section 3.4).
IPパフォーマンスメトリック[RFC2330]（セクション3.4を参照）の形でパフォーマンス測定用の詳細なモデルも存在します。
The necessary data model infrastructure for configuration data models covering network layers are currently being defined using NETCONF [RFC6242] and YANG [RFC6020].
ネットワーク層をカバーする構成データモデルに必要なデータモデルインフラストラクチャは、現在NETCONF [RFC6242]およびYANG [RFC6020]を使用して定義されています。
There are data models for the transport protocols TCP [RFC4022], UDP [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing extended statistics is defined in [RFC4898].
トランスポートプロトコルには、TCP [RFC4022]、UDP [RFC4113]、SCTP [RFC3873]のデータモデルがあります。 TCPの場合、拡張統計を提供するデータモデルは[RFC4898]で定義されています。
Some data models have been developed for specific application protocols (e.g., SIP [RFC4780]). In addition, there are data models that provide a generic infrastructure for instrumenting applications in order to obtain data useful primarily for performance management and fault management [RFC2287] [RFC2564]. In general, however, generic application MIB modules have been less successful in gaining widespread deployment.
一部のデータモデルは、特定のアプリケーションプロトコル（SIP [RFC4780]など）用に開発されています。さらに、主にパフォーマンス管理と障害管理に役立つデータを取得するために、アプリケーションを計測するための一般的なインフラストラクチャを提供するデータモデルがあります[RFC2287] [RFC2564]。ただし、一般的に、一般的なアプリケーションMIBモジュールは、広範な展開を実現するのにあまり成功していません。
A number of data models are concerned with the network management system itself. This includes, in addition to a set of SNMP MIB modules for monitoring and configuring SNMP itself [RFC3410], some MIB modules providing generic functions such as the calculation of expressions over MIB objects, generic functions for thresholding and event generation, event notification logging functions, and data models to represent alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877].
多くのデータモデルがネットワーク管理システム自体に関係しています。これには、SNMP自体を監視および構成するための一連のSNMP MIBモジュール[RFC3410]に加えて、MIBオブジェクトに対する式の計算、しきい値処理とイベント生成のための一般的な機能、イベント通知ロギング機能などの一般的な機能を提供する一部のMIBモジュールが含まれます、およびアラームを表すデータモデル[RFC2981] [RFC2982] [RFC3014] [RFC3877]。
In addition, there are data models that allow the execution of basic reachability and path discovery tests [RFC4560]. Another collection of MIB modules provides remote monitoring functions, ranging from the data link layer up to the application layer. This is known as the "RMON family of MIB modules" [RFC3577].
さらに、基本的な到達可能性とパス検出テストの実行を可能にするデータモデルがあります[RFC4560]。 MIBモジュールの別のコレクションは、データリンク層からアプリケーション層までの範囲のリモート監視機能を提供します。これは「MIBモジュールのRMONファミリ」[RFC3577]として知られています。
The IPFIX Protocol [RFC5101] (Section 2.3) is used to export information about network flows collected at so-called Observation Points (typically, a network interface). The IEs [RFC5102] carried in IPFIX cover the majority of the network and transport layer header fields and a few link-layer-specific fields. Work is underway to further extend the standardized information that can be carried in IPFIX.
IPFIXプロトコル[RFC5101]（セクション2.3）は、いわゆる観測ポイント（通常、ネットワークインターフェイス）で収集されたネットワークフローに関する情報をエクスポートするために使用されます。 IPFIXで運ばれるIE [RFC5102]は、ネットワークとトランスポート層のヘッダーフィールドの大部分と、いくつかのリンク層固有のフィールドをカバーしています。 IPFIXで伝送できる標準化された情報をさらに拡張する作業が進行中です。
The Syslog Protocol document [RFC5424] (Section 2.2) defines an initial set of Structured Data Elements (SDEs) that relate to content time quality, content origin, and meta-information about the message, such as language. Proprietary SDEs can be used to supplement the IETF-defined SDEs.
Syslogプロトコルドキュメント[RFC5424]（セクション2.2）は、コンテンツの時間品質、コンテンツの起源、および言語などのメッセージに関するメタ情報に関連する構造化データ要素（SDE）の初期セットを定義しています。独自のSDEを使用して、IETF定義のSDEを補足できます。
This subsection follows the management application view and aims to match the data models to network management tasks for fault, configuration, accounting, performance, and security management ([FCAPS]). As OAM is a general term that refers to a toolset, which can be used for fault detection, isolation, and performance measurement, aspects of FCAPS in the context of the data path, such as fault and performance management, are also discussed in "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms" [OAM-OVERVIEW].
このサブセクションは、管理アプリケーションビューに従い、障害、構成、アカウンティング、パフォーマンス、およびセキュリティ管理（[FCAPS]）のネットワーク管理タスクにデータモデルを一致させることを目的としています。 OAMはツールセットを指す一般的な用語であり、障害の検出、分離、およびパフォーマンス測定に使用できるため、障害やパフォーマンス管理などのデータパスのコンテキストにおけるFCAPSの側面についても説明されています。運用、管理、保守（OAM）メカニズムの概要」[OAM-OVERVIEW]。
Some of the data models do not fit into one single FCAPS category per design but span multiple areas. For example, there are many technology-specific IETF data models, such as transmission and protocol MIBs, which cover multiple FCAPS categories, and therefore are not mentioned in this subsection and can be found at [RFCSEARCH].
一部のデータモデルは、設計ごとに1つのFCAPSカテゴリに収まらず、複数の領域にまたがっています。たとえば、複数のFCAPSカテゴリをカバーする伝送MIBやプロトコルMIBなど、多くの技術固有のIETFデータモデルがあるため、このサブセクションでは言及されておらず、[RFCSEARCH]で見つけることができます。
Fault management encloses a set of functions to detect, isolate, notify, and correct faults encountered in a network as well as to maintain and examine error logs. The data models below can be utilized to realize a fault management application.
障害管理は、ネットワークで発生した障害を検出、分離、通知、および修正するだけでなく、エラーログを維持および調査するための一連の機能を含んでいます。以下のデータモデルを利用して、障害管理アプリケーションを実現できます。
[RFC3418], part of SNMPv3 standard [STD62], is a MIB module containing objects in the system group that are often polled to determine if a device is still operating, and sysUpTime can be used to detect if the network management portion of the system has restarted and counters have been re-initialized.
SNMPv3標準[STD62]の一部である[RFC3418]は、デバイスがまだ動作しているかどうかを確認するために頻繁にポーリングされるシステムグループ内のオブジェクトを含むMIBモジュールであり、sysUpTimeを使用してシステムのネットワーク管理部分を検出できますが再起動し、カウンタが再初期化されました。
[RFC3413], part of SNMPv3 standard [STD62], is a MIB module including objects designed for managing notifications, including tables for addressing, retry parameters, security, lists of targets for notifications, and user customization filters.
SNMPv3標準[STD62]の一部である[RFC3413]は、アドレス指定用のテーブル、再試行パラメーター、セキュリティ、通知のターゲットのリスト、ユーザーカスタマイズフィルターなど、通知を管理するために設計されたオブジェクトを含むMIBモジュールです。
The Interfaces Group MIB [RFC2863] builds on the old standard for MIB II [STD17] and is used as a primary MIB module for managing and monitoring the status of network interfaces. The Interfaces Group MIB defines a generic set of managed objects for network interfaces, and it provides the infrastructure for additional managed objects specific to particular types of network interfaces, such as Ethernet.
インターフェイスグループMIB [RFC2863]は、MIB II [STD17]の古い標準に基づいて構築されており、ネットワークインターフェイスのステータスを管理および監視するためのプライマリMIBモジュールとして使用されます。インターフェイスグループMIBは、ネットワークインターフェイスの管理対象オブジェクトの一般的なセットを定義し、イーサネットなどの特定のタイプのネットワークインターフェイスに固有の追加の管理対象オブジェクトのインフラストラクチャを提供します。
[RFC4560] defines a MIB module for performing ping, traceroute, and lookup operations at a host. For troubleshooting purposes, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host.
[RFC4560]は、ホストでping、traceroute、および検索操作を実行するためのMIBモジュールを定義します。トラブルシューティングの目的で、リモートホストで実行されたpingまたはtraceroute操作の結果を開始および取得できると便利です。
The RMON (Remote Network Monitoring) MIB [STD59] can be configured to recognize conditions on existing MIB variables (most notably error conditions) and continuously check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways (for further discussion on RMON, see Section 4.2.4).
RMON（リモートネットワークモニタリング）MIB [STD59]は、既存のMIB変数の条件（特にエラー条件）を認識し、それらを継続的にチェックするように構成できます。これらの条件のいずれかが発生すると、イベントがログに記録され、管理ステーションにさまざまな方法で通知されます（RMONの詳細については、セクション4.2.4を参照）。
DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] provide a superset of the capabilities of the RMON alarm and event groups. These modules provide mechanisms for thresholding and reporting anomalous events to management applications.
[RFC2981]のDISMAN-EVENT-MIBと[RFC2982]のDISMAN-EXPRESSION-MIBは、RMONアラームとイベントグループの機能のスーパーセットを提供します。これらのモジュールは、異常イベントをしきい値処理および管理アプリケーションに報告するメカニズムを提供します。
The Alarm MIB in [RFC3877] and the Alarm Reporting Control MIB in [RFC3878] specify mechanisms for expressing state transition models for persistent problem states. Alarm MIB defines the following:
[RFC3877]のアラームMIBと[RFC3878]のアラームレポート制御MIBは、永続的な問題状態の状態遷移モデルを表現するためのメカニズムを指定します。アラームMIBは以下を定義します。
o a mechanism for expressing state transition models for persistent problem states,
o 持続的な問題状態の状態遷移モデルを表現するためのメカニズム
o a mechanism to correlate a notification with subsequent state transition notifications about the same entity/object, and
o 通知を同じエンティティ/オブジェクトに関する後続の状態遷移通知と関連付けるメカニズム、および
o a generic alarm reporting mechanism (extends ITU-T work on X.733 [ITU-X733]).
o 汎用アラームレポートメカニズム（X.733 [ITU-X733]でのITU-Tの動作を拡張）。
In particular, [RFC3878] defines objects for controlling the reporting of alarm conditions and extends ITU-T work on M.3100 Amendment 3 [ITU-M3100].
特に、[RFC3878]は、アラーム状態のレポートを制御するためのオブジェクトを定義し、M.3100改訂3 [ITU-M3100]でのITU-Tの作業を拡張します。
Other MIB modules that may be applied to fault management with SNMP include:
SNMPによる障害管理に適用できるその他のMIBモジュールには、次のものがあります。
o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for logging SNMP Notifications.
o NOTIFICATION-LOG-MIB [RFC3014]は、SNMP通知のロギングに使用される管理対象オブジェクトについて説明しています。
o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB to provide information about the state of physical entities.
o ENTITY-STATE-MIB [RFC4268]は、物理エンティティの状態に関する情報を提供するためのエンティティMIBの拡張について説明しています。
o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for extending the Entity MIB to provide generalized access to information related to physical sensors, which are often found in networking equipment (such as chassis temperature, fan RPM, power supply voltage).
o ENTITY-SENSOR-MIB [RFC3433]は、Entity MIBを拡張して、ネットワーク機器によく見られる物理的なセンサーに関連する情報（シャーシの温度、ファンのRPM、電源電圧など）への一般的なアクセスを提供するための管理オブジェクトについて説明します。
The Syslog protocol document [RFC5424] defines an initial set of SDEs that relate to content time quality, content origin, and meta-information about the message, such as language. Proprietary SDEs can be used to supplement the IETF-defined SDEs.
Syslogプロトコルドキュメント[RFC5424]は、コンテンツの時間品質、コンテンツの起源、および言語などのメッセージに関するメタ情報に関連するSDEの初期セットを定義しています。独自のSDEを使用して、IETF定義のSDEを補足できます。
The IETF has standardized MIB Textual-Conventions for facility and severity labels and codes to encourage consistency between syslog and MIB representations of these event properties [RFC5427]. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.
IETFは、これらのイベントプロパティのsyslogとMIB表現の一貫性を促進するために、ファシリティと重大度のラベルとコードのMIBテキストの表記法を標準化しています[RFC5427]。その意図は、これらのテキストの表記法がインポートされ、MIBモジュールで使用され、そうでなければ独自の表現を定義することです。
An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX Meters, Exporters, and Collectors (see Section 2.3). The ongoing work on the PSAMP MIB module extends the IPFIX MIB modules by managed objects for monitoring PSAMP implementations [PSAMP-MIB].
IPFIX MIBモジュール[RFC5815]は、IPFIXメーター、エクスポーター、コレクターを監視するために定義されています（セクション2.3を参照）。 PSAMP MIBモジュールに関する進行中の作業は、PSAMP実装を監視するための管理対象オブジェクトによってIPFIX MIBモジュールを拡張します[PSAMP-MIB]。
The NETCONF working group defined the data model necessary to monitor the NETCONF protocol [RFC6022] with the modeling language YANG. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics, which facilitate the management of a NETCONF server. The NETCONF monitoring document also defines methods for NETCONF clients to discover the data models supported by a NETCONF server and defines the operation <get-schema> to retrieve them.
NETCONFワーキンググループは、モデリング言語YANGを使用してNETCONFプロトコル[RFC6022]を監視するために必要なデータモデルを定義しました。監視データモデルには、NETCONFデータストア、セッション、ロック、および統計に関する情報が含まれ、NETCONFサーバーの管理を容易にします。 NETCONFモニタリングドキュメントは、NETCONFクライアントがNETCONFサーバーでサポートされているデータモデルを検出するためのメソッドを定義し、それらを取得するための操作<get-schema>を定義します。
Configuration management focuses on establishing and maintaining consistency of a system and defines the functionality to configure its functional and physical attributes as well as operational information throughout its life. Configuration management includes configuration of network devices, inventory management, and software management. The data models below can be used to utilize configuration management.
構成管理は、システムの一貫性の確立と維持に重点を置き、その機能属性と物理属性、およびその運用情報を構成する機能を定義します。構成管理には、ネットワークデバイスの構成、インベントリ管理、およびソフトウェア管理が含まれます。以下のデータモデルを使用して、構成管理を利用できます。
MIB modules for monitoring of network configuration (e.g., for physical and logical network topologies) already exist and provide some of the desired capabilities. New MIB modules might be developed for the target functionality to allow operators to monitor and modify the operational parameters, such as timer granularity, event reporting thresholds, target addresses, etc.
ネットワーク構成を監視するためのMIBモジュール（物理および論理ネットワークトポロジなど）はすでに存在しており、必要な機能の一部を提供しています。オペレーターがタイマーの粒度、イベントレポートのしきい値、ターゲットアドレスなどの運用パラメーターを監視および変更できるように、ターゲット機能用に新しいMIBモジュールが開発される場合があります。
[RFC3418], part of [STD62], contains objects in the system group useful, e.g., for identifying the type of device and the location of the device, the person responsible for the device. The SNMPv3 standard [STD62] furthermore includes objects designed for configuring principals, access control rules, notification destinations, and for configuring proxy-forwarding SNMP agents, which can be used to forward messages through firewalls and NAT devices.
[STD62]の一部である[RFC3418]には、たとえば、デバイスのタイプとデバイスの場所、デバイスの責任者を識別するために役立つシステムグループ内のオブジェクトが含まれています。さらに、SNMPv3標準[STD62]には、プリンシパル、アクセスコントロールルール、通知先の構成、およびファイアウォールとNATデバイスを介したメッセージの転送に使用できるプロキシ転送SNMPエージェントの構成用に設計されたオブジェクトが含まれています。
The Entity MIB [RFC4133] supports mainly inventory management and is used for managing multiple logical and physical entities matched to a single SNMP agent. This module provides a useful mechanism for identifying the entities comprising a system and defines event notifications for configuration changes that may be useful to management applications.
エンティティMIB [RFC4133]は主にインベントリ管理をサポートし、単一のSNMPエージェントに一致する複数の論理エンティティおよび物理エンティティを管理するために使用されます。このモジュールは、システムを構成するエンティティを識別するための便利なメカニズムを提供し、管理アプリケーションに役立つ可能性のある構成変更のイベント通知を定義します。
[RFC3165] defines a set of managed objects that enable the delegation of management scripts to distributed managers.
[RFC3165]は、分散スクリプトへの管理スクリプトの委任を可能にする一連の管理対象オブジェクトを定義しています。
For configuring IPFIX and PSAMP devices, the IPFIX working group developed the IPFIX Configuration Data Model [CONF-MODEL], by using the YANG modeling language and in close collaboration with the NETMOD working group (see Section 2.4.2). The model specifies the necessary data for configuring and monitoring Selection Processes, caches, Exporting Processes, and Collecting Processes of IPFIX- and PSAMP-compliant monitoring devices.
IPFIXおよびPSAMPデバイスを構成するために、IPFIXワーキンググループは、YANGモデリング言語を使用し、NETMODワーキンググループと密接に連携して、IPFIX構成データモデル[CONF-MODEL]を開発しました（セクション2.4.2を参照）。モデルは、IPFIXおよびPSAMP準拠の監視デバイスの選択プロセス、キャッシュ、エクスポートプロセス、および収集プロセスの構成と監視に必要なデータを指定します。
At the time of this writing, the NETMOD working group is developing core system and interface models in YANG.
この記事の執筆時点で、NETMODワーキンググループは、YANGでコアシステムとインターフェイスモデルを開発しています。
The CAPWAP protocol exchanges message elements using the Type-Length-Value (TLV) format. The base TLVs are specified in [RFC5415], while the TLVs for IEEE 802.11 are specified in [RFC5416]. The CAPWAP Base MIB [RFC5833] specifies managed objects for the modeling the CAPWAP protocol and provides configuration and WTP status-monitoring aspects of CAPWAP, where the CAPWAP Binding MIB [RFC5834] defines managed objects for the modeling of the CAPWAP protocol for IEEE 802.11 wireless binding. Note: RFC 5833 and RFC 5834 have been published as Informational RFCs to provide the basis for future work on a SNMP management of the CAPWAP protocol.
CAPWAPプロトコルは、Type-Length-Value（TLV）形式を使用してメッセージ要素を交換します。ベースTLVは[RFC5415]で指定されていますが、IEEE 802.11のTLVは[RFC5416]で指定されています。 CAPWAPベースMIB [RFC5833]は、CAPWAPプロトコルのモデリング用の管理対象オブジェクトを指定し、CAPWAPの構成とWTPステータス監視の側面を提供します。CAPWAPバインディングMIB [RFC5834]は、IEEE 802.11ワイヤレスのCAPWAPプロトコルのモデリング用の管理対象オブジェクトを定義しますバインディング。注：RFC 5833およびRFC 5834は、CAPWAPプロトコルのSNMP管理に関する今後の作業の基礎を提供する情報RFCとして公開されています。
Accounting management collects usage information of network resources. Note that the IETF does not define any mechanisms related to billing and charging. Many technology-specific MIBs (link layer, network layer, transport layer, or application layer) contain counters but are not primarily targeted for accounting and, therefore, are not included in this section.
アカウンティング管理は、ネットワークリソースの使用状況情報を収集します。 IETFは、請求および課金に関連するメカニズムを定義していないことに注意してください。多くのテクノロジー固有のMIB（リンク層、ネットワーク層、トランスポート層、またはアプリケーション層）にはカウンターが含まれていますが、主にアカウンティングの対象ではないため、このセクションには含まれていません。
"RADIUS Accounting Client MIB for IPv6" [RFC4670] defines RADIUS Accounting Client MIB objects that support version-neutral IP addressing formats.
「IPv6用RADIUSアカウンティングクライアントMIB」[RFC4670]は、バージョン中立のIPアドレス指定形式をサポートするRADIUSアカウンティングクライアントMIBオブジェクトを定義します。
"RADIUS Accounting Server MIB for IPv6" [RFC4671] defines RADIUS Accounting Server MIB objects that support version-neutral IP addressing formats.
「IPv6用RADIUSアカウンティングサーバーMIB」[RFC4671]は、バージョン中立のIPアドレス指定形式をサポートするRADIUSアカウンティングサーバーMIBオブジェクトを定義します。
IPFIX/PSAMP Information Elements:
IPFIX / PSAMP情報要素：
As expressed in Section 2.3, the IPFIX Architecture [RFC5470] defines components involved in IP flow measurement and reporting of information on IP flows. As such, IPFIX records provide fine-grained measurement data for flexible and detailed usage reporting and enable usage-based accounting.
2.3節で述べたように、IPFIXアーキテクチャ[RFC5470]は、IPフローの測定とIPフローに関する情報の報告に関係するコンポーネントを定義しています。そのため、IPFIXレコードは、柔軟で詳細な使用状況レポートのためのきめの細かい測定データを提供し、使用状況ベースのアカウンティングを可能にします。
The IPFIX Information Elements (IEs) have been initially defined in the IPFIX Information Model [RFC5102] and registered with IANA [IANA-IPFIX]. The IPFIX IEs are composed of two types:
IPFIX情報要素（IE）は、IPFIX情報モデル[RFC5102]で最初に定義され、IANA [IANA-IPFIX]に登録されています。 IPFIX IEは2つのタイプで構成されています。
o IEs related to identification of IP flows such as header information, derived packet properties, IGP and BGP next-hop IP address, BGP AS, etc., and
o ヘッダー情報、派生パケットプロパティ、IGPおよびBGPネクストホップIPアドレス、BGP ASなどのIPフローの識別に関連するIE、および
o IEs related to counter and timestamps, such as per-flow counters (e.g., octet count, packet count), flow start times, flow end times, and flow duration, etc.
o フローごとのカウンター（オクテットカウント、パケットカウントなど）、フローの開始時刻、フローの終了時刻、フローの継続時間など、カウンターとタイムスタンプに関連するIE
The Information Elements specified in the IPFIX Information Model [RFC5102] are used by the PSAMP protocol where applicable. PSAMP Parameters defined in the PSAMP protocol specification are registered at [IANA-PSAMP]. An additional set of PSAMP Information Elements for reporting packet information with the IPFIX/PSAMP protocol such as Sampling-related IEs are specified in the PSAMP Information Model [RFC5477]. These IEs fulfill the requirements on reporting of different sampling and filtering techniques specified in [RFC5475].
IPFIX情報モデル[RFC5102]で指定された情報要素は、該当する場合、PSAMPプロトコルによって使用されます。 PSAMPプロトコル仕様で定義されているPSAMPパラメータは、[IANA-PSAMP]に登録されています。サンプリング関連のIEなど、IPFIX / PSAMPプロトコルでパケット情報を報告するためのPSAMP情報要素の追加セットは、PSAMP情報モデル[RFC5477]で指定されています。これらのIEは、[RFC5475]で指定されているさまざまなサンプリングおよびフィルタリング技術の報告に関する要件を満たしています。
Performance management covers a set of functions that evaluate and report the performance of network elements and the network, with the goal to maintain the overall network performance at a defined level. Performance management functionality includes monitoring and measurement of network performance parameters, gathering statistical information, maintaining and examining activity logs. The data models below can be used for performance management tasks.
パフォーマンス管理は、ネットワーク全体のパフォーマンスを定義されたレベルに維持することを目的として、ネットワーク要素とネットワークのパフォーマンスを評価および報告する一連の機能をカバーしています。パフォーマンス管理機能には、ネットワークパフォーマンスパラメータの監視と測定、統計情報の収集、アクティビティログの維持と調査が含まれます。以下のデータモデルは、パフォーマンス管理タスクに使用できます。
The RMON (Remote Network Monitoring) MIB [STD59] defines objects for collecting data related to network performance and traffic from remote monitoring devices. An organization may employ many remote monitoring probes, one per network segment, to monitor its network. These devices may be used by a network service provider to access a (distant) client network. Most of the objects in the RMON MIB module are suitable for the monitoring of any type of network, while some of them are specific to the monitoring of Ethernet networks.
RMON（リモートネットワークモニタリング）MIB [STD59]は、リモートモニタリングデバイスからのネットワークパフォーマンスとトラフィックに関連するデータを収集するためのオブジェクトを定義します。組織は、ネットワークを監視するために、ネットワークセグメントごとに1つずつ、多数のリモート監視プローブを使用する場合があります。これらのデバイスは、ネットワークサービスプロバイダーが（離れた）クライアントネットワークにアクセスするために使用できます。 RMON MIBモジュールのほとんどのオブジェクトは、あらゆるタイプのネットワークの監視に適していますが、一部はイーサネットネットワークの監視に固有のものです。
RMON allows a probe to be configured to perform diagnostics and to collect network statistics continuously, even when communication with the management station may not be possible or efficient. The alarm group periodically takes statistical samples from variables in the probe and compares them to previously configured thresholds. If the monitored variable crosses a threshold, an event is generated.
RMONを使用すると、管理ステーションとの通信が不可能または効率的でない場合でも、診断を実行し、ネットワーク統計を継続的に収集するようにプローブを設定できます。アラームグループは、プローブ内の変数から統計サンプルを定期的に取得し、それらを以前に設定されたしきい値と比較します。監視対象の変数がしきい値を超えると、イベントが生成されます。
"Introduction to the Remote Monitoring (RMON) Family of MIB Modules" [RFC3577] describes the documents associated with the RMON Framework and how they relate to each other.
「MIBモジュールのリモートモニタリング（RMON）ファミリの概要」[RFC3577]では、RMONフレームワークに関連するドキュメントと、それらの相互関係について説明しています。
The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up to the application layer and defines performance data to monitor. The SMON MIB [RFC2613] extends RMON by providing RMON analysis for switched networks.
RMON-2 MIB [RFC4502]は、RMON分析をアプリケーション層まで提供することによりRMONを拡張し、監視するパフォーマンスデータを定義します。 SMON MIB [RFC2613]は、スイッチドネットワークのRMON分析を提供することにより、RMONを拡張します。
"Remote Monitoring MIB Extensions for High Capacity Alarms" [RFC3434] describes managed objects for extending the alarm thresholding capabilities found in the RMON MIB and provides similar threshold monitoring of objects based on the Counter64 data type.
「大容量アラームのリモート監視MIB拡張」[RFC3434]では、RMON MIBにあるアラームしきい値機能を拡張するための管理オブジェクトについて説明し、Counter64データタイプに基づいてオブジェクトの同様のしきい値監視を提供します。
"Remote Network Monitoring Management Information Base for High Capacity Networks" [RFC3273] defines objects for managing RMON devices for use on high-speed networks.
「大容量ネットワーク用のリモートネットワーク監視管理情報ベース」[RFC3273]は、高速ネットワークで使用するRMONデバイスを管理するためのオブジェクトを定義しています。
"Remote Monitoring MIB Extensions for Interface Parameters Monitoring" [RFC3144] describes an extension to the RMON MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface.
「インターフェイスパラメータモニタリング用のリモートモニタリングMIB拡張」[RFC3144]では、このインターフェイスに固有のパラメータの値に従って監視対象デバイスのインターフェイスをソートする方法を備えたRMON MIBの拡張について説明しています。
[RFC4710] describes Real-Time Application Quality of Service Monitoring (RAQMON), which is part of the RMON protocol family. RAQMON supports end-to-end QoS monitoring for multiple concurrent applications and does not relate to a specific application transport. RAQMON is scalable and works well with encrypted payload and signaling. RAQMON uses TCP to transport RAQMON PDUs.
[RFC4710]は、RMONプロトコルファミリの一部であるリアルタイムアプリケーションのサービスの品質監視（RAQMON）について説明しています。 RAQMONは、複数の同時アプリケーションのエンドツーエンドQoS監視をサポートし、特定のアプリケーショントランスポートには関係しません。 RAQMONはスケーラブルであり、暗号化されたペイロードとシグナリングでうまく機能します。 RAQMONはTCPを使用してRAQMON PDUを転送します。
[RFC4711] proposes an extension to the Remote Monitoring MIB [STD59] and describes managed objects used for RAQMON. [RFC4712] specifies two transport mappings for the RAQMON information model using TCP as a native transport and SNMP to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC).
[RFC4711]は、Remote Monitoring MIB [STD59]への拡張を提案し、RAQMONに使用される管理対象オブジェクトについて説明しています。 [RFC4712]は、ネイティブトランスポートとしてTCPを使用するRAQMON情報モデルの2つのトランスポートマッピングと、RAQMONデータソース（RDS）からRAQMONレポートコレクタ（RRC）にRAQMON情報を送信するSNMPを指定します。
"Application Performance Measurement MIB" [RFC3729] uses the architecture created in the RMON MIB and defines objects by providing measurement and analysis of the application performance as experienced by end-users. [RFC3729] enables the measurement of the quality of service delivered to end-users by applications.
「アプリケーションパフォーマンス測定MIB」[RFC3729]は、RMON MIBで作成されたアーキテクチャを使用し、エンドユーザーが経験するアプリケーションパフォーマンスの測定と分析を提供することによってオブジェクトを定義します。 [RFC3729]は、アプリケーションによってエンドユーザーに提供されるサービス品質の測定を可能にします。
"Transport Performance Metrics MIB" [RFC4150] describes managed objects used for monitoring selectable Performance Metrics and statistics derived from the monitoring of network packets and sub-application level transactions. The metrics can be defined through reference to existing IETF, ITU, and other SDOs' documents.
「トランスポートパフォーマンスメトリックMIB」[RFC4150]では、ネットワークパケットとサブアプリケーションレベルのトランザクションの監視から派生した、選択可能なパフォーマンスメトリックと統計の監視に使用される管理対象オブジェクトについて説明しています。メトリックは、既存のIETF、ITU、およびその他のSDOのドキュメントを参照して定義できます。
The IPPM working group has defined "IP Performance Metrics (IPPM) Metrics Registry" [RFC4148]. Note that with the publication of [RFC6248], [RFC4148] and the corresponding IANA registry for IPPM metrics have been declared Obsolete and shouldn't be used.
IPPMワーキンググループは、「IP Performance Metrics（IPPM）Metrics Registry」[RFC4148]を定義しています。 [RFC6248]、[RFC4148]、およびIPPMメトリックの対応するIANAレジストリの公開により、廃止されたと宣言されているため、使用しないでください。
The IPPM working group defined the "Information Model and XML Data Model for Traceroute Measurements" [RFC5388], which defines a common information model dividing the IEs into two semantically separated groups (configuration elements and results elements) with an additional element to relate configuration elements and results elements by means of a common unique identifier. Based on the information model, an XML data model is provided to store the results of traceroute measurements.
IPPMワーキンググループは、「トレースルート測定の情報モデルとXMLデータモデル」[RFC5388]を定義しました。これは、IEを2つの意味論的に分離されたグループ（構成要素と結果要素）に分割し、構成要素に関連する追加要素を持つ共通情報モデルを定義します。共通の一意の識別子を使用して要素を生成します。情報モデルに基づいて、XMLデータモデルが提供され、traceroute測定の結果を保存します。
"Session Initiation Protocol Event Package for Voice Quality Reporting" [RFC6035] defines a SIP event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions.
「音声品質レポート用のセッション開始プロトコルイベントパッケージ」[RFC6035]は、Voice over Internet Protocol（VoIP）セッションの品質を測定するメトリックの収集とレポートを可能にするSIPイベントパッケージを定義します。
Security management provides the set of functions to protect the network and system from unauthorized access and includes functions such as creating, deleting, and controlling security services and mechanisms, key management, reporting security-relevant events, and authorizing user access and privileges. Based on their support for authentication and authorization, RADIUS and diameter are seen as security management protocols. The data models below can be used to utilize security management.
セキュリティ管理は、ネットワークとシステムを不正アクセスから保護する一連の機能を提供し、セキュリティサービスとメカニズムの作成、削除、制御、キー管理、セキュリティ関連イベントのレポート、ユーザーアクセスと権限の承認などの機能を含みます。認証と承認のサポートに基づいて、RADIUSとDiameterはセキュリティ管理プロトコルと見なされます。以下のデータモデルを使用して、セキュリティ管理を利用できます。
[RFC3414], part of [STD62], specifies the procedures for providing SNMPv3 message-level security and includes a MIB module for remotely monitoring and managing the configuration parameters for the USM.
[RFC3414]は[STD62]の一部であり、SNMPv3メッセージレベルのセキュリティを提供するための手順を指定し、USMの構成パラメーターをリモートで監視および管理するためのMIBモジュールを含みます。
[RFC3415], part of [STD62], describes the procedures for controlling access to management information in the SNMPv3 architecture and includes a MIB module, which defines managed objects to access portions of an SNMP engine's Local Configuration Datastore (LCD). As such, this MIB module enables remote management of the configuration parameters of the VACM.
[STD62]の一部である[RFC3415]は、SNMPv3アーキテクチャで管理情報へのアクセスを制御する手順を説明し、SNMPエンジンのローカル構成データストア（LCD）の一部にアクセスするための管理対象オブジェクトを定義するMIBモジュールを含みます。そのため、このMIBモジュールは、VACMの構成パラメーターのリモート管理を可能にします。
The NETCONF Access Control Model (NACM) [RFC6536] addresses the need for access control mechanisms for the operation and content layers of NETCONF, as defined in [RFC6241]. As such, the NACM proposes standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content within a particular server.
NETCONFアクセス制御モデル（NACM）[RFC6536]は、[RFC6241]で定義されているように、NETCONFの操作およびコンテンツレイヤーのアクセス制御メカニズムの必要性に対処します。そのため、NACMは、特定のユーザーのNETCONFプロトコルアクセスを、特定のサーバー内で利用可能なすべてのNETCONFプロトコル操作とコンテンツの事前構成済みサブセットに制限する標準メカニズムを提案します。
There are numerous MIB modules defined for multiple purposes to use with RADIUS:
RADIUSで使用する複数の目的で定義された多数のMIBモジュールがあります。
o "RADIUS Authentication Client MIB for IPv6" [RFC4668] defines RADIUS Authentication Client MIB objects that support version-neutral IP addressing formats and defines a set of extensions for RADIUS authentication client functions.
o 「IPv6のRADIUS認証クライアントMIB」[RFC4668]は、バージョンに中立なIPアドレス指定形式をサポートするRADIUS認証クライアントMIBオブジェクトを定義し、RADIUS認証クライアント機能の拡張セットを定義します。
o "RADIUS Authentication Server MIB for IPv6" [RFC4669] defines RADIUS Authentication Server MIB objects that support version-neutral IP addressing formats and defines a set of extensions for RADIUS authentication server functions.
o 「IPv6のRADIUS認証サーバーMIB」[RFC4669]は、バージョンに中立なIPアドレス指定形式をサポートするRADIUS認証サーバーMIBオブジェクトを定義し、RADIUS認証サーバー機能の拡張セットを定義します。
o "RADIUS Dynamic Authorization Client MIB" [RFC4672] defines the MIB module for entities implementing the client side of the Dynamic Authorization Extensions to RADIUS [RFC5176].
o 「RADIUS Dynamic Authorization Client MIB」[RFC4672]は、RADIUSへのDynamic Authorization Extensions [RFC5176]のクライアント側を実装するエンティティのMIBモジュールを定義します。
o "RADIUS Dynamic Authorization Server MIB" [RFC4673] defines the MIB module for entities implementing the server side of the Dynamic Authorization Extensions to RADIUS [RFC5176].
o 「RADIUS Dynamic Authorization Server MIB」[RFC4673]は、RADIUSへのDynamic Authorization Extensions [RFC5176]のサーバー側を実装するエンティティのMIBモジュールを定義します。
The MIB Module definitions in [RFC4668], [RFC4669], [RFC4672], [RFC4673] are intended to be used only for RADIUS over UDP and do not support RADIUS over TCP. There is also a recommendation that RADIUS clients and servers implementing RADIUS over TCP should not reuse earlier listed MIB modules to perform statistics counting for RADIUS-over-TCP connections.
[RFC4668]、[RFC4669]、[RFC4672]、[RFC4673]のMIBモジュール定義は、RADIUS over UDPでのみ使用することを目的としており、RADIUS over TCPをサポートしていません。 RADIUS over TCPを実装するRADIUSクライアントとサーバーは、前にリストされたMIBモジュールを再利用して、RADIUS-over-TCP接続の統計カウントを実行しないようにすることも推奨されています。
Currently, there are no standardized MIB modules for diameter applications, which can be considered as a lack on the management side of diameter nodes.
現在、Diameterアプリケーションの標準化されたMIBモジュールはありません。これは、Diameterノードの管理側の不足と見なすことができます。
This document gives an overview of IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. As such, it does not have any security implications in or of itself.
このドキュメントは、IETFネットワーク管理標準の概要を示し、IETF標準追跡ネットワーク管理プロトコルとデータモデルの既存および現在進行中の開発を要約しています。そのため、それ自体にはセキュリティ上の影響はありません。
For each specific technology discussed in the document a summary of its security usage has been given in corresponding chapters. In a few cases, e.g., for SNMP, a detailed description of developed security mechanisms has been provided.
このドキュメントで説明されている特定のテクノロジーごとに、そのセキュリティ使用法の概要が対応する章に記載されています。いくつかの場合、たとえばSNMPの場合、開発されたセキュリティメカニズムの詳細な説明が提供されています。
The attention of the reader is particularly drawn to the security discussion in following document sections:
読者の注意は、以下のドキュメントセクションのセキュリティに関する議論に特に引き付けられます。
o SNMP Security and Access Control Models in Section 2.1.4.1,
o 2.1.4.1項のSNMPセキュリティおよびアクセス制御モデル、
o User-based Security Model (USM) in Section 2.1.4.2,
o セクション2.1.4.2のユーザーベースのセキュリティモデル（USM）
o View-based Access Control Model (VACM) in Section 2.1.4.3,
o セクション2.1.4.3のビューベースのアクセス制御モデル（VACM）
o SNMP Transport Security Model in Section 2.1.5.1,
o セクション2.1.5.1のSNMPトランスポートセキュリティモデル
o Secure syslog message delivery in Section 2.2,
o セクション2.2のsyslogメッセージの安全な配信
o Use of secure NETCONF message transport and the NETCONF Access Control Model (NACM) in Section 2.4.1,
o 安全なNETCONFメッセージ転送とセクション2.4.1のNETCONFアクセスコントロールモデル（NACM）の使用
o Message authentication for Dynamic Host Configuration Protocol (DHCP) in Section 3.1.1,
o セクション3.1.1の動的ホスト構成プロトコル（DHCP）のメッセージ認証
o Security for Remote Authentication Dial-In User Service (RADIUS) in conjunction with EAP and IEEE 802.1X authenticators in Section 3.5,
o セクション3.5のEAPおよびIEEE 802.1Xオーセンティケーターと組み合わせたリモート認証ダイヤルインユーザーサービス（RADIUS）のセキュリティ
o Built-in and transport security for the Diameter Base Protocol in Section 3.6,
o セクション3.6のDiameter基本プロトコルの組み込みおよびトランスポートセキュリティ
o Transport security for Control And Provisioning of Wireless Access Points (CAPWAP) in Section 3.7,
o セクション3.7のワイヤレスアクセスポイント（CAPWAP）の制御とプロビジョニングのためのトランスポートセキュリティ
o Built-in security for Access Node Control Protocol (ANCP) in Section 3.8,
o セクション3.8のアクセスノード制御プロトコル（ANCP）の組み込みセキュリティ
o Security for Application Configuration Access Protocol (ACAP) in Section 3.9,
o セクション3.9のApplication Configuration Access Protocol（ACAP）のセキュリティ
o Security for XML Configuration Access Protocol (XCAP) in Section 3.10, and
o セクション3.10のXML構成アクセスプロトコル（XCAP）のセキュリティ、および
o Data models for Security Management in Section 4.2.5.
o セクション4.2.5のセキュリティ管理のデータモデル。
The authors would also like to refer to detailed security consideration sections for specific management standards described in this document, which contain comprehensive discussion of security implications of the particular management protocols and mechanisms. Among others, security consideration sections of following documents should be carefully read before implementing the technology.
著者はまた、このドキュメントで説明されている特定の管理標準の詳細なセキュリティ考慮セクションを参照したいと思います。このセクションには、特定の管理プロトコルとメカニズムのセキュリティへの影響に関する包括的な説明が含まれています。特に、次のドキュメントのセキュリティに関する考慮事項のセクションは、テクノロジを実装する前に注意深く読む必要があります。
o For SNMP security in general, subsequent security consideration sections in [STD62], which includes RFCs 3411-3418,
o SNMPセキュリティ全般については、RFC 3411-3418を含む、[STD62]の後続のセキュリティ考慮事項セクション、
o Security considerations section in Section 8 of [BCP074] for the coexistence of SNMP versions 1, 2, and 3,
o [BCP074]のセクション8のセキュリティに関する考慮事項セクション。SNMPバージョン1、2、3の共存について
o Security considerations for the SNMP Transport Security Model in Section 8 of [RFC5591],
o [RFC5591]のセクション8にあるSNMPトランスポートセキュリティモデルのセキュリティに関する考慮事項、
o Security considerations for the Secure Shell Transport Model for SNMP in Section 9 of [RFC5592],
o [RFC5592]のセクション9にあるSNMPのセキュアシェルトランスポートモデルのセキュリティに関する考慮事項、
o Security considerations for the TLS Transport Model for SNMP in Section 9 of [RFC6353],
o [RFC6353]のセクション9にあるSNMPのTLSトランスポートモデルのセキュリティに関する考慮事項、
o Security considerations for the TLS Transport Mapping for syslog in Section 6 of [RFC5425],
o [RFC5425]のセクション6にあるsyslogのTLSトランスポートマッピングのセキュリティに関する考慮事項
o Security considerations for the IPFIX Protocol Specification in Section 11 of [RFC5101],
o [RFC5101]のセクション11のIPFIXプロトコル仕様のセキュリティに関する考慮事項、
o Security considerations for the NETCONF protocol in Section 9 of [RFC6241] and the SSH transport in Section 6 of [RFC6242],
o [RFC6241]のセクション9のNETCONFプロトコルと[RFC6242]のセクション6のSSHトランスポートのセキュリティに関する考慮事項、
o Security considerations for the NETCONF Access Control Model (NACM) in Section 3.7 of [RFC6536],
o [RFC6536]のセクション3.7にあるNETCONFアクセスコントロールモデル（NACM）のセキュリティに関する考慮事項、
o Security considerations for DHCPv4 and DHCPv6 in Section 7 of [RFC2131] and Section 23. of [RFC3315],
o [RFC2131]のセクション7と[RFC3315]のセクション23のDHCPv4とDHCPv6のセキュリティに関する考慮事項、
o Security considerations for RADIUS in Section 8 of [RFC2865],
o [RFC2865]のセクション8にあるRADIUSのセキュリティに関する考慮事項、
o Security considerations for diameter in Section 13 of [RFC3588],
o [RFC3588]のセクション13の直径に関するセキュリティ上の考慮事項、
o Security considerations for the CAPWAP protocol in Section 12 of [RFC5415],
o [RFC5415]のセクション12にあるCAPWAPプロトコルのセキュリティに関する考慮事項、
o Security considerations for the ANCP protocol in Section 11 of [RFC6320], and
o [RFC6320]のセクション11にあるANCPプロトコルのセキュリティに関する考慮事項、および
o Security considerations for the XCAP protocol in Section 14 of [RFC4825].
o [RFC4825]のセクション14にあるXCAPプロトコルのセキュリティに関する考慮事項。
Following persons made significant contributions to and reviewed this document:
以下の人物がこの文書に重要な貢献をしてレビューしました：
o Ralph Droms (Cisco) - revised the section on IP Address Management and DHCP.
o Ralph Droms（Cisco）-IPアドレス管理とDHCPに関するセクションを改訂。
o Jouni Korhonen (Nokia Siemens Networks) - contributed the sections on RADIUS and diameter.
o Jouni Korhonen（Nokia Siemens Networks）-RADIUSと直径に関するセクションに貢献。
o Al Morton (AT&T) - contributed to the section on IP Performance Metrics.
o Al Morton（AT＆T）-IPパフォーマンスメトリックに関するセクションに貢献。
o Juergen Quittek (NEC) - contributed the section on IPFIX/PSAMP.
o Juergen Quittek（NEC）-IPFIX / PSAMPのセクションを寄稿しました。
o Juergen Schoenwaelder (Jacobs University Bremen) - contributed the sections on IETF Network Management Data Models and YANG.
o Juergen Schoenwaelder（Jacobs University Bremen）-IETF Network Management Data ModelsとYANGのセクションを寄稿しました。
The editor would like to thank Fred Baker, Alex Clemm, Miguel A. Garcia, Simon Leinen, Christopher Liljenstolpe, Tom Petch, Randy Presuhn, Dan Romascanu, Juergen Schoenwaelder, Tina Tsou, and Henk Uijterwaal for their valuable suggestions and comments in the OPSAWG sessions and on the mailing list.
編集者は、OPSAWGでの貴重な提案とコメントを提供してくれたFred Baker、Alex Clemm、Miguel A. Garcia、Simon Leinen、Christopher Liljenstolpe、Tom Petch、Randy Presuhn、Dan Romascanu、Juergen Schoenwaelder、Tina Tsou、Henk Uijterwaalに感謝します。セッションおよびメーリングリスト。
The editor would like to especially thank Dave Harrington, who created the document "Survey of IETF Network Management Standards" a few years ago, which has been used as a starting point and enhanced with a special focus on the description of the IETF network management standards and management data models.
編集者は、数年前にドキュメント「IETFネットワーク管理標準の調査」を作成したDave Harringtonに特に感謝します。これは、開始点として使用され、IETFネットワーク管理標準の説明に特に重点を置いて強化されています。および管理データモデル。
[3GPPEPC] 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks", December 2010, <http://www.3gpp.org/ftp/Specs/html-info/24302.htm>.
[3GPPEPC] 3GPP、「非3GPPアクセスネットワーク経由の3GPP Evolved Packet Core（EPC）へのアクセス」、2010年12月、<http://www.3gpp.org/ftp/Specs/html-info/24302.htm> 。
[3GPPIMS] 3GPP, "Release 10, IP Multimedia Subsystem (IMS); Stage 2", September 2010, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[3GPPIMS] 3GPP、「リリース10、IPマルチメディアサブシステム（IMS）;ステージ2」、2010年9月、<http://www.3gpp.org/ftp/Specs/html-info/23228.htm>。
[BCP027] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, "Advancement of MIB specifications on the IETF Standards Track", BCP 27, RFC 2438, October 1998.
[BCP027] O'Dell、M.、Alvestrand、H.、Wijnen、B。、およびS. Bradner、「Advancement of MIB specification on the IETF Standards Track」、BCP 27、RFC 2438、1998年10月。
[BCP074] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[BCP074] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、BCP 74、RFC 3584 、2003年8月。
[BCP170] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[BCP170] Clark、A.およびB. Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、2011年10月。
[CONF-MODEL] Muenz, G., Claise, B., and P. Aitken, "Configuration Data Model for IPFIX and PSAMP", Work in Progress, July 2011.
[会議モデル] Muenz、G.、Claise、B。、およびP. Aitken、「IPFIXおよびPSAMPの構成データモデル」、Work in Progress、2011年7月。
[DIAMETER] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", Work in Progress, April 2012.
[DIAMETER] Fajardo、V.、Arkko、J.、Loughney、J.、and G. Zorn、 "Diameter Base Protocol"、Work in Progress、2012年4月。
[DMTF-CIM] DMTF, "Common Information Model Schema, Version 2.27.0", November 2010, <http://www.dmtf.org/standards/cim>.
[DMTF-CIM] DMTF、「Common Information Model Schema、Version 2.27.0」、2010年11月、<http://www.dmtf.org/standards/cim>。
[EMAN-WG] IETF, "EMAN Working Group", <http://datatracker.ietf.org/wg/eman>.
[EMAN-WG] IETF、「EMAN Working Group」、<http://datatracker.ietf.org/wg/eman>。
[FCAPS] International Telecommunication Union, "X.700: Management Framework For Open Systems Interconnection (OSI) For CCITT Applications", September 1992, <http://www.itu.int/rec/T-REC-X.700-199209-I/en>.
[FCAPS] International Telecommunication Union、「X.700：Management Framework For Open Systems Interconnection（OSI）For CCITT Applications」、1992年9月、<http://www.itu.int/rec/T-REC-X.700- 199209-I / en>。
[IANA-AAA] Internet Assigned Numbers Authority, "Authentication, Authorization, and Accounting (AAA) Parameters", February 2012, <http://www.iana.org/assignments/aaa-parameters>.
[IANA-AAA] Internet Assigned Numbers Authority、「Authentication、Authorization、and Accounting（AAA）Parameters」、2012年2月、<http://www.iana.org/assignments/aaa-parameters>。
[IANA-IPFIX] Internet Assigned Numbers Authority, "IP Flow Information Export (IPFIX) Entities", May 2012, <http://www.iana.org/assignments/ipfix>.
[IANA-IPFIX] Internet Assigned Numbers Authority、「IP Flow Information Export（IPFIX）Entities」、2012年5月、<http://www.iana.org/assignments/ipfix>。
[IANA-PROT] Internet Assigned Numbers Authority, "Protocol Registries", <http://www.iana.org/protocols/>.
[IANA-PROT] Internet Assigned Numbers Authority、「Protocol Registries」、<http://www.iana.org/protocols/>。
[IANA-PSAMP] Internet Assigned Numbers Authority, "Packet Sampling (PSAMP) Parameters", April 2009, <http://www.iana.org/assignments/psamp-parameters>.
[IANA-PSAMP] Internet Assigned Numbers Authority、「Packet Sampling（PSAMP）Parameters」、2009年4月、<http://www.iana.org/assignments/psamp-parameters>。
[IETF-WGS] IETF, "IETF Working Groups", <http://datatracker.ietf.org/wg/>.
[IETF-WGS] IETF、「IETFワーキンググループ」、<http://datatracker.ietf.org/wg/>。
[ITU-M3100] International Telecommunication Union, "M.3100: Generic network information model", January 2006, <http://www.itu.int/rec/T-REC-M.3100-200504-I>.
[ITU-M3100] International Telecommunication Union、「M.3100：Generic network information model」、2006年1月、<http://www.itu.int/rec/T-REC-M.3100-200504-I>。
[ITU-X680] International Telecommunication Union, "X.680: Abstract Syntax Notation One (ASN.1): Specification of basic notation", July 2002, <http://www.itu.int/ ITU-T/studygroups/com17/languages/X.680-0207.pdf>.
[ITU-X680] International Telecommunication Union、「X.680：Abstract Syntax Notation One（ASN.1）：Specification of basic notation」、2002年7月、<http://www.itu.int/ ITU-T / studygroups / com17 / languages / X.680-0207.pdf>。
[ITU-X733] International Telecommunication Union, "X.733: Systems Management: Alarm Reporting Function", October 1992, <http://www.itu.int/rec/T-REC-X.733-199202-I/en>.
[ITU-X733] International Telecommunication Union、「X.733：Systems Management：Alarm Reporting Function」、1992年10月、<http://www.itu.int/rec/T-REC-X.733-199202-I/ en>。
[MPLSTP-MIB] King, D. and V. Mahalingam, "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview", Work in Progress, April 2012.
[MPLSTP-MIB]キング、D.、V。マハリンガム、「マルチプロトコルラベルスイッチングトランスポートプロファイル（MPLS-TP）MIBベースの管理の概要」、作業中、2012年4月。
[OAM-ANALYSIS] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for MPLS based Transport Networks", Work in Progress, April 2012.
[OAM-ANALYSIS] Sprecher、N。およびL. Fang、「MPLSベースのトランスポートネットワーク用のOAMツールセットの概要」、作業中、2012年4月。
[OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, March 2012.
[OAM-OVERVIEW]ミズラヒ、T。、スプレッチャー、N。、ベラガンバ、E。、およびY.ウェインガルテン、「運用、管理、および保守（OAM）メカニズムの概要」、進行中の作業、2012年3月。
[PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek, "Definitions of Managed Objects for Packet Sampling", Work in Progress, October 2011.
[PSAMP-MIB] Dietz、T.、Claise、B。、およびJ. Quittek、「パケットサンプリング用の管理対象オブジェクトの定義」、Work in Progress、2011年10月。
[RELAX-NG] OASIS, "RELAX NG Specification, Committee Specification 3 December 2001", December 2001, <http: //www.oasis-open.org/committees/relax-ng/ spec-20011203.html>.
[RELAX-NG] OASIS、「RELAX NG仕様、委員会仕様3 2001年12月3日」、2001年12月、<http：//www.oasis-open.org/committees/relax-ng/ spec-20011203.html>。
[RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC0951] Croft、B。およびJ. Gilmore、「Bootstrap Protocol」、RFC 951、1985年9月。
[RFC1021] Partridge, C. and G. Trewitt, "High-level Entity Management System (HEMS)", RFC 1021, October 1987.
[RFC1021] Partridge、C。およびG. Trewitt、「High-level Entity Management System（HEMS）」、RFC 1021、1987年10月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/ IP-based internets", STD 16, RFC 1155, May 1990.
[RFC1155] Rose、M。、およびK. McCloghrie、「構造およびTCP / IPベースのインターネットの管理情報の識別」、STD 16、RFC 1155、1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。、およびJ. Davin、「Simple Network Management Protocol（SNMP）」、STD 15、RFC 1157、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991.
[RFC1212] Rose、M。およびK. McCloghrie、「簡潔なMIB定義」、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "Convention for defining traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215] Rose、M。、「SNMPで使用するトラップを定義するための規約」、RFC 1215、1991年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices", RFC 1470, June 1993.
[RFC1470] Enger、R。およびJ. Reynolds、「FYI on a Network Management Tool Catalog：Tools for Monitoring and Debugging TCP / IP Internets and Interconnected Devices」、RFC 1470、1993年6月。
[RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901] Case、J.、McCloghrie、K.、McCloghrie、K.、Rose、M.、and S. Waldbusser、 "Introduction to Community-based SNMPv2"、RFC 1901、January 1996。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス-リビジョン3」、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2127] Roeck, G., "ISDN Management Information Base using SMIv2", RFC 2127, March 1997.
[RFC2127] Roeck、G。、「SMIv2を使用するISDN管理情報ベース」、RFC 2127、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[RFC2195] Klensin、J.、Catoe、R。、およびP. Krumviede、「IMAP / POP AUTHorize Extension for Simple Challenge / Response」、RFC 2195、1997年9月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]ニューマン、C。およびJ.マイヤーズ、「ACAP-Application Configuration Access Protocol」、RFC 2244、1997年11月。
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998.
[RFC2287] Krupczak、C。およびJ. Saperia、「Definions of System-Level Managed Objects for Applications」、RFC 2287、1998年2月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「Framework for IP Performance Metrics」、RFC 2330、1998年5月。
[RFC2458] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., Burg, F., DeSimone, A., Tewani, K., Davidson, P., Schulzrinne, H., and K. Vishwanathan, "Toward the PSTN/Internet Inter-Networking --Pre-PINT Implementations", RFC 2458, November 1998.
[RFC2458] Lu、H、Krishnaswamy、M、Conroy、L、Bellovin、S、Burg、F、DeSimone、A、Tewani、K、Davidson、P、Schulzrinne、H、K 。Vishwanathan、「PSTN / Internet Inter-Networking --Pre-PINT Implementations」、RFC 2458、1998年11月。
[RFC2515] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999.
[RFC2515] Tesink、K。、「Definions of Managed Objects for ATM Management」、RFC 2515、1999年2月。
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, May 1999.
[RFC2564] Kalbfleisch、C.、Krupczak、C.、Presuhn、R。、およびJ. Saperia、「アプリケーション管理MIB」、RFC 2564、1999年5月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Structure of Management Information Version 2（SMIv2）"、STD 58、RFC 2578、April 1999。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、April 1999。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIv2の適合宣言」、STD 58、RFC 2580、1999年4月。
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
[RFC2610]パーキンス、C。およびE.ガットマン、「Service Location ProtocolのDHCPオプション」、RFC 2610、1999年6月。
[RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0", RFC 2613, June 1999.
[RFC2613] Waterman、R.、Lahaye、B.、Romascanu、D。、およびS. Waldbusser、「スイッチドネットワークバージョン1.0のリモートネットワークモニタリングMIB拡張」、RFC 2613、1999年6月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999.
[RFC2678] Mahdavi、J。およびV. Paxson、「IPPM Metrics for Measurement Connectivity」、RFC 2678、1999年9月。
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2679] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「A IP-way Delay Metric for IPPM」、RFC 2679、1999年9月。
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2680] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの片方向パケット損失メトリック」、RFC 2680、1999年9月。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[RFC2748]ダーラム、D。、ボイル、J。、コーエン、R。、ヘルツォーク、S。、ラジャン、R。、およびA.サストリー、「COPS（Common Open Policy Service）Protocol」、RFC 2748、2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D。、およびR. Guerin、「A Framework for Policy-based Admission Control」、RFC 2753、2000年1月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]リグニー、C。、「RADIUSアカウンティング」、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867] Zorn、G.、Aboba、B。、およびD. Mitton、「RADIUS Accounting Modifications for Tunnel Protocol Support」、RFC 2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「RADIUS Attributes for Tunnel Protocol Support」、RFC 2868、2000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「RADIUS Extensions」、RFC 2869、2000年6月。
[RFC2981] Kavasseri, R., "Event MIB", RFC 2981, October 2000.
[RFC2981] Kavasseri、R。、「イベントMIB」、RFC 2981、2000年10月。
[RFC2982] Kavasseri, R., "Distributed Management Expression MIB", RFC 2982, October 2000.
[RFC2982] Kavasseri、R。、「分散管理表現MIB」、RFC 2982、2000年10月。
[RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000.
[RFC3014] Kavasseri、R。、「通知ログMIB」、RFC 3014、2000年11月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[RFC3084]チャン、K、セリグソン、J、ダラム、D、ガイ、S、マックログリー、K、ヘルツォーク、S、ライヒマイヤー、F、ヤヴァトカール、A、スミス、「COPS Policy Provisioning（COPS-PR）の使用法」、RFC 3084、2001年3月。
[RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for Interface Parameters Monitoring", RFC 3144, August 2001.
[RFC3144] Romascanu、D。、「Remote Monitoring MIB Extensions for Interface Parameters Monitoring」、RFC 3144、2001年8月。
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001.
[RFC3159] McCloghrie、K.、Fine、M.、Seligson、J.、Chan、K.、Hahn、S.、Sahita、R.、Smith、A.、and F. Reichmeyer、 "Structure of Policy Provisioning Information（ SPPI）」、RFC 3159、2001年8月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164] Lonvick、C。、「The BSD Syslog Protocol」、RFC 3164、2001年8月。
[RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts", RFC 3165, August 2001.
[RFC3165] Levi、D。およびJ. Schoenwaelder、「Descriptions for Delegation for Management Scripts」、RFC 3165、2001年8月。
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.
[RFC3195] New、D。およびM. Rose、「Reliable Delivery for syslog」、RFC 3195、2001年11月。
[RFC3273] Waldbusser, S., "Remote Network Monitoring Management Information Base for High Capacity Networks", RFC 3273, July 2002.
[RFC3273] Waldbusser、S。、「大容量ネットワーク用のリモートネットワーク監視管理情報ベース」、RFC 3273、2002年7月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319] Schulzrinne、H。およびB. Volz、「Session Initiation Protocol（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション」、RFC 3319、2003年7月。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.
[RFC3393] Demichelis、C。およびP. Chimento、「IPパフォーマンスメトリックのIPパケット遅延変動メトリック（IPPM）」、RFC 3393、2002年11月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「Introduction and Applicability Statements for Internet-Standard Management Framework」、RFC 3410、2002年12月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413] Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（SNMP）Applications」、STD 62、RFC 3413、2002年12月。
[RFC3414] 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.
[RFC3414] Blumenthal、U。およびB. Wijnen、「Simple Network Management Protocol（SNMPv3）バージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[RFC3415] 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.
[RFC3415] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「簡易ネットワーク管理プロトコル（SNMP）のビューベースアクセスコントロールモデル（VACM）」、STD 62、RFC 3415、2002年12月。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R。、「Transport Mappings for the Simple Network Management Protocol（SNMP）」、STD 62、RFC 3417、2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R。、「簡易ネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002.
[RFC3430] Schoenwaelder、J。、「Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping」、RFC 3430、2002年12月。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002.
[RFC3432] Raisanen、V.、Grotefeld、G。、およびA. Morton、「定期的なストリームによるネットワークパフォーマンス測定」、RFC 3432、2002年11月。
[RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity Sensor Management Information Base", RFC 3433, December 2002.
[RFC3433] Bierman、A.、Romascanu、D。、およびK. Norseth、「エンティティセンサー管理情報ベース」、RFC 3433、2002年12月。
[RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB Extensions for High Capacity Alarms", RFC 3434, December 2002.
[RFC3434] Bierman、A。およびK. McCloghrie、「高容量アラーム用のリモートモニタリングMIB拡張」、RFC 3434、2002年12月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「On the Difference between Information Models and Data Models」、RFC 3444、2003年1月。
[RFC3460] Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460] Moore、B。、「Policy Core Information Model（PCIM）Extensions」、RFC 3460、2003年1月。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535] Schoenwaelder、J。、「2002 IABネットワーク管理ワークショップの概要」、RFC 3535、2003年5月。
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[RFC3574] Soininen、J。、「3GPPネットワークの移行シナリオ」、RFC 3574、2003年8月。
[RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003.
[RFC3577] Waldbusser、S.、Cole、R.、Kalbfleisch、C。、およびD. Romascanu、「Introduction to the Remote Monitoring（RMON）Family of MIB Modules」、RFC 3577、2003年8月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（Remote Authentication Dial In User Service）Support For Extensible Authentication Protocol（EAP）」、RFC 3579、2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1X Remote Authentication Dial In User Service（RADIUS）Usage Guidelines」、RFC 3580、2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC3589] Loughney, J., "Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5", RFC 3589, September 2003.
[RFC3589] Loughney、J。、「Diameter Command Codes for Third Generation Partnership Project（3GPP）Release 5」、RFC 3589、2003年9月。
[RFC3606] Ly, F., Noto, M., Smith, A., Spiegel, E., and K. Tesink, "Definitions of Supplemental Managed Objects for ATM Interface", RFC 3606, November 2003.
[RFC3606] Ly、F.、Noto、M.、Smith、A.、Spiegel、E。、およびK. Tesink、「Definions of Supplemental Managed Objects for ATM Interface」、RFC 3606、2003年11月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R。、「IPv6の動的ホスト構成プロトコル（DHCPv6）のDNS構成オプション」、RFC 3646、2003年12月。
[RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004.
[RFC3729] Waldbusser、S。、「アプリケーションパフォーマンス測定MIB」、RFC 3729、2004年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、「Extensible Authentication Protocol（EAP）」、RFC 3748、2004年6月。
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
[RFC3758]スチュワート、R。、ラマーリョ、M。、シェ、Q。、テューセン、M。、およびP.コンラッド、「Stream Control Transmission Protocol（SCTP）Partial Reliability Extension」、RFC 3758、2004年5月。
[RFC3868] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., Keller, J., and B. Bidulock, "Signalling Connection Control Part User Adaptation Layer (SUA)", RFC 3868, October 2004.
[RFC3868] Loughney、J.、Sidebottom、G.、Coene、L.、Verwimp、G.、Keller、J。、およびB. Bidulock、「Signalling Connection Control Part User Adaptation Layer（SUA）」、RFC 3868、10月2004年
[RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)", RFC 3873, September 2004.
[RFC3873]牧師、J。およびM. Belinchon、「ストリーム制御伝送プロトコル（SCTP）管理情報ベース（MIB）」、RFC 3873、2004年9月。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3877] Chisholm、S。およびD. Romascanu、「Alarm Management Information Base（MIB）」、RFC 3877、2004年9月。
[RFC3878] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting Control Management Information Base (MIB)", RFC 3878, September 2004.
[RFC3878] Lam、H.、Huynh、A。、およびD. Perkins、「Alarm Reporting Control Management Information Base（MIB）」、RFC 3878、2004年9月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B。、およびS. Zander、「IPフロー情報エクスポート（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B。、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月。
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, August 2005.
[RFC4004] Calhoun、P.、Johansson、T.、Perkins、C.、Hiller、T。、およびP. McCann、「Diameter Mobile IPv4 Application」、RFC 4004、2005年8月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005.
[RFC4006] Hakala、H.、Mattila、L.、Koskinen、J-P。、Stura、M。、およびJ. Loughney、「Diameter Credit-Control Application」、RFC 4006、2005年8月。
[RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
[RFC4022]ラグナラヤン、R。、「伝送制御プロトコル（TCP）の管理情報ベース」、RFC 4022、2005年3月。
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[RFC4029] Lind、M.、Ksinant、V.、Park、S.、Baudot、A。、およびP. Savola、「ISPネットワークにIPv6を導入するためのシナリオと分析」、RFC 4029、2005年3月。
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[RFC4038] Shin、M-K。、Hong、Y-G。、Hagino、J.、Savola、P。、およびE. Castro、「IPv6移行のアプリケーションアスペクト」、RFC 4038、2005年3月。
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[RFC4057] Bound、J。、「IPv6 Enterprise Network Scenarios」、RFC 4057、2005年6月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「Diameter Extensible Authentication Protocol（EAP）Application」、RFC 4072、2005年8月。
[RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, June 2005.
[RFC4113] Fenner、B。およびJ. Flick、「ユーザーデータグラムプロトコル（UDP）の管理情報ベース」、RFC 4113、2005年6月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118] Yang、L.、Zerfos、P。、およびE. Sadot、「ワイヤレスアクセスポイントの制御とプロビジョニングのためのアーキテクチャ分類法（CAPWAP）」、RFC 4118、2005年6月。
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
[RFC4133] Bierman、A。およびK. McCloghrie、「Entity MIB（Version 3）」、RFC 4133、2005年8月。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005.
[RFC4148]ステファン、E。、「IP Performance Metrics（IPPM）Metrics Registry」、BCP 108、RFC 4148、2005年8月。
[RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005.
[RFC4150] Dietz、R。およびR. Cole、「Transport Performance Metrics MIB」、RFC 4150、2005年8月。
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005.
[RFC4188] Norseth、K。およびE. Bell、「ブリッジの管理対象オブジェクトの定義」、RFC 4188、2005年9月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmark、E。およびR. Gilligan、「IPv6ホストおよびルーターの基本的な移行メカニズム」、RFC 4213、2005年10月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215] Wiljakka、J。、「Analysis on IPv6 Transition in Third Generation Partnership Project（3GPP）Networks」、RFC 4215、2005年10月。
[RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", RFC 4221, November 2005.
[RFC4221] Nadeau、T.、Srinivasan、C。、およびA. Farrel、「Multiprotocol Label Switching（MPLS）Management Overview」、RFC 4221、2005年11月。
[RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", RFC 4268, November 2005.
[RFC4268] Chisholm、S。およびD. Perkins、「Entity State MIB」、RFC 4268、2005年11月。
[RFC4273] Haas, J. and S. Hares, "Definitions of Managed Objects for BGP-4", RFC 4273, January 2006.
[RFC4273] Haas、J。およびS. Hares、「Definions of Managed Objects for BGP-4」、RFC 4273、2006年1月。
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005.
[RFC4280] Chowdhury、K.、Yegani、P。、およびL. Madour、「ブロードキャストおよびマルチキャスト制御サーバーの動的ホスト構成プロトコル（DHCP）オプション」、RFC 4280、2005年11月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「Authentication Protocol for Mobile IPv6」、RFC 4285、2006年1月。
[RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 2006.
[RFC4292] Haberman、B。、「IP Forwarding Table MIB」、RFC 4292、2006年4月。
[RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006.
[RFC4293] Routhier、S。、「インターネットプロトコル（IP）の管理情報ベース」、RFC 4293、2006年4月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4318] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", RFC 4318, December 2005.
[RFC4318] Levi、D。およびD. Harrington、「Rapid Spanning Tree Protocolを使用したブリッジの管理対象オブジェクトの定義」、RFC 4318、2005年12月。
[RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006.
[RFC4363] Levi、D。およびD. Harrington、「トラフィッククラス、マルチキャストフィルタリング、および仮想LAN拡張機能を備えたブリッジの管理対象オブジェクトの定義」、RFC 4363、2006年1月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4444] Parker, J., "Management Information Base for Intermediate System to Intermediate System (IS-IS)", RFC 4444, April 2006.
[RFC4444]パーカーJ.、「中間システムから中間システム（IS-IS）の管理情報ベース」、RFC 4444、2006年4月。
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006.
[RFC4502] Waldbusser、S。、「リモートネットワーク監視管理情報ベースバージョン2」、RFC 4502、2006年5月。
[RFC4546] Raftus, D. and E. Cardona, "Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces", RFC 4546, June 2006.
[RFC4546] Raftus、D。、およびE. Cardona、「Data over Cable Service Interface Specification（DOCSIS）2.0準拠のRFインターフェイス用の無線周波数（RF）インターフェイス管理情報ベース」、RFC 4546、2006年6月。
[RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, June 2006.
[RFC4560] Quittek、J.およびK. White、「Definions of Managed Objects for Remote Ping、Traceroute、and Lookup Operations」、RFC 4560、2006年6月。
[RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, "Objectives for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4564, July 2006.
[RFC4564] Govindan、S.、Cheng、H.、Yao、ZH。、Zhou、WH。、and L. Yang、 "Objectives for Control and Provisioning of Wireless Access Points（CAPWAP）"、RFC 4564、July 2006。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「A One-way Active Measurement Protocol（OWAMP）」、RFC 4656、2006年9月。
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC4663]ハリントン、D。、「IETFブリッジMIB WGからIEEE 802.1 WGへのMIB作業の転送」、RFC 4663、2006年9月。
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006.
[RFC4668] Nelson、D。、「RADIUS Authentication Client MIB for IPv6」、RFC 4668、2006年8月。
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006.
[RFC4669] Nelson、D。、「RADIUS Authentication Server MIB for IPv6」、RFC 4669、2006年8月。
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006.
[RFC4670]ネルソン、D。、「IPv6のRADIUSアカウンティングクライアントMIB」、RFC 4670、2006年8月。
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006.
[RFC4671] Nelson、D。、「RADIUS Accounting Server MIB for IPv6」、RFC 4671、2006年8月。
[RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Client MIB", RFC 4672, September 2006.
[RFC4672] De Cnodder、S.、Jonnala、N。、およびM. Chiba、「RADIUS Dynamic Authorization Client MIB」、RFC 4672、2006年9月。
[RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS Dynamic Authorization Server MIB", RFC 4673, September 2006.
[RFC4673] De Cnodder、S.、Jonnala、N。、およびM. Chiba、「RADIUS Dynamic Authorization Server MIB」、RFC 4673、2006年9月。
[RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
[RFC4675] Congdon、P.、Sanchez、M。、およびB. Aboba、「仮想LANおよび優先度サポートのRADIUS属性」、RFC 4675、2006年9月。
[RFC4706] Morgenstern, M., Dodge, M., Baillie, S., and U. Bonollo, "Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2)", RFC 4706, November 2006.
[RFC4706] Morgenstern、M.、Dodge、M.、Baillie、S。、およびU. Bonollo、「Definions of Managed Objects for Asymmetric Digital Subscriber Line 2（ADSL2）」、RFC 4706、2006年11月。
[RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006.
[RFC4710] Siddiqui、A.、Romascanu、D。、およびE. Golovinsky、「Real-time Application Quality-of-Service Monitoring（RAQMON）Framework」、RFC 4710、2006年10月。
[RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) MIB", RFC 4711, October 2006.
[RFC4711] Siddiqui、A.、Romascanu、D。、およびE. Golovinsky、「Real-time Application Quality-of-Service Monitoring（RAQMON）MIB」、RFC 4711、2006年10月。
[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., and Y. Kim, "Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)", RFC 4712, October 2006.
[RFC4712] Siddiqui、A.、Romascanu、D.、Golovinsky、E.、Rahman、M。、およびY. Kim、「リアルタイムアプリケーションのサービス品質監視（RAQMON）プロトコルデータユニット（PDUのトランスポートマッピング） ） "、RFC 4712、2006年10月。
[RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[RFC4737] Morton、A.、Ciavattone、L.、Ramachandran、G.、Shalunov、S。、およびJ. Perser、「Packet Reordering Metrics」、RFC 4737、2006年11月。
[RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales-Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006.
[RFC4740] Garcia-Martin、M.、Belinchon、M.、Pallares-Lopez、M.、Canales-Valenzuela、C。、およびK. Tammi、「Diameter Session Initiation Protocol（SIP）Application」、RFC 4740、2006年11月。
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
[RFC4743] Goddard、T。、「シンプルオブジェクトアクセスプロトコル（SOAP）を介したNETCONFの使用」、RFC 4743、2006年12月。
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4744] Lear、E。、およびK. Crozier、「Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol（BEEP）」、RFC 4744、2006年12月。
[RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
[RFC4750] Joyal、D.、Galecki、P.、Giacarone、S.、Coltun、R。、およびF. Baker、「OSPFバージョン2管理情報ベース」、RFC 4750、2006年12月。
[RFC4780] Lingle, K., Mule, J-F., Maeng, J., and D. Walker, "Management Information Base for the Session Initiation Protocol (SIP)", RFC 4780, April 2007.
[RFC4780] Lingle、K.、Mule、J-F。、Maeng、J。、およびD. Walker、「Session Initiation Protocol（SIP）の管理情報ベース」、RFC 4780、2007年4月。
[RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, November 2006.
[RFC4789] Schoenwaelder、J。およびT. Jeffree、「Simple Network Management Protocol（SNMP）over IEEE 802 Networks」、RFC 4789、2006年11月。
[RFC4803] Nadeau, T. and A. Farrel, "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007.
[RFC4803]ナドー、T。およびA.ファレル、「汎用マルチプロトコルラベルスイッチング（GMPLS）ラベルスイッチングルーター（LSR）管理情報ベース」、RFC 4803、2007年2月。
[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6- Prefix Attribute", RFC 4818, April 2007.
[RFC4818] Salowey、J。およびR. Droms、「RADIUS Delegated-IPv6- Prefix Attribute」、RFC 4818、2007年4月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「Extensible Markup Language（XML）Configuration Access Protocol（XCAP）」、RFC 4825、2007年5月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826] Rosenberg、J。、「リソースリストを表すためのExtensible Markup Language（XML）形式」、RFC 4826、2007年5月。
[RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents", RFC 4827, May 2007.
[RFC4827] Isomaki、M。およびE. Leppanen、「Extensible Markup Language（XML）Configuration Access Protocol（XCAP）Usage for Manipulating Presence Document Contents」、RFC 4827、2007年5月。
[RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP Extended Statistics MIB", RFC 4898, May 2007.
[RFC4898] Mathis、M.、Heffner、J。、およびR. Raghunarayan、「TCP Extended Statistics MIB」、RFC 4898、2007年5月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., and A. Kessler, "Protocol Independent Multicast MIB", RFC 5060, January 2008.
[RFC5060] Sivaramu、R.、Lingard、J.、McWalter、D.、Joshi、B。、およびA. Kessler、「Protocol Independent Multicast MIB」、RFC 5060、2008年1月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. DeKok、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と推奨される修正」、RFC 5080、2007年12月。
[RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085]ナドー、T。およびC.ピグナタロ、「疑似配線仮想回線接続検証（VCCV）：疑似配線の制御チャネル」、RFC 5085、2007年12月。
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, February 2008.
[RFC5090]スターマン、B。、サドレフスキー、D。、シュワルツ、D。、ウィリアムズ、D。、およびW.ベック、「RADIUS Extension for Digest Authentication」、RFC 5090、2008年2月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103] Trammell、B。およびE. Boschi、「IPフロー情報エクスポート（IPFIX）を使用した双方向フローエクスポート」、RFC 5103、2008年1月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
[RFC5176]千葉、M.、Dommety、G.、Eklund、M.、Mitton、D。、およびB. Aboba、「リモート認証ダイヤルインユーザーサービス（RADIUS）への動的承認拡張機能」、RFC 5176、2008年1月。
[RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
[RFC5181] Shin、M-K。、Han、Y-H。、Kim、S-E。、およびD. Premec、「802.16ネットワークにおけるIPv6導入シナリオ」、RFC 5181、2008年5月。
[RFC5224] Brenner, M., "Diameter Policy Processing Application", RFC 5224, March 2008.
[RFC5224] Brenner、M。、「Diameter Policy Processing Application」、RFC 5224、2008年3月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008.
[RFC5277] Chisholm、S。およびH. Trevino、「NETCONFイベント通知」、RFC 5277、2008年7月。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October 2008.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、2008年10月。
[RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., and M. Swany, "Information Model and XML Data Model for Traceroute Measurements", RFC 5388, December 2008.
[RFC5388] Niccolini、S.、Tartarelli、S.、Quittek、J.、Dietz、T。、およびM. Swany、「トレースルート測定の情報モデルとXMLデータモデル」、RFC 5388、2008年12月。
[RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009.
[RFC5415] Calhoun、P.、Montemurro、M。、およびD. Stanley、「Control and Provisioning of Wireless Access Points（CAPWAP）Protocol Specification」、RFC 5415、2009年3月。
[RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009.
[RFC5416] Calhoun、P.、Montemurro、M。、およびD. Stanley、「IEEE 802.11のワイヤレスアクセスポイント（CAPWAP）プロトコルバインディングの制御とプロビジョニング」、RFC 5416、2009年3月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslogプロトコル」、RFC 5424、2009年3月。
[RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer Security (TLS) Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5425] Miao、F.、Ma、Y。、およびJ. Salowey、「Syslogのトランスポート層セキュリティ（TLS）トランスポートマッピング」、RFC 5425、2009年3月。
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426] Okmianski、A。、「UDPを介したSyslogメッセージの送信」、RFC 5426、2009年3月。
[RFC5427] Keeni, G., "Textual Conventions for Syslog Management", RFC 5427, March 2009.
[RFC5427] Keeni、G。、「Syslog Managementのテキスト表記法」、RFC 5427、2009年3月。
[RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface Application", RFC 5431, March 2009.
[RFC5431] Sun、D。、「Diameter ITU-T Rw Policy Enforcement Interface Application」、RFC 5431、2009年3月。
[RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C., and K. Chowdhury, "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction", RFC 5447, February 2009.
[RFC5447] Korhonen、J.、Bournelle、J.、Tschofenig、H.、Perkins、C。、およびK. Chowdhury、「Diameter Mobile IPv6：Support for Network Access Server to Diameter Server Interaction」、RFC 5447、2009年2月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、Brownlee、N.、Claise、B。、およびJ. Quittek、「Architecture for IP Flow Information Export」、RFC 5470、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、RFC 5472、2009年3月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473] Boschi、E.、Mark、L。、およびB. Claise、「Reduce Redundancy in IP Flow Information Export（IPFIX）and Packet Sampling（PSAMP）Reports」、RFC 5473、2009年3月。
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474] Duffield、N.、Chiou、D.、Claise、B.、Greenberg、A.、Grossglauser、M。、およびJ. Rexford、「A Framework for Packet Selection and Reporting」、RFC 5474、2009年3月。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S。、およびF. Raspall、「IPパケット選択のためのサンプリングおよびフィルタリング技術」、RFC 5475、2009年3月。
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、Johnson、A。、およびJ. Quittek、「Packet Sampling（PSAMP）Protocol Specifications」、RFC 5476、2009年3月。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009.
[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F。、およびG. Carle、「パケットサンプリングエクスポートの情報モデル」、RFC 5477、2009年3月。
[RFC5516] Jones, M. and L. Morand, "Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 5516, April 2009.
[RFC5516]ジョーンズ、M.、L。モランド、「第3世代パートナーシッププロジェクト（3GPP）の進化したパケットシステム（EPS）の直径コマンドコード登録」、RFC 5516、2009年4月。
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009.
[RFC5539] Badra、M。、「NETCONF over Transport Layer Security（TLS）」、RFC 5539、2009年5月。
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009.
[RFC5560] Uijterwaal、H。、「A One-Way Packet Duplication Metric」、RFC 5560、2009年5月。
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
[RFC5580] Tschofenig、H.、Adrangi、F.、Jones、M.、Lior、A。、およびB. Aboba、「RADIUSおよびDiameterでのロケーションオブジェクトの持ち運び」、RFC 5580、2009年8月。
[RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009.
[RFC5590] Harrington、D.およびJ. Schoenwaelder、「Transport Subsystem for the Simple Network Management Protocol（SNMP）」、RFC 5590、2009年6月。
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model for the Simple Network Management Protocol (SNMP)", RFC 5591, June 2009.
[RFC5591] Harrington、D.およびW. Hardaker、「Transport Security Model for the Simple Network Management Protocol（SNMP）」、RFC 5591、2009年6月。
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure Shell Transport Model for the Simple Network Management Protocol (SNMP)", RFC 5592, June 2009.
[RFC5592] Harrington、D.、Salowey、J。、およびW. Hardaker、「Secure Network Transport Model for the Simple Network Management Protocol（SNMP）」、RFC 5592、2009年6月。
[RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management", RFC 5607, July 2009.
[RFC5607]ネルソン、D。およびG.ウェーバー、「ネットワークアクセスサーバー（NAS）管理用のリモート認証ダイヤルインユーザーサービス（RADIUS）承認」、RFC 5607、2009年7月。
[RFC5608] Narayan, K. and D. Nelson, "Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models", RFC 5608, August 2009.
[RFC5608]ナラヤン、K。およびD.ネルソン、「簡易ネットワーク管理プロトコル（SNMP）トランスポートモデルのリモート認証ダイヤルインユーザーサービス（RADIUS）の使用」、RFC 5608、2009年8月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610] Boschi、E.、Trammell、B.、Mark、L。、およびT. Zseby、「Exporting Type Information for IP Flow Information Export（IPFIX）Information Elements」、RFC 5610、2009年7月。
[RFC5650] Morgenstern, M., Baillie, S., and U. Bonollo, "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", RFC 5650, September 2009.
[RFC5650] Morgenstern、M.、Baillie、S。、およびU. Bonollo、「Definions of Managed Objects for Very High Speed Digital Subscriber Line 2（VDSL2）」、RFC 5650、2009年9月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「Specification of the IP Flow Information Export（IPFIX）File Format」、RFC 5655、2009年10月。
[RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog", RFC 5674, October 2009.
[RFC5674] Chisholm、S。およびR. Gerhards、「Alarms in Syslog」、RFC 5674、2009年10月。
[RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages", RFC 5675, October 2009.
[RFC5675] Marinov、V。およびJ. Schoenwaelder、「Simple Network Management Protocol（SNMP）Notifications to SYSLOG Messages」、RFC 5675、2009年10月。
[RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications", RFC 5676, October 2009.
[RFC5676] Schoenwaelder、J.、Clemm、A。、およびA. Karmakar、「SYSLOGメッセージを簡易ネットワーク管理プロトコル（SNMP）通知にマッピングするための管理対象オブジェクトの定義」、RFC 5676、2009年10月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]ハリントンD.、「新しいプロトコルとプロトコル拡張の操作と管理を検討するためのガイドライン」、RFC 5706、2009年11月。
[RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", RFC 5713, January 2010.
[RFC5713] Moustafa、H.、Tschofenig、H。、およびS. De Cnodder、「セキュリティ脅威およびAccess Node Control Protocol（ANCP）のセキュリティ要件」、RFC 5713、2010年1月。
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009.
[RFC5717] Lengyel、B。およびM. Bjorklund、「NETCONFの部分ロックリモートプロシージャコール（RPC）」、RFC 5717、2009年12月。
[RFC5719] Romascanu, D. and H. Tschofenig, "Updated IANA Considerations for Diameter Command Code Allocations", RFC 5719, January 2010.
[RFC5719] Romascanu、D。、およびH. Tschofenig、「Diameterコマンドコード割り当てに関する更新されたIANAの考慮事項」、RFC 5719、2010年1月。
[RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, "Clarifications on the Routing of Diameter Requests Based on the Username and the Realm", RFC 5729, December 2009.
[RFC5729] Korhonen、J.、Jones、M.、Morand、L。、およびT. Tsou、「ユーザー名とレルムに基づくDiameterリクエストのルーティングに関する説明」、RFC 5729、2009年12月。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, February 2010.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、and A. Lior、 "Traffic Classification and Quality of Service（QoS）Attributes for Diameter"、RFC 5777、February 2010。
[RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, February 2010.
[RFC5778] Korhonen、J.、Tschofenig、H.、Bournelle、J.、Giaretta、G。、およびM. Nakhjiri、「Diameter Mobile IPv6：Support for Home Agent to Diameter Server Interaction」、RFC 5778、2010年2月。
[RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", RFC 5779, February 2010.
[RFC5779] Korhonen、J.、Bournelle、J.、Chowdhury、K.、Muhanna、A。、およびU. Meyer、「Diameter Proxy Mobile IPv6：Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server」、RFC 5779、 2010年2月。
[RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, "Definitions of Managed Objects for IP Flow Information Export", RFC 5815, April 2010.
[RFC5815] Dietz、T.、Kobayashi、A.、Claise、B。、およびG. Muenz、「Defineions of Managed Objects for IP Flow Information Export」、RFC 5815、2010年4月。
[RFC5833] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB", RFC 5833, May 2010.
[RFC5833] Shi、Y.、Perkins、D.、Elliott、C。、およびY. Zhang、「ワイヤレスアクセスポイント（CAPWAP）プロトコルベースMIBの制御とプロビジョニング」、RFC 5833、2010年5月。
[RFC5834] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11", RFC 5834, May 2010.
[RFC5834] Shi、Y.、Perkins、D.、Elliott、C。、およびY. Zhang、「IEEE 802.11用のワイヤレスアクセスポイント（CAPWAP）プロトコルバインディングMIBの制御とプロビジョニング」、RFC 5834、2010年5月。
[RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric Composition", RFC 5835, April 2010.
[RFC5835] Morton、A.およびS. Van den Berghe、「Framework for Metric Composition」、RFC 5835、2010年4月。
[RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog Messages", RFC 5848, May 2010.
[RFC5848] Kelsey、J.、Callas、J。、およびA. Clemm、「Signed Syslog Messages」、RFC 5848、2010年5月。
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010.
[RFC5851] Ooghe、S.、Voigt、N.、Platnic、M.、Haag、T。、およびS. Wadhwa、「フレームワークとブロードバンドマルチサービスネットワークにおけるアクセスノード制御メカニズムの要件」、RFC 5851、5月2010。
[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., and G. Zorn, "Diameter Quality-of-Service Application", RFC 5866, May 2010.
[RFC5866] Sun、D.、McCann、P.、Tschofenig、H.、Tsou、T.、Doria、A。、およびG. Zorn、「Diameter Quality-of-Service Application」、RFC 5866、2010年5月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad Hoc Networks", RFC 5889, September 2010.
[RFC5889] Baccelli、E。およびM. Townsley、「アドホックネットワークのIPアドレッシングモデル」、RFC 5889、2010年9月。
[RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export (IPFIX) Mediation: Problem Statement", RFC 5982, August 2010.
[RFC5982]小林、A。およびB. Claise、「IPフロー情報エクスポート（IPFIX）調停：問題の説明」、RFC 5982、2010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「インターネットキー交換プロトコルバージョン2（IKEv2）」、RFC 5996、2010年9月。
[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, "Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog", RFC 6012, October 2010.
[RFC6012] Salowey、J.、Petch、T.、Gerhards、R。、およびH. Feng、「Syslogのデータグラムトランスポート層セキュリティ（DTLS）トランスポートマッピング」、RFC 6012、2010年10月。
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M。、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J。、「Common YANG Data Types」、RFC 6021、2010年10月。
[RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF Monitoring", RFC 6022, October 2010.
[RFC6022] Scott、M.およびM. Bjorklund、「YANG Module for NETCONF Monitoring」、RFC 6022、2010年10月。
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, November 2010.
[RFC6035]ペンドルトン、A。、クラーク、A。、ジョンストン、A。、およびH.シンライヒ、「音声品質レポート用のセッション開始プロトコルイベントパッケージ」、RFC 6035、2010年11月。
[RFC6065] Narayan, K., Nelson, D., and R. Presuhn, "Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings", RFC 6065, December 2010.
[RFC6065] Narayan、K.、Nelson、D。、およびR. Presuhn、「Authentication、Authorization、およびAccounting Servicesを使用して、ビューベースのアクセスコントロールモデルのユーザーからグループへのマッピングを動的にプロビジョニングする」、RFC 6065、2010年12月。
[RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG Data Model Documents", RFC 6087, January 2011.
[RFC6087] Bierman、A。、「YANG Data Model Documentsの作成者とレビューアーのためのガイドライン」、RFC 6087、2011年1月。
[RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending YANG with Language Abstractions", RFC 6095, March 2011.
[RFC6095] Linowski、B.、Ersue、M。、およびS. Kuryla、「Extending YANG with Language Abstractions」、RFC 6095、2011年3月。
[RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", RFC 6110, February 2011.
[RFC6110] Lhotka、L。、「スキーマ定義言語を文書化するためのYANGのマッピングとNETCONFコンテンツの検証」、RFC 6110、2011年2月。
[RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158] DeKok、A。およびG. Weber、「RADIUS設計ガイドライン」、BCP 158、RFC 6158、2011年3月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]小林明朗、クレイズB.、ムエンツG.、石橋健二、「IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク」、RFC 6183、2011年4月。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011.
[RFC6235] Boschi、E。およびB. Trammell、「IP Flow Anonymization Support」、RFC 6235、2011年5月。
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R.、Bjorklund、M.、Schoenwaelder、J。、およびA. Bierman、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, June 2011.
[RFC6242] Wasserman、M。、「Secure Shell（SSH）上のNETCONFプロトコルの使用」、RFC 6242、2011年6月。
[RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, June 2011.
[RFC6244]シェーファー、P。、「NETCONFとYANGを使用したネットワーク管理のアーキテクチャ」、RFC 6244、2011年6月。
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 2011.
[RFC6248] Morton、A。、「RFC 4148およびIP Performance Metrics（IPPM）Registry of Metricsは廃止されました」、RFC 6248、2011年4月。
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011.
[RFC6272]ベイカー、F。およびD.マイヤー、「スマートグリッドのためのインターネットプロトコル」、RFC 6272、2011年6月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月。
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, "Protocol for Access Node Control Mechanism in Broadband Networks", RFC 6320, October 2011.
[RFC6320] Wadhwa、S.、Moisand、J.、Haag、T.、Voigt、N。、およびT. Taylor、「Protocol for Access Node Control Mechanism in Broadband Networks」、RFC 6320、2011年10月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)", RFC 6353, July 2011.
[RFC6353] Hardaker、W。、「簡易ネットワーク管理プロトコル（SNMP）のトランスポート層セキュリティ（TLS）トランスポートモデル」、RFC 6353、2011年7月。
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I。およびD. Allan、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
[RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage", RFC 6408, November 2011.
[RFC6408] Jones、M.、Korhonen、J。、およびL. Morand、「Diameter Straightforward-Naming Authority Pointer（S-NAPTR）Usage」、RFC 6408、2011年11月。
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, October 2011.
[RFC6410] Housley、R.、Crocker、D。、およびE. Burger、「Standard Tracks to Two Maturity Levels」、BCP 9、RFC 6410、2011年10月。
[RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream", RFC 6526, March 2012.
[RFC6526] Claise、B.、Aitken、P.、Johnson、A。、およびG. Muenz、「IP Flow Information Export（IPFIX）Per Stream Control Transmission Protocol（SCTP）Stream」、RFC 6526、2012年3月。
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012.
[RFC6536] Bierman、A。およびM. Bjorklund、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、2012年3月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月。
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012.
[RFC6613] DeKok、A。、「RADIUS over TCP」、RFC 6613、2012年5月。
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, May 2012.
[RFC6614] Winter、S.、McCauley、M.、Venaas、S.、and K. Wierenga、 "Transport Layer Security（TLS）Encryption for RADIUS"、RFC 6614、May 2012。
[RFCSEARCH] RFC Editor, "RFC Index Search Engine", <http://www.rfc-editor.org/rfcsearch.html>.
[RFCSEARCH] RFC Editor、「RFC Index Search Engine」、<http://www.rfc-editor.org/rfcsearch.html>。
[SMI-NUMBERS] IANA, "Network Management Parameters - SMI OID List", May 2012, <http://www.iana.org/assignments/smi-numbers>.
[SMI-NUMBERS] IANA、「Network Management Parameters-SMI OID List」、2012年5月、<http://www.iana.org/assignments/smi-numbers>。
[SMI-YANG] Schoenwaelder, J., "Translation of SMIv2 MIB Modules to YANG Modules", Work in Progress, April 2012.
[SMI-YANG] Schoenwaelder、J。、「SMIv2 MIBモジュールのYANGモジュールへの変換」、作業中、2012年4月。
[STD06] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[STD06] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、1980年8月。
[STD07] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[STD07] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。
[STD16] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/ IP-based internets", STD 16, RFC 1155, May 1990.
[STD16] Rose、M。、およびK. McCloghrie、「構造およびTCP / IPベースのインターネットの管理情報の識別」、STD 16、RFC 1155、1990年5月。
Rose, M. and K. McCloghrie, "Concise MIB definitions", STD 16, RFC 1212, March 1991.
Rose、M。、およびK. McCloghrie、「簡潔なMIB定義」、STD 16、RFC 1212、1991年3月。
[STD17] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991.
[STD17] McCloghrie、K。およびM. Rose、「TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、STD 17、RFC 1213、1991年3月。
[STD58] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[STD58] McCloghrie、K。、編、Perkins、D。、編、およびJ. Schoenwaelder、編、「Structure of Management Information Version 2（SMIv2）」、STD 58、RFC 2578、1999年4月。
McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、April 1999。
McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Conformance Statements for SMIv2"、STD 58、RFC 2580、April 1999。
[STD59] Waldbusser, S., "Remote Network Monitoring Management Information Base", STD 59, RFC 2819, May 2000.
[STD59] Waldbusser、S。、「リモートネットワーク監視管理情報ベース」、STD 59、RFC 2819、2000年5月。
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[STD62] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
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.
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。
Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
Levi、D.、Meyer、P。、およびB. Stewart、「Simple Network Management Protocol（SNMP）Applications」、STD 62、RFC 3413、2002年12月。
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.
Blumenthal、U。およびB. Wijnen、「Simple Network Management Protocol（SNMPv3）バージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
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.
Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「簡易ネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、STD 62、RFC 3415、2002年12月。
Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
Presuhn、R。、編、「簡易ネットワーク管理プロトコル（SNMP）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
Presuhn, R., Ed., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
Presuhn、R。、編、「簡易ネットワーク管理プロトコル（SNMP）のトランスポートマッピング」、STD 62、RFC 3417、2002年12月。
Presuhn, R., Ed., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
Presuhn、R。、編、「簡易ネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[STD66] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[XPATH] World Wide Web Consortium, "XML Path Language (XPath) Version 1.0", November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XPATH] World Wide Web Consortium、「XML Path Language（XPath）Version 1.0」、1999年11月、<http://www.w3.org/TR/1999/REC-xpath-19991116>。
[XSD-1] Beech, D., Thompson, H., Maloney, M., Mendelsohn, N., and World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, "XML Schema Part 1: Structures Second Edition", October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XSD-1]ビーチ、D。、トンプソン、H。、マロニー、M。、メンデルゾーン、N。、およびワールドワイドウェブコンソーシアム勧告REC-xmlschema-1-20041028、「XML Schema Part 1：Structures Second Edition」、 2004年10月、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>。
Appendix A. High-Level Classification of Management Protocols and Data Models
付録A.管理プロトコルとデータモデルの高レベルの分類
The following subsections aim to guide the reader for the fast selection of the management standard in interest and can be used as a dispatcher to forward to the appropriate chapter. The subsections below classify the protocols on one hand according to high-level criteria such as push versus pull mechanism, and passive versus active monitoring. On the other hand, the protocols are categorized concerning the network management task they address or the data model extensibility they provide. Based on the reader's requirements, a reduced set of standard protocols and associated data models can be selected for further reading.
次のサブセクションは、対象となる管理標準をすばやく選択するためのガイドであり、適切な章に進むためのディスパッチャとして使用できます。以下のサブセクションでは、プッシュ対プルメカニズム、パッシブ対アクティブモニタリングなどの高レベルの基準に従って、一方でプロトコルを分類します。一方、プロトコルは、それらが対処するネットワーク管理タスクまたはそれらが提供するデータモデルの拡張性に関して分類されます。読者の要件に基づいて、標準プロトコルと関連するデータモデルの削減されたセットを選択して、さらに読むことができます。
As an example, someone outside of IETF typically would look for the TWAMP protocol in the Operations and Management Area working groups as it addresses performance management. However, the protocol TWAMP has been developed by the IPPM working group in the Transport Area.
例として、IETFの外部にいる誰かが、パフォーマンス管理に取り組むときに、運用および管理領域のワーキンググループでTWAMPプロトコルを探すのが一般的です。ただし、プロトコルTWAMPは、トランスポートエリアのIPPMワーキンググループによって開発されました。
Note that not all protocols have been listed in all classification sections. Some of the protocols, especially the protocols with specific focus in Section 3 cannot be clearly classified. Note also that COPS and COPS-PR are not listed in the tables, as COPS-PR is not recommended to use (see Section 3.3).
すべてのプロトコルがすべての分類セクションにリストされているわけではないことに注意してください。一部のプロトコル、特にセクション3で特に重点が置かれているプロトコルは、明確に分類できません。 COPS-PRの使用は推奨されていないため（セクション3.3を参照）、COPSおよびCOPS-PRは表に記載されていません。
This section classifies the management protocols according their standard maturity in the IETF. The IETF standard maturity levels Proposed, Draft, or Internet Standard, are defined in [RFC2026] (as amended by [RFC6410]). An Internet Standard is characterized by a high degree of technical maturity and by a generally held belief that the specified protocol or service provides significant benefit to the Internet community.
このセクションでは、IETFでの標準的な成熟度に従って管理プロトコルを分類します。 IETF標準の成熟度レベルProposed、Draft、またはInternet Standardは、[RFC2026]で定義されています（[RFC6410]によって修正）。インターネット標準の特徴は、高度な技術的成熟と、指定されたプロトコルまたはサービスがインターネットコミュニティに大きな利益をもたらすと一般に信じられていることです。
The table below covers the standard maturity of the different protocols listed in this document. Note that only the main protocols (and not their extensions) are noted. An RFC search tool listing the current document status is available at [RFCSEARCH].
次の表は、このドキュメントに記載されているさまざまなプロトコルの標準的な成熟度を示しています。記載されているのはメインプロトコルのみであり、拡張子は記載されていないことに注意してください。現在のドキュメントステータスをリストするRFC検索ツールは、[RFCSEARCH]から入手できます。
+---------------------------------------------+---------------------+
| Protocol | Maturity Level |
+---------------------------------------------+---------------------+
| SNMP [STD62][RFC3411] (Section 2.1) | Internet Standard |
| | |
| Syslog [RFC5424] (Section 2.2) | Proposed Standard |
| | |
| IPFIX [RFC5101] (Section 2.3) | Proposed Standard |
| | |
| PSAMP [RFC5476] (Section 2.3) | Proposed Standard |
| | |
| NETCONF [RFC6241] (Section 2.4.1) | Proposed Standard |
| | |
| DHCP for IPv4 [RFC2131] (Section 3.1.1) | Draft Standard |
| | |
| DHCP for IPv6 [RFC3315] (Section 3.1.1) | Proposed Standard |
| | |
| OWAMP [RFC4656] (Section 3.4) | Proposed Standard |
| | |
| TWAMP [RFC5357] (Section 3.4) | Proposed Standard |
| | |
| RADIUS [RFC2865] (Section 3.5) | Draft Standard |
| | |
| Diameter [RFC3588] (Section 3.6) | Proposed Standard |
| | |
| CAPWAP [RFC5416] (Section 3.7) | Proposed Standard |
| | |
| ANCP [RFC6320] (Section 3.8) | Proposed Standard |
| | |
| Ad hoc network configuration [RFC5889] | Informational |
| (Section 3.1.2) | |
| | |
| ACAP [RFC2244] (Section 3.9) | Proposed Standard |
| | |
| XCAP [RFC4825] (Section 3.10) | Proposed Standard |
+---------------------------------------------+---------------------+
Table 1: Protocols Classified by Standard Maturity in the IETF
表1：IETFの標準的な成熟度によって分類されたプロトコル
This subsection classifies the management protocols matching to the management tasks for fault, configuration, accounting, performance, and security management.
このサブセクションでは、障害、構成、アカウンティング、パフォーマンス、およびセキュリティ管理の管理タスクに一致する管理プロトコルを分類します。
+------------+------------+-------------+--------------+------------+
| Fault Mgmt | Config. | Accounting | Performance | Security |
| | Mgmt | Mgmt | Mgmt | Mgmt |
+------------+------------+-------------+--------------+------------+
| SNMP | SNMP | SNMP | SNMP | |
| notif. | config. | monitoring | monitoring | |
| with trap | with set | with get | with get | |
| operation | operation | operation | operation | |
| (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1) | |
| | | | | |
| IPFIX | CAPWAP | IPFIX | IPFIX | |
| (S. 2.3) | (S. 3.7) | (S. 2.3) | (S. 2.3) | |
| | | | | |
| PSAMP | NETCONF | PSAMP | PSAMP | |
| (S. 2.3) | (S. 2.4.1) | (S. 2.3) | (S. 2.3) | |
| | | | | |
| Syslog | ANCP | RADIUS | | RADIUS |
| (S. 2.2) | (S. 3.8) | Accounting | | Authent.& |
| | | (S. 3.5) | | Authoriz. |
| | | | | (S. 3.5) |
| | | | | |
| | AUTOCONF | Diameter | | Diameter |
| | (S. 3.1.2) | Accounting | | Authent.& |
| | | (S. 3.6) | | Authoriz. |
| | | | | (S. 3.6) |
| | | | | |
| | ACAP | | | |
| | (S. 3.9) | | | |
| | | | | |
| | XCAP | | | |
| | (S. 3.10) | | | |
| | | | | |
| | DHCP | | | |
| | (S. 3.1.1) | | | |
+------------+------------+-------------+--------------+------------+
Table 2: Protocols Matched to Management Tasks
表2：管理タスクに一致するプロトコル
Note: Corresponding section numbers are given in parentheses.
注：対応するセクション番号は括弧内に示されています。
A pull mechanism is characterized by the Network Management System (NMS) pulling the management information out of network elements, when needed. A push mechanism is characterized by the network elements pushing the management information to the NMS, either when the information is available or on a regular basis.
プルメカニズムの特徴は、必要に応じて、ネットワーク管理システム（NMS）がネットワーク要素から管理情報を引き出すことです。プッシュメカニズムの特徴は、ネットワーク要素が管理情報をNMSにプッシュすることです。
Client/Server protocols, such as DHCP, ANCP, ACAP, and XCAP are not listed in Table 3.
DHCP、ANCP、ACAP、XCAPなどのクライアント/サーバープロトコルは、表3にリストされていません。
+---------------------------------+---------------------------------+
| Protocols supporting the Pull | Protocols supporting the Push |
| mechanism | mechanism |
+---------------------------------+---------------------------------+
| SNMP (except notifications) | SNMP notifications |
| (Section 2.1) | (Section 2.1) |
| NETCONF (except notifications) | NETCONF notifications |
| (Section 2.4.1) | (Section 2.4.1) |
| CAPWAP (Section 3.7) | Syslog (Section 2.2) |
| | IPFIX (Section 2.3) |
| | PSAMP (Section 2.3) |
| | RADIUS accounting |
| | (Section 3.5) |
| | Diameter accounting |
| | (Section 3.6) |
+---------------------------------+---------------------------------+
Table 3: Protocol Classification by Push versus Pull Mechanism
表3：プッシュメカニズムとプルメカニズムによるプロトコル分類
Monitoring can be divided into two categories: passive and active monitoring. Passive monitoring can perform the network traffic monitoring, monitoring of a device, or the accounting of network resource consumption by users. Active monitoring, as used in this document, focuses mainly on active network monitoring and relies on the injection of specific traffic (also called "synthetic traffic"), which is then monitored. The monitoring focus is indicated in the table below as "network", "device", or "accounting".
監視は、パッシブ監視とアクティブ監視の2つのカテゴリに分類できます。パッシブモニタリングでは、ネットワークトラフィックのモニタリング、デバイスのモニタリング、またはユーザによるネットワークリソース消費のアカウンティングを実行できます。このドキュメントで使用されているアクティブモニタリングは、主にアクティブネットワークモニタリングに重点を置いており、特定のトラフィック（「合成トラフィック」とも呼ばれます）の注入に依存しており、その後監視されます。監視対象は、以下の表で「ネットワーク」、「デバイス」、または「アカウンティング」として示されています。
This classification excludes non-monitoring protocols, such as configuration protocols: Ad hoc network autoconfiguration, ANCP, and XCAP. Note that some of the active monitoring protocols, in the context of the data path, e.g., ICMP Ping and Traceroute [RFC1470], Bidirectional Forwarding Detection (BFD) [RFC5880], and PWE3 Virtual Circuit Connectivity Verification (VCCV) [RFC5085] are covered in [OAM-OVERVIEW].
この分類では、構成プロトコル（アドホックネットワーク自動構成、ANCP、XCAP）などの非監視プロトコルは除外されます。 ICMP PingおよびTraceroute [RFC1470]、Bidirectional Forwarding Detection（BFD）[RFC5880]、およびPWE3 Virtual Circuit Connectivity Verification（VCCV）[RFC5085]などのデータパスのコンテキストでは、アクティブモニタリングプロトコルの一部が[OAM-OVERVIEW]で説明されています。
+---------------------------------+---------------------------------+
| Protocols supporting passive | Protocols supporting active |
| monitoring | monitoring |
+---------------------------------+---------------------------------+
| IPFIX (network) (Section 2.3) | OWAMP (network) (Section 3.4) |
| PSAMP (network) (Section 2.3) | TWAMP (network) (Section 3.4) |
| SNMP (network and device) | |
| (Section 2.1) | |
| NETCONF (device) | |
| (Section 2.4.1) | |
| RADIUS (accounting) | |
| (Section 3.5) | |
| Diameter (accounting) | |
| (Section 3.6) | |
| CAPWAP (device) (Section 3.7) | |
+---------------------------------+---------------------------------+
Table 4: Protocols for Passive and Active Monitoring and Their Monitoring Focus
表4：パッシブおよびアクティブモニタリングのプロトコルとそのモニタリングの焦点
The application of SNMP to passive traffic monitoring (e.g., with RMON-MIB) or active monitoring (with IPPM MIB) depends on the MIB modules used. However, the SNMP protocol itself does not have operations, which support active monitoring. NETCONF can be used for passive monitoring, e.g., with the NETCONF Monitoring YANG module [RFC6022] for the monitoring of the NETCONF protocol. CAPWAP monitors the status of a Wireless Termination Point.
パッシブトラフィックモニタリング（RMON-MIBなど）またはアクティブモニタリング（IPPM MIB）へのSNMPの適用は、使用するMIBモジュールによって異なります。ただし、SNMPプロトコル自体には、アクティブな監視をサポートする操作はありません。 NETCONFはパッシブモニタリングに使用できます。たとえば、NETCONFプロトコルのモニタリング用のNETCONFモニタリングYANGモジュール[RFC6022]を使用できます。 CAPWAPは、ワイヤレスターミネーションポイントのステータスを監視します。
RADIUS and diameter are considered passive monitoring protocols as they perform accounting, i.e., counting the number of packets/bytes for a specific user.
RADIUSとDiameterは、アカウンティングを実行するとき、つまり特定のユーザーのパケット/バイト数をカウントするときに、パッシブモニタリングプロトコルと見なされます。
The following table matches the protocols to the associated data model types. Furthermore, the table indicates how the data model can be extended based on the available content today and whether the protocol contains a built-in mechanism for proprietary extensions of the data model.
次の表は、プロトコルと関連するデータモデルタイプを示しています。さらに、この表は、現在利用可能なコンテンツに基づいてデータモデルを拡張する方法と、プロトコルにデータモデルの独自の拡張のための組み込みメカニズムが含まれているかどうかを示しています。
+-------------+---------------+------------------+------------------+
| Protocol | Data Modeling | Data Model | Proprietary Data |
| | | Extensions | Modeling |
| | | | Extensions |
+-------------+---------------+------------------+------------------+
| SNMP | MIB modules | New MIB modules | Enterprise- |
| (S. 2.1) | defined with | specified in new | specific MIB |
| | SMI | RFCs | modules |
| | (S. 2.1.3) | | |
| | | | |
| Syslog | Structured | With the | Enterprise- |
| (S. 2.2) | Data Elements | procedure to add | specific SDEs |
| | (SDEs) | Structured Data | |
| | (S. 4.2.1) | ID in [RFC5424] | |
| | | | |
| IPFIX | IPFIX | With the | Enterprise- |
| (S. 2.3) | Information | procedure to add | specific |
| | Elements, | Information | Information |
| | IPFIX IANA | Elements | Elements |
| | registry at | specified in | [RFC5101] |
| | [IANA-IPFIX] | [RFC5102] | |
| | (S. 2.3) | | |
| | | | |
| PSAMP | PSAMP | With the | Enterprise- |
| (S. 2.3) | Information | procedure to add | specific |
| | Elements, as | Information | Information |
| | an extension | Elements | Elements |
| | to IPFIX | specified in | [RFC5101] |
| | [IANA-IPFIX], | [RFC5102] | |
| | and PSAMP | | |
| | IANA registry | | |
| | at | | |
| | [IANA-PSAMP] | | |
| | (S. 2.3) | | |
| | | | |
| NETCONF | YANG modules | New YANG modules | Enterprise- |
| (S. 2.4.1) | (S. 2.4.2) | specified in new | specific YANG |
| | | RFCs following | modules |
| | | the guideline in | |
| | | [RFC6087] | |
| | | | |
| IPPM OWAMP/ | IPPM metrics | New IPPM metrics | Not applicable |
| TWAMP | (*) (S. 3.4) | (S. 3.4) | |
| (S. 3.4) | | | |
| | | | |
| RADIUS | TLVs | RADIUS-related | Vendor-Specific |
| (S. 3.5) | | registries at | Attributes |
| | | [IANA-AAA] and | [RFC2865] |
| | | [IANA-PROT] | |
| | | | |
| Diameter | AVPs | Diameter-related | Vendor-Specific |
| (S. 3.6) | | registry at | Attributes |
| | | [IANA-AAA] | [RFC2865] |
| | | | |
| CAPWAP | TLVs | New bindings | Vendor-specific |
| (S. 3.7) | | specified in new | TLVs |
| | | RFCs | |
+-------------+---------------+------------------+------------------+
Table 5: Data Models and Their Extensibility
表5：データモデルとその拡張性
(*): With the publication of [RFC6248], the latest IANA registry for IPFIX metrics has been declared Obsolete.
（*）：[RFC6248]の公開に伴い、IPFIXメトリックの最新のIANAレジストリが廃止されたと宣言されました。
Energy management is becoming an additional requirement for network management systems due to several factors including the rising and fluctuating energy costs, the increased awareness of the ecological impact of operating networks and devices, and government regulation on energy consumption and production.
エネルギー管理は、エネルギーコストの上昇と変動、稼働中のネットワークとデバイスの生態学的影響に対する意識の高まり、エネルギー消費と生産に対する政府の規制など、いくつかの要因により、ネットワーク管理システムの追加要件になりつつあります。
The basic objective of energy management is operating communication networks and other equipment with a minimal amount of energy while still providing sufficient performance to meet service-level objectives. Today, most networking and network-attached devices neither monitor nor allow controlled energy usage as they are mainly instrumented for functions such as fault, configuration, accounting, performance, and security management. These devices are not instrumented to be aware of energy consumption. There are very few means specified in IETF documents for energy management, which includes the areas of power monitoring, energy monitoring, and power state control.
エネルギー管理の基本的な目的は、サービスレベルの目標を満たすのに十分なパフォーマンスを提供しながら、最小限のエネルギーで通信ネットワークやその他の機器を操作することです。今日、ほとんどのネットワーキングデバイスとネットワーク接続デバイスは、主に障害、構成、アカウンティング、パフォーマンス、セキュリティ管理などの機能を備えているため、制御されたエネルギー使用量を監視したり許可したりすることはありません。これらのデバイスは、エネルギー消費を認識するように装備されていません。電力管理、エネルギー監視、電力状態制御の領域を含む、エネルギー管理のためのIETF文書で指定された手段はほとんどありません。
A particular difference between energy management and other management tasks is that in some cases energy consumption of a device is not measured at the device itself but reported by a different place. For example, at a Power over Ethernet (PoE) sourcing device or at a smart power strip, where one device is effectively metering another remote device. This requires a clear definition of the relationship between the reporting devices and identification of remote devices for which monitoring information is provided. Similar considerations will apply to power state control of remote devices, for example, at a PoE sourcing device that switches on and off power at its ports. Another example scenario for energy management is a gateway to low resourced and lossy network devices in wireless a building network. Here the energy management system talks directly to the gateway but not necessarily to other devices in the building network.
エネルギー管理と他の管理タスクの特定の違いは、場合によっては、デバイスのエネルギー消費がデバイス自体で測定されず、別の場所で報告されることです。たとえば、あるデバイスが別のリモートデバイスを効果的に測定しているPower over Ethernet（PoE）ソースデバイスやスマートパワーストリップなどです。これには、レポートデバイスと監視情報が提供されるリモートデバイスの識別の間の関係を明確に定義する必要があります。同様の考慮事項は、リモートデバイスの電源状態制御にも適用されます。たとえば、ポートで電源をオン/オフするPoEソースデバイスです。エネルギー管理の別の例のシナリオは、建物のワイヤレスネットワークにおけるリソースが少なく損失の多いネットワークデバイスへのゲートウェイです。ここでは、エネルギー管理システムは直接ゲートウェイと通信しますが、必ずしも建物ネットワーク内の他のデバイスとは通信しません。
At the time of this writing, the EMAN working group is working on the management of energy-aware devices, covered by the following items:
この記事の執筆時点で、EMANワーキンググループは、次の項目でカバーされるエネルギー認識デバイスの管理に取り組んでいます。
o The requirements for energy management, specifying energy management properties that will allow networks and devices to become energy aware. In addition to energy awareness requirements, the need for control functions will be discussed. Specifically, the need to monitor and control properties of devices that are remote to the reporting device should be discussed.
o エネルギー管理の要件。ネットワークとデバイスがエネルギーを認識できるようにするエネルギー管理プロパティを指定します。エネルギー意識の要件に加えて、制御機能の必要性についても説明します。具体的には、レポートデバイスからリモートにあるデバイスのプロパティを監視および制御する必要性について説明する必要があります。
o The energy management framework, which will describe extensions to the current management framework, required for energy management. This includes: power and energy monitoring, power states, power state control, and potential power state transitions. The framework will focus on energy management for IP-based network equipment (routers, switches, PCs, IP cameras, phones and the like). Particularly, the relationships between reporting devices, remote devices, and monitoring probes (such as might be used in low-power and lossy networks) need to be elaborated. For the case of a device reporting on behalf of other devices and controlling those devices, the framework will address the issues of discovery and identification of remote devices.
o エネルギー管理に必要な現在の管理フレームワークへの拡張について説明するエネルギー管理フレームワーク。これには、電力とエネルギーの監視、電力状態、電力状態制御、および潜在的な電力状態遷移が含まれます。このフレームワークは、IPベースのネットワーク機器（ルーター、スイッチ、PC、IPカメラ、電話など）のエネルギー管理に焦点を当てます。特に、レポートデバイス、リモートデバイス、および監視プローブ（低電力で損失の多いネットワークで使用される可能性があるものなど）間の関係を詳しく説明する必要があります。他のデバイスに代わってレポートを作成し、それらのデバイスを制御するデバイスの場合、フレームワークはリモートデバイスの検出と識別の問題に対処します。
o The Energy-aware Networks and Devices MIB document, for monitoring energy-aware networks and devices, will address devices identification, context information, and potential relationship between reporting devices, remote devices, and monitoring probes.
o エネルギー認識ネットワークとデバイスMIB文書は、エネルギー認識ネットワークとデバイスを監視するためのもので、デバイスの識別、コンテキスト情報、およびレポートデバイス、リモートデバイス、監視プローブ間の潜在的な関係に対処します。
o The Power and Energy Monitoring MIB document will document defining managed objects for the monitoring of power states and energy consumption/production. The monitoring of power states includes the following: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means of reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, they will provide information on electrical power quality.
o 電力およびエネルギー監視MIBドキュメントは、電力状態とエネルギー消費/生産の監視のための管理対象オブジェクトの定義を文書化します。電源状態の監視には、電源状態の取得、電源状態のプロパティ、現在の電源状態、電源状態の遷移、および電源状態の統計が含まれます。管理対象オブジェクトは、実際のエネルギーレート（電力）および累積エネルギーの詳細なプロパティを報告する手段を提供します。さらに、電力品質に関する情報を提供します。
o The Battery MIB document will define managed objects for battery monitoring, which will provide means of reporting detailed properties of the actual charge, age, and state of a battery and of battery statistics.
o バッテリーMIBドキュメントは、バッテリー監視用の管理対象オブジェクトを定義します。これは、バッテリーの実際の充電、経過時間、および状態とバッテリー統計の詳細なプロパティを報告する手段を提供します。
o The applicability statement will describe the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss relationships of the framework to other architectures and frameworks (such as Smart Grid). The applicability statement will explain the relationship between the work in this WG and other existing standards, e.g., from the IEC, ANSI, DMTF, etc. Note that the EMAN WG will be looking into existing standards such as those from the IEC, ANSI, DMTF and others, and reuse existing work as much as possible.
o 適用性ステートメントでは、エネルギーフレームワークと関連するMIBモジュールを使用できるさまざまなアプリケーションについて説明します。潜在的な例は、ネットワークの構築、家庭のエネルギーゲートウェイなどです。最後に、このドキュメントでは、フレームワークと他のアーキテクチャおよびフレームワーク（スマートグリッドなど）との関係についても説明します。適用性ステートメントは、このWGでの作業と、IEC、ANSI、DMTFなどの他の既存の標準との関係を説明します。EMANWGは、IEC、ANSI、 DMTFやその他、既存の作業を可能な限り再利用します。
The documents of the EMAN working group can be found at [EMAN-WG].
EMANワーキンググループのドキュメントは、[EMAN-WG]にあります。
Authors' Addresses
著者のアドレス
Mehmet Ersue (editor) Nokia Siemens Networks St.-Martin-Strasse 53 Munich 81541 Germany
Mehmet Ersue（編集者）Nokia Siemens Networks St.-Martin-Strasse 53ミュンヘン81541ドイツ
EMail: mehmet.ersue@nsn.com
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
Benoit Claise Cisco Systems、Inc. De Kleetlaan 6a b1 Diegem 1831 Belgium
EMail: bclaise@cisco.com