Network Working Group J. Case
Request for Comments: 2570 SNMP Research, Inc.
Category: Informational R. Mundy
TIS Labs at Network Associates, Inc.
D. Partain
Ericsson
B. Stewart
Cisco Systems
April 1999
Introduction to Version 3 of the
Internet-standard Network Management Framework
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed the SNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard Management Framework (SNMPv1) and the second Internet-standard Management Framework (SNMPv2).
このドキュメントの目的は、インターネット標準の管理フレームワークの3番目のバージョンの概要を提供することで、SNMPバージョン3の枠組み（SNMPv3が）と呼ばれます。このフレームワークは由来し、元のインターネット標準管理フレームワーク（SNMPv1の）及び第二インターネット標準管理フレームワーク（SNMPv2の）の両方の上に構築されます。
The architecture is designed to be modular to allow the evolution of the Framework over time.
アーキテクチャは、時間をかけてフレームワークの進化を可能にするモジュラーなるように設計されています。
Table of Contents
目次
1 Introduction .....................................................2
2 The Internet Standard Management Framework .......................3
2.1 Basic Structure and Components .................................3
2.2 Architecture of the Internet Standard Management Framework .....3
3 The SNMPv1 Management Framework ..................................4
3.1 The SNMPv1 Data Definition Language ............................5
3.2 Management Information .........................................6
3.3 Protocol Operations ............................................6
3.4 SNMPv1 Security and Administration .............................6
4 The SNMPv2 Management Framework ..................................7
5 The SNMPv3 Working Group .........................................8
6 SNMPv3 Framework Module Specifications ..........................10
6.1 Data Definition Language ......................................10
6.2 MIB Modules ...................................................11
6.3 Protocol Operations and Transport Mappings ....................12
6.4 SNMPv3 Security and Administration ............................12
7 Document Summaries ..............................................13
7.1 Structure of Management Information ...........................13
7.1.1 Base SMI Specification ......................................13
7.1.2 Textual Conventions .........................................14
7.1.3 Conformance Statements ......................................15
7.2 Protocol Operations ...........................................15
7.3 Transport Mappings ............................................15
7.4 Protocol Instrumentation ......................................16
7.5 Architecture / Security and Administration ....................16
7.6 Message Processing and Dispatch (MPD) .........................16
7.7 SNMP Applications .............................................17
7.8 User-based Security Model (USM) ...............................17
7.9 View-based Access Control (VACM) ..............................18
7.10 SNMPv3 Coexistence and Transition ............................18
8 Security Considerations .........................................19
9 Editors' Addresses ..............................................19
10 References .....................................................20
11 Full Copyright Statement .......................................23
1 Introduction
1はじめに
This document is an introduction to the third version of the Internet-standard Management Framework, termed the SNMP version 3 Management Framework (SNMPv3) and has multiple purposes.
このドキュメントはインターネット標準の管理フレームワークのバージョン3への導入で、SNMPバージョン3管理フレームワーク（SNMPv3のを）と呼ばれ、複数の目的を持っています。
First, it describes the relationship between the SNMP version 3 (SNMPv3) specifications and the specifications of the SNMP version 1 (SNMPv1) Management Framework, the SNMP version 2 (SNMPv2) Management Framework, and the Community-based Administrative Framework for SNMPv2.
まず、それはSNMPバージョン3（SNMPv3の）仕様およびSNMPバージョン1（SNMPv1の）管理フレームワークの仕様との関係を説明し、SNMPバージョン2（SNMPv2の）管理フレームワーク、およびSNMPv2のためのコミュニティベースの管理フレームワーク。
Second, it provides a roadmap to the multiple documents which contain the relevant specifications.
第二に、それは、関連する仕様を含む複数のドキュメントへのロードマップを提供します。
Third, this document provides a brief easy-to-read summary of the contents of each of the relevant specification documents.
第三に、このドキュメントは、関連する仕様書のそれぞれの内容を簡単にわかりやすくまとめられています。
This document is intentionally tutorial in nature and, as such, may occasionally be "guilty" of oversimplification. In the event of a conflict or contradiction between this document and the more detailed documents for which this document is a roadmap, the specifications in the more detailed documents shall prevail.
この文書では、意図的になど、時折単純化の「有罪」であってもよいし、自然の中でチュートリアルとされます。この文書とこの文書がロードマップであるため、より詳細なドキュメント間の葛藤や矛盾が発生した場合には、より詳細な文書で仕様が優先するものとします。
Further, the detailed documents attempt to maintain separation between the various component modules in order to specify well-defined interfaces between them. This roadmap document, however, takes a different approach and attempts to provide an integrated view of the various component modules in the interest of readability.
さらに、詳細なドキュメントは、それらの間に明確に定義されたインターフェースを指定するために、様々なコンポーネントモジュール間の分離を維持することを試みます。このロードマップ文書は、しかしながら、異なるアプローチをとり、読みやすさの利益のために様々なコンポーネントモジュールの統合されたビューを提供することを試みます。
2 The Internet Standard Management Framework
2インターネット標準管理フレームワーク
The third version of the Internet Standard Management Framework (the SNMPv3 Framework) is derived from and builds upon both the original Internet-standard Management Framework (SNMPv1) and the second Internet-standard Management Framework (SNMPv2).
インターネット標準の管理フレームワーク（SNMPv3のフレームワーク）の3番目のバージョンが由来すると元のインターネット標準管理フレームワーク（SNMPv1の）及び第二インターネット標準管理フレームワーク（SNMPv2の）の両方の上に構築されます。
All versions (SNMPv1, SNMPv2, and SNMPv3) of the Internet Standard Management Framework share the same basic structure and components. Furthermore, all versions of the specifications of the Internet Standard Management Framework follow the same architecture.
インターネット標準管理フレームワークのすべてのバージョン（SNMPv1の、SNMPv2の、およびSNMPv3）は、同じ基本構造とコンポーネントを共有しています。さらに、インターネット標準管理フレームワークの仕様のすべてのバージョンは、同じアーキテクチャに従ってください。
An enterprise deploying the Internet Standard Management Framework contains four basic components:
インターネット標準管理フレームワークを導入する企業は4つの基本的な構成要素が含まれています。
* several (typically many) managed nodes, each with an SNMP entity which provides remote access to management instrumentation (traditionally called an agent);
*（一般的に多くの）複数のノード、（伝統的にエージェントと呼ばれる）管理計装へのリモートアクセスを提供するSNMPエンティティと各管理。
* at least one SNMP entity with management applications (typically called a manager),
*管理アプリケーションと少なくとも一つのSNMPエンティティは、（通常はマネージャーと呼ばれます）
* a management protocol used to convey management information between the SNMP entities, and
*管理プロトコルは、SNMPエンティティ間で管理情報を伝達するために使用され、
* management information.
*経営情報。
The management protocol is used to convey management information between SNMP entities such as managers and agents.
管理プロトコルは、マネージャとエージェントとしてSNMPエンティティ間で管理情報を伝えるために使用されます。
This basic structure is common to all versions of the Internet Standard Management Framework; i.e., SNMPv1, SNMPv2, and SNMPv3.
この基本的な構造は、インターネット標準管理フレームワークのすべてのバージョンに共通しています。すなわち、SNMPv1の、SNMPv2の、およびSNMPv3。
The specifications of the Internet Standard Management Framework are based on a modular architecture. This framework is more than just a protocol for moving data. It consists of:
インターネット標準管理フレームワークの仕様は、モジュラーアーキテクチャに基づいています。このフレームワークは、データを移動するための単なるプロトコル以上のものです。これは、で構成されています。
* a data definition language,
*データ定義言語、
* definitions of management information (the Management Information Base, or MIB),
*管理情報の定義（管理情報ベース、またはMIB）、
* a protocol definition, and
*プロトコル定義、および
* security and administration.
*セキュリティと管理。
Over time, as the Framework has evolved from SNMPv1, through SNMPv2, to SNMPv3, the definitions of each of these architectural components have become richer and more clearly defined, but the fundamental architecture has remained consistent.
フレームワークは、SNMPv1のより進化してきたように、時間が経つにつれて、SNMPv2のを通して、SNMPv3のために、これらのアーキテクチャコンポーネントのそれぞれの定義が豊かになり、より明確に定義されたが、基本的なアーキテクチャは、一貫性のままです。
One prime motivator for this modularity was to enable the ongoing evolution of the Framework as is documented in RFC 1052 [14]. When originally envisioned, this capability was to be used to ease the transition from SNMP-based management of internets to management based on OSI protocols. To this end, the framework was architected with a protocol-independent data definition language and Management Information Base along with a MIB-independent protocol. This separation was designed to allow the SNMP-based protocol to be replaced without requiring the management information to be redefined or reinstrumented. History has shown that the selection of this architecture was the right decision for the wrong reason -- it turned out that this architecture has eased the transition from SNMPv1 to SNMPv2 and from SNMPv2 to SNMPv3 rather than easing the transition away from management based on the Simple Network Management Protocol.
RFC 1052 [14]に記載されていて、このモジュール方式の一つプライム動機は、フレームワークの継続的な発展を可能にすることでした。本来想定するとき、この機能は、OSIプロトコルに基づく管理へのインターネットのSNMPベースの管理からの移行を容易にするために使用されるようになりました。この目的を達成するために、フレームワークは、MIB-依存しないプロトコルと一緒に、プロトコルに依存しないデータ定義言語と管理情報ベースで設計されました。この分離は、SNMPベースのプロトコルは、再定義又は再インスする管理情報を必要とせずに交換することができるように設計しました。それは、このアーキテクチャがシンプルに基づいて、むしろ離れて経営からの移行を容易によりのSNMPv1からSNMPv2のへとSNMPv2からSNMPv3のへの移行を緩和していることが判明 - 歴史は、このアーキテクチャの選択は間違った理由のために正しい決断だったことを示していますネットワーク管理プロトコル。
The SNMPv3 Framework builds and extends these architectural principles by:
SNMPv3のフレームワークは、することにより、これらのアーキテクチャの原則を構築し、拡張します。
* building on these four basic architectural components, in some cases incorporating them from the SNMPv2 Framework by reference, and
*参照することによってSNMPv2フレームワークからそれらを組み込むいくつかのケースではこれら四つの基本的なアーキテクチャコンポーネント上の建物と、
* by using these same layering principles in the definition of new capabilities in the security and administration portion of the architecture.
*アーキテクチャのセキュリティと管理の部分での新機能の定義にこれらの同じ階層化の原則を使用します。
Those who are familiar with the architecture of the SNMPv1 Management Framework and the SNMPv2 Management Framework will find many familiar concepts in the architecture of the SNMPv3 Management Framework. However, in some cases, the terminology may be somewhat different.
SNMPv1の管理フレームワークとSNMPv2管理フレームワークのアーキテクチャに精通している人は、SNMPv3の管理フレームワークのアーキテクチャでは、多くのおなじみの概念があります。しかし、いくつかのケースでは、用語が多少異なる場合があります。
3 The SNMPv1 Management Framework
3のSNMPv1管理フレームワーク
The original Internet-standard Network Management Framework (SNMPv1) is defined in the following documents:
オリジナルのインターネット標準ネットワーク管理フレームワーク（SNMPv1のは）次のドキュメントで定義されています。
* STD 16, RFC 1155 [1] which defines the Structure of Management Information (SMI), the mechanisms used for describing and naming objects for the purpose of management.
* STD 16、RFC 1155 [1]管理情報（SMI）、管理の目的のためにオブジェクトを記述し、命名のために使用される機構の構造を定義します。
* STD 16, RFC 1212 [2] which defines a more concise description mechanism for describing and naming management information objects, but which is wholly consistent with the SMI.
* STD 16、RFC 1212 [2]管理情報オブジェクトを記述し、命名のためのより簡潔な記述メカニズムを定義するが、SMIと完全に一致しています。
* STD 15, RFC 1157 [3] which defines the Simple Network Management Protocol (SNMP), the protocol used for network access to managed objects and event notification. Note this document also defines an initial set of event notifications.
* STD 15、RFC 1157 [3]は簡易ネットワーク管理プロトコル（SNMP）、管理オブジェクトとイベント通知へのネットワークアクセスのために使用されるプロトコルを定義します。この文書はまた、イベント通知の初期セットを定義して注意してください。
Additionally, two documents are generally considered to be companions to these three:
さらに、2つの文書は、一般的に、これらの3の仲間であると考えられています。
* STD 17, RFC 1213 [13] which contains definitions for the base set of management information
* STD 17、RFC 1213 [13]管理情報の基本セットの定義が含まれ
* RFC 1215 [25] defines a concise description mechanism for defining event notifications, which are called traps in the SNMPv1 protocol. It also specifies the generic traps from RFC 1157 in the concise notation.
* RFC 1215 [25] SNMPv1プロトコルにトラップと呼ばれるイベント通知を定義するための簡潔な記述メカニズムを定義します。また、簡潔な表記でRFC 1157から汎用トラップを指定します。
These documents describe the four parts of the first version of the SNMP Framework.
これらの文書は、SNMPフレームワークの最初のバージョンの四つの部分を記述する。
The first two and the last document describe the SNMPv1 data definition language. Note that due to the initial requirement that the SMI be protocol-independent, the first two SMI documents do not provide a means for defining event notifications (traps). Instead, the SNMP protocol document defines a few standardized event notifications (generic traps) and provides a means for additional event notifications to be defined. The last document specifies a straight-forward approach towards defining event notifications used with the SNMPv1 protocol. At the time that it was written, use of traps in the Internet-standard network management framework was controversial. As such, RFC 1215 was put forward with the status of "Informational", which was never updated because it was believed that the second version of the SNMP Framework would replace the first version. Note that the SNMPv1 data definition language is sometimes referred to as SMIv1.
2最初と最後の文書は、SNMPv1データ定義言語を記述します。 SMIは、プロトコルに依存しないことが最初の要求には、最初の2つのSMI文書がイベント通知（トラップ）を定義するための手段を提供しないことに注意してください。代わりに、SNMPプロトコル文書は、いくつかの標準化されたイベント通知（汎用トラップ）を定義し、定義するために追加のイベント通知のための手段を提供します。最後のドキュメントは、SNMPv1プロトコルで使用されるイベント通知の定義に向けた直接的なアプローチを指定します。それが書かれた時点で、インターネット標準ネットワーク管理フレームワークでのトラップの使用は物議ました。このようにして、RFC 1215には、それはSNMPフレームワークの第二のバージョンは、最初のバージョンを置き換えるだろうと信じられていたため、更新されなかった「情報」の状態、と提唱しました。 SNMPv1のデータ定義言語でSMIv1と呼ばれることがあることに注意してください。
The data definition language described in the first two documents was first used to define the now-historic MIB-I as specified in RFC 1066 [12], and was subsequently used to define MIB-II as specified in RFC 1213 [13].
最初の二つの文書に記載されたデータ定義言語は、最初のRFC 1066で指定されるように、今、歴史的MIB-Iを定義するために使用された[12]、続いてRFC 1213に指定されているMIB-IIを定義するために使用された[13]。
Later, after the publication of MIB-II, a different approach to management information definition was taken from the earlier approach of having a single committee staffed by generalists work on a single document to define the Internet-standard MIB. Rather, many mini-MIB documents were produced in a parallel and distributed fashion by groups chartered to produce a specification for a focused portion of the Internet-standard MIB and staffed by personnel with expertise in those particular areas ranging from various aspects of network management, to system management, and application management.
以降、MIB-IIの発行後、管理情報の定義とは異なるアプローチがジェネラリストによってスタッフ単一委員会がインターネット標準MIBを定義する単一の文書で作業有する以前のアプローチから採取しました。むしろ、多くのミニMIBドキュメントは、インターネット標準MIBの合焦部分の仕様を生成するためにチャーターグループにより並列分散方式で生成され、ネットワーク管理の様々な側面の範囲のそれらの特定の領域で専門知識を有する者によってスタッフましたシステム管理、アプリケーション管理に。
The third document, STD 15, describes the SNMPv1 protocol operations performed by protocol data units (PDUs) on lists of variable bindings and describes the format of SNMPv1 messages. The operators defined by SNMPv1 are: get, get-next, get-response, set-request, and trap. Typical layering of SNMP on a connectionless transport service is also defined.
第三の文書、STD 15は、変数バインディングのリストのプロトコルデータユニット（PDU）によって実行されるSNMPv1プロトコルの動作を説明し、SNMPv1のメッセージのフォーマットを記述する。 SNMPv1ので定義された事業者は、次のとおり取得するには、Get-次、取得 - 応答、設定要求、およびトラップ。コネクションレスのトランスポートサービス上のSNMPの典型的なレイヤーも定義されています。
STD 15 also describes an approach to security and administration. Many of these concepts are carried forward and some, particularly security, are extended by the SNMPv3 Framework.
STD 15は、セキュリティと管理へのアプローチを説明します。これらの概念の多くが引き継がれており、いくつかは、特にセキュリティ、SNMPv3のフレームワークによって拡張されています。
The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in SNMP messages between SNMP entities and distinguishes between application entities and protocol entities. In SNMPv3, these are renamed applications and engines, respectively.
SNMPv1フレームワークでは、SNMPエンティティ間のSNMPメッセージでのSNMPv1 PDUのカプセル化について説明し、アプリケーションエンティティとプロトコルエンティティが区別されます。 SNMPv3のでは、これらはそれぞれ、アプリケーションとエンジンが変更されます。
The SNMPv1 Framework also introduces the concept of an authentication service supporting one or more authentication schemes. In addition to authentication, SNMPv3 defines the additional security capability referred to as privacy. (Note: some literature from the security community would describe SNMPv3 security capabilities as providing data integrity, source authenticity, and confidentiality.) The modular nature of the SNMPv3 Framework permits both changes and additions to the security capabilities.
SNMPv1フレームワークでは、1つまたは複数の認証方式をサポートしている認証サービスの概念を導入しています。認証に加えて、SNMPv3は、プライバシーと呼ばれる追加のセキュリティ機能を定義します。 （注意：セキュリティコミュニティからいくつかの文献は、データの整合性、ソースの真正性、機密性を提供するものとしてSNMPv3セキュリティ機能について説明します。）のSNMPv3フレームワークのモジュラー性質は、セキュリティ機能の両方の変更や追加が可能になります。
Finally, the SNMPv1 Framework introduces access control based on a concept called an SNMP MIB view. The SNMPv3 Framework specifies a fundamentally similar concept called view-based access control. With this capability, SNMPv3 provides the means for controlling access to information on managed devices.
最後に、SNMPv1フレームワークでは、SNMP MIBビューと呼ばれる概念に基づいたアクセス制御を導入しています。 SNMPv3のフレームワークは、ビューベースのアクセス制御と呼ばれる基本的に同様の概念を指定します。この機能により、SNMPv3は、管理対象デバイス上の情報へのアクセスを制御するための手段を提供します。
However, while the SNMPv1 Framework anticipated the definition of multiple authentication schemes, it did not define any such schemes other than a trivial authentication scheme based on community strings. This was a known fundamental weakness in the SNMPv1 Framework but it was thought at that time that the definition of commercial grade security might be contentious in its design and difficult to get approved because "security" means many different things to different people. To that end, and because some users do not require strong authentication, the SNMPv1 architected an authentication service as a separate block to be defined "later" and the SNMPv3 Framework provides an architecture for use within that block as well as a definition for its subsystems.
SNMPv1フレームワークでは、複数の認証方式の定義を予想しながら、しかし、それはコミュニティストリングに基づいて、些細な認証方式以外の任意のそのようなスキームを定義していませんでした。これは、SNMPv1フレームワークで知られている根本的な弱点だったが、それは、「セキュリティ」は異なる人々に多くの異なるものを意味するので、商用グレードのセキュリティの定義は、承認を得るために、そのデザインで論争と難しいかもしれないその時に考えられていました。そのために、一部のユーザーは、強力な認証を必要としない、SNMPv1のは「後で」に定義されるように、別のブロックとして認証サービスをアーキテクチャおよびSNMPv3 Frameworkはそのブロック内で使用するためのアーキテクチャだけでなく、そのサブシステムの定義を提供しますので、 。
4 The SNMPv2 Management Framework
4 SNMPv2の管理フレームワーク
The SNMPv2 Management Framework is fully described in [4-9] and coexistence and transition issues relating to SNMPv1 and SNMPv2 are discussed in [10].
SNMPv2の管理フレームワークは、完全に[4-9]に記載されており、SNMPv1とSNMPv2のに関連する共存と移行問題は[10]に記載されています。
SNMPv2 provides several advantages over SNMPv1, including:
SNMPv2では、SNMPv1のを含むいくつかの利点を提供します。
* expanded data types (e.g., 64 bit counter)
*拡張データタイプ（例えば、64ビット・カウンタ）
* improved efficiency and performance (get-bulk operator)
*改善された効率と性能（取得バルクオペレータ）
* confirmed event notification (inform operator)
*確認イベント通知（オペレータに通知）
* richer error handling (errors and exceptions)
*取り扱い豊かなエラー（エラーと例外）
* improved sets, especially row creation and deletion
*改善セット、特に行の作成および削除
* fine tuning of the data definition language
*データ定義言語の微調整
However, the SNMPv2 Framework, as described in these documents, is incomplete in that it does not meet the original design goals of the SNMPv2 project. The unmet goals included provision of security and administration delivering so-called "commercial grade" security with
それはSNMPv2のプロジェクトの当初の設計目標を満たしていないという点で、しかし、SNMPv2フレームワークは、これらの文書で説明したように、不完全です。満たされていない目標は、いわゆる「商用グレード」のセキュリティを提供するセキュリティと管理の提供を含みます
* authentication: origin identification, message integrity, and some aspects of replay protection;
*認証：起源の識別、メッセージの整合性、および再生保護のいくつかの側面。
* privacy: confidentiality;
*プライバシー：機密性。
* authorization and access control; and
*認証とアクセス制御。そして
* suitable remote configuration and administration capabilities for these features.
これらの機能のための*に適したリモート設定および管理機能を提供します。
The SNMPv3 Management Framework, as described in this document and the companion documents, addresses these significant deficiencies.
SNMPv3の管理フレームワークは、このドキュメントコンパニオン文書で説明したように、これらの重要な欠陥に対処しています。
5 The SNMPv3 Working Group
5 SNMPv3のワーキンググループ
This document, and its companion documents, were produced by the SNMPv3 Working Group of the Internet Engineering Task Force (IETF). The SNMPv3 Working Group was chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group was to produce the necessary set of documents that provide a single standard for the next generation of core SNMP functions. The single, most critical need in the next generation is a definition of security and administration that makes SNMP-based management transactions secure in a way which is useful for users who wish to use SNMPv3 to manage networks, the systems that make up those networks, and the applications which reside on those systems, including manager-to-agent, agent-to-manager, and manager-to-manager transactions.
このドキュメント、およびその仲間ドキュメントは、Internet Engineering Task Force（IETF）のSNMPv3のワーキンググループによって作成されました。 SNMPv3のワーキンググループは、SNMPの次の世代のための勧告を準備するためにチャーターされました。ワーキンググループの目標は、コアSNMP機能の次世代のための単一の標準を提供した文書の必要なセットを生成することでした。次の世代では、単一の、最も重要な必要性は、ネットワークを管理するためのSNMPv3を使用したいユーザーが、これらのネットワークを構成するシステムに有用な方法でセキュアなSNMPベースの管理の取引を行い、セキュリティと管理の定義ですそしてマネージャ・ツー・エージェント、エージェント - マネージャ、およびマネージャ・ツー・マネージャ取引を含むそれらのシステム上に常駐するアプリケーション。
In the several years prior to the chartering of the Working Group, there were a number of activities aimed at incorporating security and other improvements to SNMP. These efforts included:
ワーキンググループのチャーターに先立って、数年後には、SNMPにセキュリティや他の改善を組み込むに向けた活動の数がありました。これらの努力が含まれます：
* "SNMP Security" circa 1991-1992 [RFC 1351 - RFC 1353],
* "SNMPセキュリティ" 年頃1991-1992 [RFC 1351 - RFC 1353]、
* "SMP" circa 1992-1993,
1992-1993年頃* "ジュニア"、
* "The Party-based SNMPv2" circa 1993-1995 [RFC 1441 - RFC 1452].
* "パーティー・ベースのSNMPv2" 年頃1993から1995 [RFC 1441 - RFC 1452]。
Each of these efforts incorporated commercial grade, industrial strength security including authentication, privacy, authorization, view-based access control, and administration, including remote configuration.
リモート設定を含む商業グレード、認証、プライバシー、認証、ビューベースのアクセス制御を含む工業用強度のセキュリティ、および管理を、組み込まれたこれらの努力のそれぞれ。
These efforts fed the development of the SNMPv2 Management Framework as described in RFCs 1902 - 1908. However, the Framework described in those RFCs had no standards-based security and administrative framework of its own; rather, it was associated with multiple security and administrative frameworks, including:
; 1908しかし、これらのRFCに記述フレームワークは何の標準ベースのセキュリティと、独自の管理フレームワークを持っていた - RFCで説明したように、これらの取り組みは、1902年のSNMPv2管理フレームワークの開発を供給しましたむしろ、それを含めて、複数のセキュリティおよび管理フレームワークに関連していました。
* "The Community-based SNMPv2" (SNMPv2c) [RFC 1901],
* "コミュニティベースのSNMPv2"（SNMPv2cの）[RFC 1901]
* "SNMPv2u" [RFCs 1909 - 1910] and
* "SNMPv2u" [RFCの1909年から1910年]と
* "SNMPv2*".
* "SNMPv2の*"。
SNMPv2c had the endorsement of the IETF but no security and administration whereas both SNMPv2u and SNMPv2* had security but lacked the endorsement of the IETF.
SNMPv2uとSNMPv2 *の両方のセキュリティを持っていたが、IETFの承認を欠いていたのに対し、SNMPv2cには、IETFの承認なく、無セキュリティと管理していました。
The SNMPv3 Working Group was chartered to produce a single set of specifications for the next generation of SNMP, based upon a convergence of the concepts and technical elements of SNMPv2u and SNMPv2*, as was suggested by an advisory team which was formed to provide a single recommended approach for SNMP evolution.
シングルを提供するように形成された諮問チームによって提案されたとしてのSNMPv3ワーキンググループは、概念やSNMPv2uとSNMPv2 *の技術要素の収束に基づいて、SNMPの次の世代のための仕様の単一のセットを生成するためにチャーターされましたSNMPの進化のためのアプローチをお勧めします。
In so doing, the Working Group charter defined the following objectives:
そうすることで、ワーキンググループ憲章は、以下の目的を定義しました。
* accommodate the wide range of operational environments with differing management demands;
*管理の要求が異なる運用環境の広い範囲に対応。
* facilitate the need to transition from previous, multiple protocols to SNMPv3;
* SNMPv3の、前、複数のプロトコルからの移行の必要性を容易にします。
* facilitate the ease of setup and maintenance activities.
*セットアップやメンテナンス活動を容易。
In the initial work of the SNMPv3 Working Group, the group focused on security and administration, including
SNMPv3の作業部会の初期の作品では、グループには、セキュリティと管理に焦点を当てました
* authentication and privacy,
*認証とプライバシー、
* authorization and view-based access control, and
*承認とビューベースのアクセス制御、および
* standards-based remote configuration of the above.
※上記のリモート構成を標準ベース。
The SNMPv3 Working Group did not "reinvent the wheel," but reused the SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for those portions of the design that were outside the focused scope.
SNMPv3のワーキンググループは「車輪の再発明」しませんでしたが、集中範囲外であった設計の部分のために1908年を通じて1902 SNMPv2のドラフト標準の文書、すなわち、RFCを再利用します。
Rather, the primary contributors to the SNMPv3 Working Group, and the Working Group in general, devoted their considerable efforts to addressing the missing link -- security and administration -- and in the process made invaluable contributions to the state-of-the-art of management.
セキュリティと管理 - - むしろ、SNMPv3のワーキンググループへの主要な貢献者、および一般的なワーキンググループは、ミッシングリンクに対処する彼らの多大な努力を捧げ、その過程で最先端のに非常に貴重な貢献をしました経営の。
They produced a design based on a modular architecture with evolutionary capabilities with emphasis on layering. As a result, SNMPv3 can be thought of as SNMPv2 with additional security and administration capabilities.
彼らは、レイヤーに重点を置いた進化の機能を備えたモジュラー型アーキテクチャに基づいて設計を作成しました。その結果、SNMPv3は、追加のセキュリティと管理機能とのSNMPv2と考えることができます。
In doing so, the Working Group achieved the goal of producing a single specification which has not only the endorsement of the IETF but also has security and administration.
そうすることで、ワーキンググループは、IETFの承認だけでなく、持っているだけでなく、セキュリティと管理を持つ単一の仕様を生産するという目標を達成しました。
6 SNMPv3 Framework Module Specifications
6つのSNMPv3のフレームワークモジュール仕様
The specification of the SNMPv3 Management Framework is partitioned in a modular fashion among several documents. It is the intention of the SNMPv3 Working Group that, with proper care, any or all of the individual documents can be revised, upgraded, or replaced as requirements change, new understandings are obtained, and new technologies become available.
SNMPv3の管理フレームワークの仕様は、いくつかのドキュメント間でモジュール方式で仕切られています。これは、適切な注意を払って、個々のドキュメントのいずれかまたは全ては、改訂されたアップグレード、または要件の変更に応じて交換することができ、SNMPv3のワーキンググループの意図で、新しい理解が得られ、新しい技術が利用可能になっています。
Whenever feasible, the initial document set which defines the SNMPv3 Management Framework leverages prior investments defining and implementing the SNMPv2 Management Framework by incorporating by reference each of the specifications of the SNMPv2 Management Framework.
たび可能、SNMPv3の管理フレームワークを定義する最初の文書セットが定義すると、参照することによってSNMPv2管理フレームワークの仕様のそれぞれを組み込むことによってSNMPv2管理フレームワークを実装する前に投資を活用しています。
The SNMPv3 Framework augments those specifications with specifications for security and administration for SNMPv3.
SNMPv3のフレームワークは、SNMPv3のセキュリティと管理のための仕様で、これらの仕様を拡張します。
The documents which specify the SNMPv3 Management Framework follow the same architecture as those of the prior versions and can be organized for expository purposes into four main categories as follows:
SNMPv3の管理フレームワークを指定する文書は、以前のバージョンのものと同じアーキテクチャを追跡し、次のように4つの主要なカテゴリに解説の目的のために整理することができます。
* the data definition language,
*データ定義言語、
* Management Information Base (MIB) modules,
*管理情報ベース（MIB）モジュール、
* protocol operations, and
*プロトコル操作、および
* security and administration.
*セキュリティと管理。
The first three sets of documents are incorporated from SNMPv2. The fourth set of documents are new to SNMPv3, but, as described previously, build on significant prior related works.
文書の最初の三組は、SNMPv2から組み込まれています。文書の第4セットは、前述のように、大幅な従来の関連作品を構築し、SNMPv3のに新しいですが、。
The specifications of the data definition language includes STD 58, RFC 2578, "Structure of Management Information Version 2 (SMIv2)" [26], and related specifications. These documents are updates of RFCs 1902 - 1904 [4-6] which have evolved independently from the other parts of the framework and were republished as STD 58, RFCs 2578 - 2580 [26-28] when promoted from Draft Standard.
データ定義言語の仕様は、[26]、及び関連する仕様「経営情報バージョン2（SMIv2）の構造を」STD 58、RFC 2578を含みます。フレームワークの他の部分から独立して進化したとSTD 58として再発行された[4-6] 1904のRFC 2578 - - ドラフト標準から昇格2580 [26-28]、これらの文書は、のRFC 1902の更新です。
The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules. Related specifications include STD 58, RFCs 2579, 2580. The updated data definition language is sometimes referred to as SMIv2.
管理情報（SMIv2の）の構造は、基本データ型、オブジェクトモデル、およびMIBモジュールを書き込み、修正するための規則を定義します。関連の仕様はSTD 58、RFCの2579年、2580更新されたデータ定義言語が時々SMIv2のと呼ばれています。
STD 58, RFC 2579, "Textual Conventions for SMIv2" [27], defines an initial set of shorthand abbreviations which are available for use within all MIB modules for the convenience of human readers and writers.
STD 58、RFC 2579、「SMIv2のためのテキストの表記法」[27]、ヒトリーダーとライターの便宜のために、すべてのMIBモジュール内で使用可能な速記の略語の最初のセットを定義します。
STD 58, RFC 2580, "Conformance Statements for SMIv2" [28], defines the format for compliance statements which are used for describing requirements for agent implementations and capability statements which can be used to document the characteristics of particular implementations.
STD 58、RFC 2580、「SMIv2のための順応文」[28]は、特定の実装の特徴を文書化するために使用することができるエージェントの実装と機能文の要件を記述するために使用されるコンプライアンスステートメントの形式を定義します。
MIB modules usually contain object definitions, may contain definitions of event notifications, and sometimes include compliance statements specified in terms of appropriate object and event notification groups. As such, MIB modules define the management information maintained by the instrumentation in managed nodes, made remotely accessible by management agents, conveyed by the management protocol, and manipulated by management applications.
MIBモジュールは通常、イベント通知の定義を含むことができ、オブジェクトの定義を含む、時には適切なオブジェクトおよびイベント通知グループの観点で指定されたコンプライアンス・ステートメントが含まれます。このように、MIBモジュールは、管理エージェントによってリモートでアクセス可能管理ノードにおける計測によって維持管理情報、管理プロトコルによって搬送され、管理アプリケーションによって操作を定義します。
MIB modules are defined according the rules defined in the documents which specify the data definition language, principally the SMI as supplemented by the related specifications.
MIBモジュールは、関連する仕様で補足として、データ定義言語、主にSMIを指定したドキュメントで定義されたルールに従って定義されています。
There is a large and growing number of standards-based MIB modules, as defined in the periodically updated list of standard protocols [STD 1, RFC 2400]. As of this writing, there are nearly 100 standards-based MIB modules with a total number of defined objects approaching 10,000. In addition, there is an even larger and growing number of enterprise-specific MIB modules defined unilaterally by various vendors, research groups, consortia, and the like resulting in an unknown and virtually uncountable number of defined objects.
標準プロトコル[STD 1、RFC 2400]の定期的に更新リストで定義された標準ベースのMIBモジュールの大規模かつ成長している数が、あります。この記事の執筆時点では、万に近づいて定義されたオブジェクトの総数とほぼ100標準ベースのMIBモジュールがあります。加えて、より大きな及び様々なベンダー、研究グループ、コンソーシアム、および定義されたオブジェクトの未知の実質無数に得等によって一方的に定義されたエンタープライズ固有のMIBモジュールの増加があります。
In general, management information defined in any MIB module, regardless of the version of the data definition language used, can be used with any version of the protocol. For example, MIB modules defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the SNMPv3 Management Framework and can be conveyed by the protocols specified therein. Furthermore, MIB modules defined in terms of the SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and can be conveyed by it. However, there is one noteworthy exception: the Counter64 datatype which can be defined in a MIB module defined in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol engine.
一般に、任意のMIBモジュールで定義された管理情報は、関係なく使用されるデータ定義言語のバージョンのプロトコルのすべてのバージョンで使用することができます。例えば、SNMPv1のSMI（でSMIv1）の観点で定義されたMIBモジュールは、SNMPv3の管理フレームワークと互換性があり、その中に指定されたプロトコルによって搬送することができます。また、SNMPv2のSMI（SMIv2の）に関して定義されたMIBモジュールは、SNMPv1プロトコル操作と互換性があり、それによって搬送することができます。 SMIv2の形式で定義されたMIBモジュールで定義することができるが、SNMPv1プロトコルエンジンによって搬送することができないCounter64のデータ型：しかしながら、注目すべき例外があります。
The specifications for the protocol operations and transport mappings of the SNMPv3 Framework are incorporated by reference to the two SNMPv2 Framework documents.
SNMPv3フレームワークのプロトコル操作とトランスポートマッピングの仕様は、二つのSNMPv2フレームワークドキュメントを参照することにより組み込まれます。
The specification for protocol operations is found in RFC 1905, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)" [7]. The SNMPv3 Framework is designed to allow various portions of the architecture to evolve independently. For example, it might be possible for a new specification of protocol operations to be defined within the Framework to allow for additional protocol operations.
プロトコル操作のための仕様は、RFC 1905年に発見され、「簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのプロトコル操作」[7]。 SNMPv3のフレームワークは、アーキテクチャの様々な部分は、独立して進化できるように設計されています。例えば、追加のプロトコル操作を可能にするフレームワーク内で定義されるプロトコル操作の新たな指定可能であるかもしれません。
The specification of transport mappings is found in RFC 1906, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)" [8].
トランスポートマッピングの仕様はRFC 1906年に発見され、「簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための輸送マッピング」[8]。
The SNMPv3 document series defined by the SNMPv3 Working Group consists of seven documents at this time:
SNMPv3のワーキンググループによって定義されたSNMPv3ドキュメントシリーズは、この時点で7つの文書で構成されています。
RFC 2570, "Introduction to Version 3 of the Internet-standard Network Management Framework", which is this document.
RFC 2570、この文書で、「インターネット標準ネットワーク管理フレームワークのバージョン3の概要」。
RFC 2571, "An Architecture for Describing SNMP Management Frameworks" [15], describes the overall architecture with special emphasis on the architecture for security and administration.
RFC 2571、「SNMP管理フレームワークを記述するためのアーキテクチャ」[15]は、セキュリティと管理のためのアーキテクチャ上の特別な重点を置いて、全体的なアーキテクチャについて説明します。
RFC 2572, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [16], describes the possibly multiple message processing models and the dispatcher portion that can be a part of an SNMP protocol engine.
RFC 2572、「メッセージ処理と簡易ネットワーク管理プロトコル（SNMP）のためのディスパッチ」[16]、おそらく複数のメッセージ処理モデルおよびSNMPプロトコルエンジンの一部とすることができるディスパッチャ部分を記述する。
RFC 2573, "SNMP Applications" [17], describes the five types of applications that can be associated with an SNMPv3 engine and their elements of procedure.
RFC 2573、「SNMPアプリケーション」[17]は、SNMPv3エンジンと手続きのその要素に関連付けることができる5種類のアプリケーションを記述します。
RFC 2574, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)" [18], describes the threats, mechanisms, protocols, and supporting data used to provide SNMP message-level security.
RFC 2574には、「ユーザベースセキュリティモデルは、簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために」[18]、SNMPメッセージレベルのセキュリティを提供するために使用する脅威、メカニズム、プロトコル、およびサポートするデータを記述する。
RFC 2575, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)" [19], describes how view-based access control can be applied within command responder and notification originator applications.
RFC 2575、「簡易ネットワーク管理プロトコル（SNMP）のためのビューベースアクセス制御モデル」[19]は、ビューベースのアクセス制御は、コマンド応答者と通知創始アプリケーション内で適用する方法について説明します。
The Work in Progress, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" [20], describes coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework.
進行中の作業は、[20]「バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存」は、SNMPv3の管理フレームワーク、SNMPv2の管理フレームワーク、及びオリジナルのSNMPv1管理フレームワークとの間の共存を記述する。
7 Document Summaries
7つのドキュメントの概要
The following sections provide brief summaries of each document with slightly more detail than is provided in the overviews above.
以下のセクションでは、上記の概要で提供されるよりも若干詳細と、各文書の簡単な要約を提供します。
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written in the SNMP MIB module language, which contains elements of OSI's Abstract Syntax Notation One (ASN.1) [11] language. STD 58, RFCs 2578, 2579, 2580, together define the MIB module language, specify the base data types for objects, specify a core set of short-hand specifications for data types called textual conventions, and specify a few administrative assignments of object identifier (OID) values.
管理情報は、仮想インフォメーションストアに存在する、管理対象オブジェクトのコレクションとして表示され、管理情報ベース（MIB）と呼ばれます。関連するオブジェクトのコレクションは、MIBモジュールで定義されています。これらのモジュールは、OSIの抽象構文記法1（ASN.1）[11]言語の要素を含むSNMP MIBモジュール言語で書かれています。 STD 58のRFC 2578、2579、2580、一緒に、MIBモジュール言語を定義するオブジェクトの基本データ・タイプを指定し、テキストの表記法と呼ばれるデータ・タイプの短手仕様のコアセットを指定し、オブジェクト識別子のいくつかの管理の割り当てを指定します（OID）値。
The SMI is divided into three parts: module definitions, object definitions, and notification definitions.
モジュール定義、オブジェクト定義、通知定義：SMIは、3つの部分に分割されています。
(1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the semantics of an information module.
情報モジュールを記述する場合、（1）モジュールの定義が使用されます。 ASN.1マクロMODULE-IDENTITYは、簡潔に情報モジュールの意味を伝えるために使用されます。
(2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax and semantics of a managed object.
管理オブジェクトを記述する場合（2）オブジェクトの定義が使用されます。 ASN.1マクロ、OBJECT-TYPEは、簡潔に、管理オブジェクトの構文とセマンティクスを伝えるために使用されます。
(3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to convey concisely the syntax and semantics of a notification.
管理情報の迷惑送信を記述する場合（3）通知定義が使用されます。 ASN.1マクロ、NOTIFICATION-TYPEは、簡潔に通知の構文とセマンティクスを伝えるために使用されます。
STD 58, RFC 2578 specifies the base data types for the MIB module language, which include: Integer32, enumerated integers, Unsigned32, Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, Opaque, and BITS. It also assigns values to several object identifiers. STD 58, RFC 2578 further defines the following constructs of the MIB module language:
構文Integer32、列挙された整数、Unsigned32の、Gauge32、Counter32の、Counter64の、時間刻み、INTEGER、オクテット文字列、オブジェクト識別子、IPアドレス、不透明、およびBITSを：STD 58は、RFC 2578は、MIBモジュール言語の基本データ型を、指定します。それはまた、いくつかのオブジェクト識別子に値を割り当てます。 STD 58、RFC 2578は、さらに、MIBモジュール言語の以下の構造を定義します。
* IMPORTS to allow the specification of items that are used in a MIB module, but defined in another MIB module.
* MIBモジュールで使用されるが、他のMIBモジュールで定義されているアイテムの指定を可能にするためにインポートします。
* MODULE-IDENTITY to specify for a MIB module a description and administrative information such as contact and revision history.
* MODULE-IDENTITYは、接触と改訂履歴としてMIBモジュールの説明および管理情報を指定します。
* OBJECT-IDENTITY and OID value assignments to specify a an OID value.
* OBJECT-IDENTITYとOID値の割り当ては、OID値を指定します。
* OBJECT-TYPE to specify the data type, status, and the semantics of managed objects.
* OBJECT-TYPEは、データタイプ、ステータス、および管理対象オブジェクトのセマンティクスを指定します。
* SEQUENCE type assignment to list the columnar objects in a table.
* SEQUENCEタイプの割り当ては、テーブル内の円柱状のオブジェクトを一覧表示します。
* NOTIFICATION-TYPE construct to specify an event notification.
* NOTIFICATION-TYPEイベント通知を指定するには、構築します。
When designing a MIB module, it is often useful to specify in a short-hand way the semantics for a set of objects with similar behavior. This is done by defining a new data type using a base data type specified in the SMI. Each new type has a different name, and specifies a base type with more restrictive semantics. These newly defined types are termed textual conventions, and are used for the convenience of humans reading a MIB module and potentially by "intelligent" management applications. It is the purpose of STD 58, RFC 2579, Textual Conventions for SMIv2 [27], to define the construct, TEXTUAL-CONVENTION, of the MIB module language used to define such new types and to specify an initial set of textual conventions available to all MIB modules.
MIBモジュールを設計するとき、短い手の方法で同様の振る舞いを持つオブジェクトのセットのためのセマンティクスを指定することが有用であることが多いです。これは、SMIで指定された基本データ型を使用して、新しいデータ型を定義することによって行われます。それぞれの新しいタイプは、別の名前を持っており、より限定的なセマンティクスで基本型を指定します。これらの新たに定義されたタイプは、原文のコンベンションと呼ばれて、MIBモジュールを読んだ人間の便宜のために、潜在的に「インテリジェント」管理アプリケーションで使用されています。そのような新しいタイプを定義することとに使用可能なテキスト規則の初期セットを指定するために使用されるMIBモジュール言語のテキストの表記法、構築物を定義するために、STD 58の目的は、RFC 2579、SMIv2のためのテキストの表記法[27]でありますすべてのMIBモジュール。
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of STD 58, RFC 2580, Conformance Statements for SMIv2 [28], to define the constructs of the MIB module language used for these purposes. There are two kinds of constructs:
それを達成実装の実際のレベルと共に、実装の許容される低境界を定義することが有用であり得ます。これは、これらの目的のために使用されるMIBモジュール言語の構造を定義するために、SMIv2の[28]のための適合性宣言、STD 58、RFC 2580の目的です。コンストラクトの2種類があります。
(1) Compliance statements are used when describing requirements for agents with respect to object and event notification definitions. The MODULE-COMPLIANCE construct is used to convey concisely such requirements.
（1）オブジェクトに対してエージェントイベント通知の定義の要件を記述する際にコンプライアンスステートメントが使用されています。 MODULEコンプライアンス構築物を、簡潔な要件を伝えるために使用されます。
(2) Capability statements are used when describing capabilities of agents with respect to object and event notification definitions. The AGENT-CAPABILITIES construct is used to convey concisely such capabilities.
オブジェクトとイベント通知定義に対する薬剤の能力を記述する場合（2）機能ステートメントが使用されます。 AGENT-CAPABILITIES構築物は、簡潔な能力を伝えるために使用されます。
Finally, collections of related objects and collections of related event notifications are grouped together to form a unit of conformance. The OBJECT-GROUP construct is used to convey concisely the objects in and the semantics of an object group. The NOTIFICATION-GROUP construct is used to convey concisely the event notifications in and the semantics of an event notification group.
最後に、関連するオブジェクトと関連するイベント通知のコレクションのコレクションは、適合性のユニットを形成するために一緒にグループ化されます。オブジェクト・グループの構築物は簡潔でオブジェクトとオブジェクトグループの意味論を伝えるために使用されます。 NOTIFICATION-GROUP構築物は、簡潔でイベント通知やイベント通知グループの意味を伝えるために使用されます。
The management protocol provides for the exchange of messages which convey management information between the agents and the management stations. The form of these messages is a message "wrapper" which encapsulates a Protocol Data Unit (PDU).
管理プロトコルは、エージェントと管理ステーション間で管理情報を伝えるメッセージの交換を提供します。これらのメッセージの形式はプロトコルデータユニット（PDU）をカプセル化するメッセージ「ラッパー」です。
It is the purpose of RFC 1905, Protocol Operations for SNMPv2 [7], to define the operations of the protocol with respect to the sending and receiving of the PDUs.
これは、送信とPDUの受信に対してプロトコルの動作を定義する、[7]、SNMPv2のためのプロトコル操作RFC 1905の目的です。
SNMP Messages may be used over a variety of protocol suites. It is the purpose of RFC 1906, Transport Mappings for SNMPv2 [8], to define how SNMP messages maps onto an initial set of transport domains. Other mappings may be defined in the future.
SNMPメッセージプロトコルスイートの様々な上で使用することができます。これは、SNMPメッセージは、輸送ドメインの最初のセットにマップする方法を定義するには、SNMPv2のための輸送マッピング[8]、RFC 1906の目的です。他のマッピングは、将来的に定義されてもよいです。
Although several mappings are defined, the mapping onto UDP is the preferred mapping. As such, to provide for the greatest level of interoperability, systems which choose to deploy other mappings should also provide for proxy service to the UDP mapping.
複数のマッピングが定義されていますが、UDPへのマッピングは、好適なマッピングです。そのため、相互運用性の最高レベルを提供するために、他のマッピングを配布することを選択したシステムはまた、UDPマッピングへのプロキシサービスを提供すべきです。
It is the purpose of RFC 1907, the Management Information Base for SNMPv2 document [9] to define managed objects which describe the behavior of an SNMPv2 entity.
これは、RFC 1907の目的である、SNMPv2のエンティティの振る舞いを記述する管理対象オブジェクトを定義するためのSNMPv2ドキュメント[9]のための管理情報ベース。
It is the purpose of RFC 2571, "An Architecture for Describing SNMP Management Frameworks" [15], to define an architecture for specifying SNMP Management Frameworks. While addressing general architectural issues, it focuses on aspects related to security and administration. It defines a number of terms used throughout the SNMPv3 Management Framework and, in so doing, clarifies and extends the naming of
SNMP管理フレームワークを指定するためのアーキテクチャを定義するRFC 2571の目的は、「SNMP管理フレームワークを記述するためのアーキテクチャ」[15]、です。一般的なアーキテクチャの問題に対処するが、それはセキュリティと管理に関連する側面に焦点を当てています。これは、SNMPv3の管理フレームワーク全体で使用される用語の数を定義し、そうすることで、明確にし、の命名を拡張します
* engines and applications,
*エンジンとアプリケーション、
* entities (service providers such as the engines in agents and managers),
*エンティティ（たとえば、エージェントとマネージャでエンジンなどのサービスプロバイダ）、
* identities (service users), and
*アイデンティティ（サービス利用者）、および
* management information, including support for multiple logical contexts.
*複数の論理的なコンテキストのサポートを含む管理情報、。
The document contains a small MIB module which is implemented by all authoritative SNMPv3 protocol engines.
文書は、すべての正式なSNMPv3プロトコルエンジンによって実現される小さなMIBモジュールを含んでいます。
RFC 2572, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [16], describes the Message Processing and Dispatching for SNMP messages within the SNMP architecture. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.
RFC 2572、「メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のためにディスパッチ」[16]、メッセージ処理を説明し、SNMPアーキテクチャ内でSNMPメッセージのために派遣。これは、適切なSNMPメッセージ処理モデルにSNMPメッセージの潜在的に複数のバージョンをディスパッチするため、およびSNMPアプリケーションにPDUをディスパッチするための手順を定義します。 SNMPv3のメッセージ処理モデル - この文書は、一つのメッセージ処理モデルについて説明します。
It is expected that an SNMPv3 protocol engine MUST support at least one Message Processing Model. An SNMPv3 protocol engine MAY support more than one, for example in a multi-lingual system which provides simultaneous support of SNMPv3 and SNMPv1 and/or SNMPv2c.
SNMPv3プロトコルエンジンは、少なくとも1つのメッセージ処理モデルをサポートしなければならないことが期待されます。 SNMPv3プロトコルエンジンは、SNMPv3のとSNMPv1および/またはSNMPv2cの同時サポートを提供する多言語システムでは、例えば、1つ以上をサポートするかもしれません。
It is the purpose of RFC 2573, "SNMP Applications" to describe the five types of applications which can be associated with an SNMP engine. They are: Command Generators, Command Responders, Notification Originators, Notification Receivers, and Proxy Forwarders.
SNMPエンジンと関連付けることができる5種類のアプリケーションを記述するための「SNMPアプリケーション」RFC 2573の目的です。彼らは以下のとおりです。コマンドジェネレータ、コマンド応答者、通知のオリジネーター、通知レシーバー、およびプロキシフォワーダ。
The document also defines MIB modules for specifying targets of management operations (including notifications), for notification filtering, and for proxy forwarding.
文書はまた、通知フィルタリングのために、（通知を含む）管理操作の対象を指定するためのMIBモジュールを定義し、プロキシ転送のために。
RFC 2574, the "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" describes the User-based Security Model for SNMPv3. It defines the Elements of Procedure for providing SNMP message-level security.
「簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）」RFC 2574、SNMPv3のユーザベースセキュリティモデルを記述する。これは、SNMPメッセージレベルのセキュリティを提供するための手順の要素を定義します。
The document describes the two primary and two secondary threats which are defended against by the User-based Security Model. They are: modification of information, masquerade, message stream modification, and disclosure.
文書は、ユーザベースセキュリティモデルによりに対して擁護されている2つのプライマリとセカンダリ2脅威について説明します。彼らは以下のとおりです。情報の変更、仮面舞踏会、メッセージストリーム変更、および開示。
The USM utilizes MD5 [21] and the Secure Hash Algorithm [22] as keyed hashing algorithms [23] for digest computation to provide data integrity
USMは、MD5 [21]とデータの整合性を提供するために計算を消化するためのセキュアハッシュアルゴリズム[22]などのキー付きハッシュアルゴリズム[23]を利用します
* to directly protect against data modification attacks,
*直接データ変更攻撃から保護するために、
* to indirectly provide data origin authentication, and
*間接的にデータ発信元認証を提供するために、そして
* to defend against masquerade attacks.
*なりすまし攻撃を防御します。
The USM uses loosely synchronized monotonically increasing time indicators to defend against certain message stream modification attacks. Automatic clock synchronization mechanisms based on the protocol are specified without dependence on third-party time sources and concomitant security considerations.
USMは、特定のメッセージストリーム変更攻撃を防御するために緩やかに同期単調増加する時間インジケーターを使用しています。プロトコルに基づいて自動的にクロック同期メカニズムは、サードパーティのタイムソースと付随するセキュリティ上の考慮事項に依存せずに指定されています。
The USM uses the Data Encryption Standard (DES) [24] in the cipher block chaining mode (CBC) if disclosure protection is desired. Support for DES in the USM is optional, primarily because export and usage restrictions in many countries make it difficult to export and use products which include cryptographic technology.
開示保護が所望される場合USMは、暗号ブロック連鎖方式（CBC）にデータ暗号化規格（DES）[24]を使用します。 USMにおけるDESのサポートは、多くの国の輸出と使用制限は、それが困難な暗号化技術が含まれる製品を輸出して使用するように作る主な理由、オプションです。
The document also includes a MIB suitable for remotely monitoring and managing the configuration parameters for the USM, including key distribution and key management.
文書はまた、リモート鍵配布及び鍵管理を含む、USMのコンフィギュレーションパラメータを監視および管理するのに適したMIBを含みます。
An entity may provide simultaneous support for multiple security models as well as multiple authentication and privacy protocols. All of the protocols used by the USM are based on pre-placed keys, i.e., private key mechanisms. The SNMPv3 architecture permits the use of asymmetric mechanisms and protocols (commonly called "public key cryptography") but as of this writing, no such SNMPv3 security models utilizing public key cryptography have been published.
エンティティは、複数のセキュリティモデルを同時にサポートだけでなく、複数の認証とプライバシープロトコルを提供することができます。 USMによって使用されるプロトコルの全ては、予め配置されたキー、すなわち秘密鍵のメカニズムに基づいています。 SNMPv3アーキテクチャは、非対称のメカニズムとプロトコルの使用を許可する（一般的に「公開鍵暗号」と呼ばれる）が、これを書いている時点では、公開鍵暗号を利用し、そのようなSNMPv3セキュリティモデルが発表されていません。
The purpose of RFC 2575, the "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" is to describe the View-based Access Control Model for use in the SNMP architecture. The VACM can simultaneously be associated in a single engine implementation with multiple Message Processing Models and multiple Security Models.
「簡易ネットワーク管理プロトコル（SNMP）のためのビューベースアクセス制御モデル（VACM）」RFC 2575の目的、SNMPアーキテクチャにおける使用のためのビューベースアクセス制御モデルを記述することです。 VACMは、同時に複数のメッセージ処理モデルと、複数のセキュリティモデルを備えた単一エンジンの実装に関連することができます。
It is architecturally possible to have multiple, different, Access Control Models active and present simultaneously in a single engine implementation, but this is expected to be *_very_* rare in practice and *_far_* less common than simultaneous support for multiple Message Processing Models and/or multiple Security Models.
単一エンジンの実装で同時にアクティブと存在する複数の、異なる、アクセス制御モデルを持っているアーキテクチャも可能であるが、これは実際には稀で、複数のメッセージ処理モデルを同時にサポートより* _far_ *あまり一般的_very_ *を*されることが期待されると/または複数のセキュリティモデル。
The purpose of "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework" is to describe coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework. In particular, this document describes four aspects of coexistence:
「バージョン1、バージョン2、およびインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存」の目的は、SNMPv3の管理フレームワーク、SNMPv2の管理フレームワーク、そしてオリジナルのSNMPv1管理フレームワーク間の共存を記述することです。特に、このドキュメントは、共存の4つの側面について説明します。
* Conversion of MIB documents from SMIv1 to SMIv2 format
でSMIv1からSMIv2の形式にMIBドキュメントの変換*
* Mapping of notification parameters
*通知パラメータのマッピング
* Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network, in particular the processing of protocol operations in multi-lingual implementations, as well as behavior of proxy implementations
*多言語の実装では、特に、多言語ネットワークにおけるプロトコル操作の処理をSNMPのさまざまなバージョンをサポートするエンティティ、ならびにプロキシ実装の挙動の共存へのアプローチ
* The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 and SNMPv2c into the View-Based Access Control Model (VACM) [19]
ビューベースアクセス制御モデル（VACM）[19]にSNMPv1およびSNMPv2cのを適応させるためのメカニズムを提供*のSNMPv1メッセージ処理モデルとコミュニティベースセキュリティモデル、
8 Security Considerations
8セキュリティについての考慮事項
As this document is primarily a roadmap document, it introduces no new security considerations. The reader is referred to the relevant sections of each of the referenced documents for information about security considerations.
この文書は、主にロードマップ文書であるとして、それはどんな新しいセキュリティ問題も紹介しません。読者は、セキュリティ上の考慮事項については、参照文書のそれぞれの関連セクションと呼ばれます。
9 Editors' Addresses
9つのエディタのアドレス
Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA Phone: +1 423 573 1434 EMail: case@snmp.com
ジェフリーケースSNMPリサーチ社3001キンバリンハイツロードノックスビル、テネシー州37920から9716 USA電話：+1 423 573 1434 Eメール：case@snmp.com
Russ Mundy TIS Labs at Network Associates 3060 Washington Rd Glenwood, MD 21738 USA Phone: +1 301 854 6889 EMail: mundy@tislabs.com
ネットワークアソシエイツのラス・マンディTIS Labsの3060オーガスタグレンウッド、MD 21738 USA電話：+1 301 854 6889 Eメール：mundy@tislabs.com
David Partain Ericsson Radio Systems Research and Innovation P.O. Box 1248 SE-581 12 Linkoping Sweden Phone: +46 13 28 41 44 EMail: David.Partain@ericsson.com
デビッドパーテインエリクソン無線システムの研究とイノベーション私書箱ボックス1248 SE-581 12リンショーピンスウェーデン電話：+46 13 28 41 44 Eメール：David.Partain@ericsson.com
Bob Stewart Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 U.S.A. Phone: +1 603 654 6923 EMail: bstewart@cisco.com
ボブスチュワートシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 U.S.A.電話：+1 603 654 6923 Eメール：bstewart@cisco.com
10 References
10本の参考文献
[1] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[1]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990月。
[2] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[2]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[3] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[3]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、 "簡単なネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[4] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための経営情報の構造"、RFC 1902、1月1996。
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[5] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1903、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのテキストの表記法"。
[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, January 1996.
[6] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1904、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための適合性宣言"。
[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[7] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[8] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のための輸送マッピング（SNMPv2の）"、RFC 1906、1996年1月。
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
[9] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のための管理情報ベース（SNMPv2の）"、RFC 1907、1996年1月。
[10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996.
[10] SNMPv2のワーキンググループ、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "バージョン1およびインターネット標準ネットワーク管理フレームワークのバージョン2の間の共存"、RFC 1908、1996年1月。
[11] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
[11]情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）、国際標準化機構の仕様。国際標準8824、（12月、1987）。
[12] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1066, August 1988.
[12] McCloghrie、K.とM.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース"、RFC 1066、1988年8月。
[13] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II, STD 17, RFC 1213, March 1991.
[13] McCloghrie、K.とM.ローズ、TCP / IPベースのインターネットのネットワーク管理のための「管理情報ベース：MIB-II、STD 17、RFC 1213、1991年3月。
[14] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988.
[14]サーフ、V.、 "インターネットネットワークマネージメント規格の開発のためのIABの提言"、RFC 1052、1988年4月。
[15] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[15]ハリントン、D.、PresuhnとR.とB. Wijnen、、RFC 2571、1999年4月 "SNMP管理フレームワークを記述するためのアーキテクチャ"。
[16] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[16]ケース、J.、ハリントン、D.、PresuhnとR.とB. Wijnen、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、RFC 2572、1999年4月。
[17] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[17]レビ、D.、マイヤー、P.とB.スチュワート、 "SNMPアプリケーション"、RFC 2573、1999年4月。
[18] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[18]ブルーメンソール、U.とB. Wijnenの、 "簡易ネットワーク管理プロトコルのバージョン3のためのユーザベースセキュリティモデル（SNMPv3の）"、RFC 2574、1999年4月。
[19] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[19] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（SNMP）"、RFC 2575、1999年4月。
[20] 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", Work in Progress.
[20]フライ、R.、レヴィ、D.、Routhier、S.、およびB. Wijnenの、 "バージョン1、バージョン2、及びインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、ProgressのWork。
[21] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[21]リベスト、R.、 "メッセージダイジェストアルゴリズムMD5"、RFC 1321、1992年4月。
[22] Secure Hash Algorithm. NIST FIPS 180-1, (April, 1995) http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (Postscript)
[22]セキュア・ハッシュ・アルゴリズム。 NIST FIPS 180-1、（1995年4月）http://csrc.nist.gov/fips/fip180-1.txt（ASCII）http://csrc.nist.gov/fips/fip180-1.ps（ポストスクリプト）
[23] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[23] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[24] Data Encryption Standard, National Institute of Standards and Technology. Federal Information Processing Standard (FIPS) Publication 46-1. Supersedes FIPS Publication 46, (January, 1977; reaffirmed January, 1988).
[24]データ暗号化規格、アメリカ国立標準技術研究所。連邦情報処理標準（FIPS）出版46-1。 FIPS出版46、（;再確認1988年1月、1月、1977年）よりも優先されます。
[25] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[25]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[26] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[26] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "経営情報バージョン2（SMIv2）の構造"、STD 58、RFC 2578、 1999年4月。
[27] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[27] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[28] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[28] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
11 Full Copyright Statement
11完全な著作権声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
著作権（C）インターネット協会（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています権利または特定の目的に対する商品性または適合性の黙示の保証を侵害し。」
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。