Network Working Group J. Case
Request for Comments: 3410 SNMP Research, Inc.
Obsoletes: 2570 R. Mundy
Category: Informational Network Associates Laboratories
D. Partain
Ericsson
B. Stewart
Retired
December 2002
Introduction and Applicability Statements for
Internet Standard 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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
アーキテクチャは、時間をかけてフレームワークの進化を可能にするモジュラーなるように設計されています。
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570.
SNMPv1またはSNMPv2のの代わりに、SNMPv3を使用が強く推奨される理由を文書で説明しています。文書はまたのRFC 1157、1441、1901、1909年と1910年は歴史的な状況に移動して引退することをお勧めします。この文書はRFC 2570を廃止します。
Table of Contents
目次
1 Introduction ................................................. 2
2 The Internet Standard Management Framework ................... 3
2.1 Basic Structure and Components ............................. 4
2.2 Architecture of the Internet Standard Management Framework . 4
3 The SNMPv1 Management Framework .............................. 5
3.1 The SNMPv1 Data Definition Language ........................ 6
3.2 Management Information ..................................... 6
3.3 Protocol Operations ........................................ 7
3.4 SNMPv1 Security and Administration ......................... 7
4 The SNMPv2 Management Framework .............................. 8
5 The SNMPv3 Working Group ..................................... 8
6 SNMPv3 Framework Module Specifications ....................... 10
6.1 Data Definition Language ................................... 11
6.2 MIB Modules ................................................ 12
6.3 Protocol Operations and Transport Mappings ................. 13
6.4 SNMPv3 Security and Administration ......................... 13
7 Document Summaries ........................................... 14
7.1 Structure of Management Information ........................ 14
7.1.1 Base SMI Specification ................................... 15
7.1.2 Textual Conventions ...................................... 15
7.1.3 Conformance Statements ................................... 16
7.2 Protocol Operations ........................................ 16
7.3 Transport Mappings ......................................... 16
7.4 Protocol Instrumentation ................................... 17
7.5 Architecture / Security and Administration ................. 17
7.6 Message Processing and Dispatch (MPD) ...................... 17
7.7 SNMP Applications .......................................... 18
7.8 User-based Security Model (USM) ............................ 18
7.9 View-based Access Control (VACM) ........................... 19
7.10 SNMPv3 Coexistence and Transition ......................... 19
8 Standardization Status ....................................... 20
8.1 SMIv1 Status ............................................... 20
8.2 SNMPv1 and SNMPv2 Standardization Status ................... 21
8.3 Working Group Recommendation ............................... 22
9 Security Considerations ...................................... 22
10 References .................................................. 22
11 Editor's Addresses .......................................... 26
12 Full Copyright Statement .................................... 27
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.
さらに、詳細なドキュメントは、それらの間に明確に定義されたインターフェースを指定するために、様々なコンポーネントモジュール間の分離を維持することを試みます。このロードマップ文書は、しかしながら、異なるアプローチをとり、読みやすさの利益のために様々なコンポーネントモジュールの統合されたビューを提供することを試みます。
This document is a work product of the SNMPv3 Working Group of the Internet Engineering Task Force (IETF).
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）のSNMPv3のワーキンググループの成果物です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
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 SNMP Framework share the same basic structure and components. Furthermore, all versions of the specifications of the Internet Standard Management Framework follow the same architecture.
インターネット標準の管理SNMPフレームワークのすべてのバージョン（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 [2]. 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で文書化されたように、フレームワークの継続的な発展を可能にするためだった[2]。本来想定するとき、この機能は、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の管理フレームワークのアーキテクチャでは、多くのおなじみの概念があります。しかし、いくつかのケースでは、用語が多少異なる場合があります。
The original Internet-Standard Network Management Framework (SNMPv1) is defined in the following documents:
オリジナルのインターネット標準ネットワーク管理フレームワーク（SNMPv1のは）次のドキュメントで定義されています。
* STD 16, RFC 1155 [3] 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 [3]管理情報（SMI）、管理の目的のためにオブジェクトを記述し、命名のために使用される機構の構造を定義します。
* STD 16, RFC 1212 [4] 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 [4]管理情報オブジェクトを記述し、命名のためのより簡潔な記述メカニズムを定義するが、SMIと完全に一致しています。
* STD 15, RFC 1157 [5] 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 [5]簡易ネットワーク管理プロトコル（SNMP）、管理オブジェクトとイベント通知へのネットワークアクセスのために使用されるプロトコルを定義します。この文書はまた、イベント通知の初期セットを定義して注意してください。
Additionally, two documents are generally considered companions to these three:
さらに、2つの文書は、一般的に、これらの3の仲間とみなされます。
* STD 17, RFC 1213 [6] which contains definitions for the base set of management information
* STD 17、RFC 1213 [6]、管理情報の基本セットの定義を含んでいます
* RFC 1215 [7] 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 [7] 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, i.e., RFCs 1155, 1212, and 1215, describe the SNMPv1 data definition language and are often collectively referred to as "SMIv1". 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.
二つの第一及び最後のドキュメント、即ち、のRFC 1155、1212、1215、SNMPv1のデータ定義言語を記述し、しばしば集合的に「でSMIv1」と呼ばれます。 SMIは、プロトコルに依存しないことが最初の要求には、最初の2つのSMI文書がイベント通知（トラップ）を定義するための手段を提供しないことに注意してください。代わりに、SNMPプロトコル文書は、いくつかの標準化されたイベント通知（汎用トラップ）を定義し、定義するために追加のイベント通知のための手段を提供します。最後のドキュメントは、SNMPv1プロトコルで使用されるイベント通知の定義に向けた直接的なアプローチを指定します。それが書かれた時点で、インターネット標準ネットワーク管理フレームワークでのトラップの使用は物議ました。このようにして、RFC 1215には、それはSNMPフレームワークの第二のバージョンは、最初のバージョンを置き換えるだろうと信じられていたため、更新されなかった「情報」の状態、と提唱しました。
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 [8], and was subsequently used to define MIB-II as specified in RFC 1213 [6].
最初の二つの文書に記載されたデータ定義言語は、最初の[8] RFC 1066で指定されるように、今、歴史的MIB-Iを定義するために使用し、続いて[6] RFC 1213に指定されているMIB-IIを定義するために使用しました。
Later, after the publication of MIB-II, a different approach to the 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 [5], 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 [5]は、変数バインディングのリストのプロトコルデータユニット（PDU）によって実行されるSNMPv1プロトコルの動作を説明し、SNMPv1のメッセージのフォーマットを記述する。 SNMPv1ので定義された事業者は、次のとおり取得するには、Get-次、取得 - 応答、設定要求、およびトラップ。コネクションレスのトランスポートサービス上のSNMPの典型的なレイヤーも定義されています。
STD 15 [5] 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 [5]また、セキュリティと管理のアプローチを記載します。これらの概念の多くが引き継がれており、いくつかは、特にセキュリティ、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はそのブロック内で使用するためのアーキテクチャだけでなく、そのサブシステムの定義を提供しますので、 。
The SNMPv2 Management Framework is described in [8-13] and coexistence and transition issues relating to SNMPv1 and SNMPv2 are discussed in [15].
SNMPv2の管理フレームワークは[8-13]に記載されており、SNMPv1とSNMPv2のに関連する共存と移行問題は[15]に記載されています。
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の管理フレームワークは、このドキュメントコンパニオン文書で説明したように、これらの重要な欠陥に対処しています。
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),
1991-1992年頃* "SNMPセキュリティ"（RFC 1351 - RFC 1353）、
* "SMP" circa 1992-1993, and
1992-1993年頃*「ジュニア」、および
* "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa 1993-1995 (RFC 1441 - RFC 1452).
（時々 "SNMPv2p" と呼ばれる）* "パーティー・ベースの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) as described in RFC 1901 [16],
* "コミュニティベースのSNMPv2"（SNMPv2cの）RFC 1901年に記載されているように[16]、
* "SNMPv2u" as described in RFCs 1909 and 1910, and
*「SNMPv2u」のRFC 1909および1910で説明したように、そして
* "SNMPv2*."
* "SNMPv2の*。"
SNMPv2c had the most support within the IETF but had no security and administration whereas both SNMPv2u and SNMPv2* had security but lacked a consensus of support within the IETF.
SNMPv2cには、IETF内で最も支援があったが、SNMPv2uとSNMPv2 *の両方のセキュリティを持っていたが、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の承認だけでなく、持っているだけでなく、セキュリティと管理を持つ単一の仕様を生産するという目標を達成しました。
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 documents in the fourth set are new to SNMPv3, but, as described previously, build on significant prior related works.
文書の最初の三組は、SNMPv2から組み込まれています。第4セット内の文書は、前述のように、大幅な従来の関連作品を構築し、SNMPv3のに新しいですが、。
The specifications of the data definition language include STD 58, RFC 2578, "Structure of Management Information Version 2 (SMIv2)" [17], and related specifications. These documents are updates of RFCs 1902 - 1904 [9-11] which have evolved independently from the other parts of the framework and were republished with minor editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when promoted from Draft Standard to full Standard.
データ定義言語の仕様はSTD 58、[17]、及び関連する仕様RFC 2578、「経営情報バージョン2（SMIv2）の構造」を含みます。これらの文書は、RFCの更新である1902年から1904年フレームワークの他の部分から独立して進化したとSTD 58として軽微な編集上の変更で再発行された[9-11]のRFC 2578から2580 [17-19]ドラフト標準から昇格場合フル規格へ。
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.
管理情報（SMIv2の）の構造は、基本データ型、オブジェクトモデル、およびMIBモジュールを書き込み、修正するための規則を定義します。関連の仕様はSTD 58、RFCの2579年、2580年が含まれます。
STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], 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のためのテキストの表記法」[18]、ヒトリーダーとライターの便宜のために、すべてのMIBモジュール内で使用可能な速記の略語の最初のセットを定義します。
STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], 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のための順応文」[19]は、特定の実装の特徴を文書化するために使用することができるエージェントの実装と機能文の要件を記述するために使用されるコンプライアンスステートメントの形式を定義します。
The term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.
用語のユーザーが、それは、少なくとも2つの異なる意味を持っているつもりので、用語「SMIv2のは」やや曖昧です。他の時にはこの曖昧さは不幸であるRFC 2578で定義されたデータ定義言語の一部のみを指すのに使用されるのに対し、2580 - 時々用語のRFC 2578の中で集合的に定義されたSTD 58の全体のデータ定義言語を指すのに使用されますしかし、実際には大きな問題はめったにありません。
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 to 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-track MIB modules, as defined in the periodically updated "Internet Official Protocol Standards" list [20]. As of this writing, there are more than 100 standards-track MIB modules with a total number of defined objects exceeding 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.
定期的に更新され、「インターネット公式プロトコル標準」リスト[20]で定義されている標準トラックMIBモジュールの大規模かつ成長している数が、あります。この記事の執筆時点では、定義されたオブジェクトの合計数が10,000を超えると、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. It can be conveyed by an SNMPv2 or an SNMPv3 engine, but cannot be conveyed by an engine which exclusively supports SNMPv1.
一般に、任意のMIBモジュールで定義された管理情報は、関係なく使用されるデータ定義言語のバージョンのプロトコルのすべてのバージョンで使用することができます。例えば、SNMPv1のSMI（でSMIv1）の観点で定義されたMIBモジュールは、SNMPv3の管理フレームワークと互換性があり、その中に指定されたプロトコルによって搬送することができます。また、SNMPv2のSMI（SMIv2の）に関して定義されたMIBモジュールは、SNMPv1プロトコル操作と互換性があり、それによって搬送することができます。 SMIv2の形式で定義されたMIBモジュールで定義することができるが、SNMPv1プロトコルエンジンによって搬送することができないCounter64のデータ型：しかしながら、注目すべき例外があります。それはSNMPv2のか、SNMPv3エンジンによって搬送することができますが、排他的にSNMPv1のをサポートしてエンジンによって搬送することができません。
The specifications for the protocol operations and transport mappings of the SNMPv3 Framework are incorporated by reference to the two SNMPv2 Framework documents which have subsequently been updated.
SNMPv3フレームワークのプロトコル操作とトランスポートマッピングの仕様はその後更新された2つのSNMPv2フレームワークのドキュメントを参照して組み込まれています。
The specification for protocol operations is found in STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21].
プロトコル操作のための仕様は、「簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2」[21]、STD 62、RFC 3416に見出されます。
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.
SNMPv3のフレームワークは、アーキテクチャの様々な部分は、独立して進化できるように設計されています。例えば、追加のプロトコル操作を可能にするフレームワーク内で定義されるプロトコル操作の新たな指定可能であるかもしれません。
The specification of transport mappings is found in STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22].
トランスポートマッピングの仕様はSTD 62、RFC 3417で発見され、「簡易ネットワーク管理プロトコル（SNMP）のためのマッピングを輸送します」[22]。
The document series pertaining to SNMPv3 Security and Administration defined by the SNMPv3 Working Group consists of seven documents at this time:
SNMPv3のワーキンググループによって定義されたSNMPv3のセキュリティと管理に関連するドキュメントシリーズは、この時点で7つの文書で構成されています。
RFC 3410, "Introduction and Applicability Statements for the Internet-Standard Management Framework", which is this document.
RFC 3410、この文書で、「インターネット標準の管理フレームワークのための序論と適用性声明」。
STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], describes the overall architecture with special emphasis on the architecture for security and administration.
STD 62、RFC 3411には、「簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャは、」[23]は、セキュリティと管理のためのアーキテクチャ上の特別な重点を置いて、全体的なアーキテクチャについて説明します。
STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], describes the possibility of multiple message processing models and the dispatcher portion that can be a part of an SNMP protocol engine.
STD 62、RFC 3412、「メッセージ処理と簡易ネットワーク管理プロトコル（SNMP）のためのディスパッチ」[24]は、複数のメッセージ処理モデルおよびSNMPプロトコルエンジンの一部とすることができるディスパッチャ部分の可能性を記載しています。
STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25], describes the five initial types of applications that can be associated with an SNMPv3 engine and their elements of procedure.
STD 62、RFC 3413、「簡易ネットワーク管理プロトコル（SNMP）アプリケーション」[25]は、5つの初期SNMPv3エンジンと関連付けることができるアプリケーションの種類や手続きの彼らの要素について説明します。
STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)" [26], describes the threats against which protection is provided, as well as the mechanisms, protocols, and supporting data used to provide SNMP message-level security with the user-based security model.
STD 62、RFC 3414、「簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）」[26]、保護が提供され、これに対して脅威だけでなく、メカニズム、プロトコルを記述し、ユーザベースのセキュリティモデルと、SNMPメッセージレベルのセキュリティを提供するために使用されるデータをサポートします。
STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the Simple Network Management Protocol (SNMP)" [27], describes how view-based access control can be applied within command responder and notification originator applications.
STD 62、RFC 3415、「簡易ネットワーク管理プロトコル（SNMP）のためのビューベースアクセス制御モデル（VCAM）」[27]は、ビューベースのアクセス制御は、コマンド応答者と通知創始アプリケーション内で適用する方法について説明します。
RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes coexistence between the SNMPv3 Management Framework, the SNMPv2 Management Framework, and the original SNMPv1 Management Framework, and is in the process of being updated by a Work in Progress.
RFC 2576、「SNMPv3の共存と移行」[28]は、SNMPv3の管理フレームワーク、SNMPv2の管理フレームワーク、及びオリジナルのSNMPv1管理フレームワークとの間の共存を説明し、そして進行中の作業によって更新中です。
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 data definition language, which evolved from an adapted subset of OSI's Abstract Syntax Notation One (ASN.1) [29] language. STD 58, RFCs 2578, 2579, 2580, collectively define the data definition 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）[29]言語の適合サブセットから進化したSNMPデータ定義言語で書かれています。 STD 58のRFC 2578、2579、2580は、集合的に、オブジェクトの基本データ・タイプを指定し、データ定義言語を定義するテキストの表記法と呼ばれるデータ・タイプの短手仕様のコアセットを指定し、オブジェクト識別子のいくつかの管理の割り当てを指定します（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は、簡潔に通知の構文とセマンティクスを伝えるために使用されます。
As noted earlier, the term "SMIv2" is somewhat ambiguous because users of the term intend it to have at least two different meanings. Sometimes the term is used to refer to the entire data definition language of STD 58, defined collectively in RFCs 2578 - 2580 whereas at other times it is used to refer to only the portion of the data definition language defined in RFC 2578. This ambiguity is unfortunate but is rarely a significant problem in practice.
先に述べたように、用語のユーザは、少なくとも2つの異なる意味を持っていることを意図しているため、用語「SMIv2のは」やや曖昧です。他の時にはこの曖昧さは、RFC 2578で定義されたデータ定義言語の一部のみを指すのに使用されるのに対し、2580 - 時々用語のRFC 2578の中で集合的に定義されたSTD 58の全体のデータ定義言語を指すのに使用されます不幸しかし、実際にはほとんど重大な問題ではありません。
STD 58, RFC 2578 specifies the base data types for the data definition 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 data definition language:
構文Integer32、列挙された整数、Unsigned32の、Gauge32、Counter32の、Counter64の、時間刻み、INTEGER、オクテット文字列、オブジェクト識別子、IPアドレス、不透明、およびBITSを：STD 58は、RFC 2578には、データ定義言語の基本データ型を、指定します。それはまた、いくつかのオブジェクト識別子に値を割り当てます。 STD 58、RFC 2578は、データ定義言語の次の構成を定義します。
* 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 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,
MIBモジュールを設計するとき、短い手のやり方で、同様の振る舞いを持つオブジェクトのセットのためのセマンティクスを指定することが有用であることが多いです。これは、SMIで指定された基本データ型を使用して、新しいデータ型を定義することによって行われます。それぞれの新しいタイプは、別の名前を持っており、より限定的なセマンティクスで基本型を指定します。これらの新たに定義されたタイプは、原文のコンベンションと呼ばれて、MIBモジュールを読んだ人間の便宜のために、潜在的に「インテリジェント」管理アプリケーションで使用されています。これは、STD 58の目的です、
RFC 2579, Textual Conventions for SMIv2 [18], to define the construct, TEXTUAL-CONVENTION, of the data definition language used to define such new types and to specify an initial set of textual conventions available to all MIB modules.
このような新しいタイプを定義し、すべてのMIBモジュールに利用可能なテキスト表記の最初のセットを指定するために使用されるデータ定義言語のテキストの表記法を、構築物を規定するRFC 2579、SMIv2のためのテキストの表記法[18]。
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 [19], to define the constructs of the data definition language used for these purposes. There are two kinds of constructs:
それを達成実装の実際のレベルと共に、実装の許容される低境界を定義することが有用であり得ます。これは、これらの目的のために使用されるデータ定義言語の構文を定義するために、SMIv2の[19]のための適合性宣言、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 STD 62, RFC 3416, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)" [21], to define the operations of the protocol with respect to the sending and receiving of the PDUs.
これは、送信とPDUの受信に対してプロトコルの動作を定義するために、「簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2」、[21] STD 62、RFC 3416の目的です。
SNMP messages may be used over a variety of protocol suites. It is the purpose of STD 62, RFC 3417, "Transport Mappings for the Simple Network Management Protocol (SNMP)" [22], to define how SNMP messages
SNMPメッセージは、プロトコル・スイートのさまざま上で使用することができます。それはどのようにSNMPメッセージを定義するには、「簡易ネットワーク管理プロトコル（SNMP）のための輸送マッピング」、[22] STD 62、RFC 3417の目的です
map onto an initial set of transport domains. Other mappings may be defined in the future.
輸送ドメインの最初のセットにマップされます。他のマッピングは、将来的に定義されてもよいです。
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 STD 62, RFC 3418, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)" [30], to define managed objects which describe the behavior of portions of an SNMP entity.
これは、SNMPエンティティの部分の挙動を記述する管理オブジェクトを定義するために、STD 62の目的は、RFC 3418、「簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）」[30]です。
It is the purpose of STD 62, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" [23], to define an architecture for specifying 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:
これは、管理フレームワークを指定するためのアーキテクチャを定義するために、[23]、「簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」STD 62、RFC 3411の目的です。一般的なアーキテクチャの問題に対処するが、それはセキュリティと管理に関連する側面に焦点を当てています。これは、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モジュールを含んでいます。
STD 62, RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" [24], 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.
STD 62、RFC 3412、「メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のためにディスパッチ」[24]は、メッセージ処理を説明し、SNMPアーキテクチャ内でSNMPメッセージのために派遣します。これは、適切なSNMPメッセージ処理モデルにSNMPメッセージの潜在的に複数のバージョンをディスパッチするため、およびSNMPアプリケーションにPDUをディスパッチするための手順を定義します。 SNMPv3のメッセージ処理モデル - この文書は、一つのメッセージ処理モデルについて説明します。
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. For example, such a tri-lingual system which provides simultaneous support for SNMPv1, SNMPv2c, and SNMPv3 supports three message processing models.
SNMPv3プロトコルエンジンは、少なくとも1つのメッセージ処理モデルをサポートしなければなりません。 SNMPv3プロトコルエンジンは、SNMPv3のとSNMPv1および/またはSNMPv2cの同時サポートを提供する多言語システムでは、例えば、1つ以上をサポートするかもしれません。例えば、SNMPv1、SNMPv2c、およびSNMPv3に対する同時サポートを提供トリ言語システムは、3つのメッセージ処理モデルをサポートします。
It is the purpose of STD 62, RFC 3413, "Simple Network Management Protocol (SNMP) Applications" [25] 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種類のアプリケーションを記述するためにSTD 62の目的は、RFC 3413、「簡易ネットワーク管理プロトコル（SNMP）アプリケーション」[25]です。彼らは以下のとおりです。コマンドジェネレータ、コマンド応答者、通知のオリジネーター、通知レシーバー、およびプロキシフォワーダ。
The document also defines MIB modules for specifying targets of management operations (including notifications), for notification filtering, and for proxy forwarding.
文書はまた、通知フィルタリングのために、（通知を含む）管理操作の対象を指定するためのMIBモジュールを定義し、プロキシ転送のために。
STD 62, RFC 3414, the "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)" [26] describes the User-based Security Model for SNMPv3. It defines the Elements of Procedure for providing SNMP message-level security.
「簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）」STD 62、RFC 3414、[26]は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 [31] and the Secure Hash Algorithm [32] as keyed hashing algorithms [33] for digest computation to provide data integrity:
USMは、MD5 [31]とセキュアハッシュアルゴリズム[33]データの整合性を提供するために計算を消化するための[32]などのキー付きハッシュアルゴリズムを利用します。
* 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) [34] 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）[34]を使用します。 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 symmetric and asymmetric mechanisms and protocols (asymmetric mechanisms are commonly called public key cryptography) but, as of this writing, there are no SNMPv3 security models on the IETF standards track that use public key cryptography.
エンティティは、複数のセキュリティモデルを同時にサポートだけでなく、複数の認証とプライバシープロトコルを提供することができます。 USMによって使用されるプロトコルの全ては、予め配置されたキー、すなわち秘密鍵のメカニズムに基づいています。 SNMPv3アーキテクチャは、これを書いているとして、公開鍵暗号を使用するIETF標準トラックにはSNMPv3セキュリティモデルが存在しない、対称および非対称のメカニズムとプロトコルの使用を許可する（非対称のメカニズムは、一般的に、公開鍵暗号方式と呼ばれている）が、。
Work is underway to specify how AES is to be used within the User-based Security Model (USM). This will be a separate document.
仕事はAESは、ユーザベースセキュリティモデル（USM）内で使用する方法を指定するために進行中です。これは、別の文書になります。
The purpose of STD 62, RFC 3415, the "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)" [27], 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.
STD 62の目的は、RFC 3415、「簡易ネットワーク管理プロトコル（SNMP）のためのビューベースアクセス制御モデル（VACM）」[27]は、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 RFC 2576, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework" [28], 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:
RFC 2576の目的は、「バージョン1、バージョン2の間の共存、およびインターネット標準ネットワーク管理フレームワークのバージョン3」[28]は、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) [27]
ビューベースアクセス制御モデル（VACM）[27]にSNMPv1およびSNMPv2cのを適応させるためのメカニズムを提供*のSNMPv1メッセージ処理モデルとコミュニティベースセキュリティモデル、
Readers should consult the latest version of the "Internet Official Protocol Standards" list [20] to determine the standardization status of any document.
読者は、任意の文書の標準化の状態を判断するためには、「Internet Official Protocol Standards」リスト[20]の最新バージョンを相談してください。
However, the SNMPv3 Working Group explicitly requested that text be included in this document to amplify on the status of SMIv1, SNMPv1, and SNMPv2c.
しかし、SNMPv3のワーキンググループは、明示的にテキストがでSMIv1、SNMPv1の、およびSNMPv2cの状態で増幅するために、本文書に含まれていることを要求しました。
SMIv1, as described in STD 16, RFCs 1155 and 1212, was promoted to full Standard status in 1990 and has remained a Standard even after SMIv2 reached full Standard (see RFC 2026 [35] for more information about the Internet Standards Process). In many cases, a Standard is declared "Historic" when its replacement reaches full Standard. For example, MIB-1 [8] was declared "Historic" when MIB-2 [6] reached full Standard. Similarly, when SMIv2 reached full Standard, it might have been reasonable at that time to retire SMIv1 and declare it to be "Historic" but as the result of a conscious decision, STD 16, RFCs 1155 and 1212 continue to have the standardization status of full "Standard" but are not recommended. These documents were not declared "Historic" and remain on the standards track because they provide normative references for other documents on the standards track and cannot be declared "Historic" without rendering the documents which rely on them to also become "Historic". Consequently, STD 16 retains its standardization status but is not recommended because it has been superseded by the newer SMIv2 specifications which are identified somewhat later in this document.
でSMIv1は、STD 16、RFC 1155とRFC 1212に記載されているように、1990年に完全な標準状態に昇格し、SMIv2のがフル標準（インターネット標準化過程の詳細は、RFC 2026 [35]参照）に達した後でも、標準のままでいます。その交換が完全な標準に達したとき、多くの場合、標準では「歴史的」と宣言されます。 MIB-2 [6]フル標準に達したとき、例えば、MIB-1 [8]、 "歴史" と宣言しました。同様のSMIv2がフル標準に達したとき、それはでSMIv1を引退し、「歴史的」であることを、それを宣言するために、その時点で合理的であったかもしれないが、意識的な決断、STD 16の結果として、RFC 1155とRFC 1212は、標準化の状態を持ち続けます完全な「標準」が、推奨されていません。これらの文書は「歴史的」と宣言し、それらが標準トラック上の他の文書のための規範的な参照を提供し、また、「歴史的」になるためにそれらに依存しているドキュメントをレンダリングすることなく、「歴史的」と宣言することはできませんので、基準がトラック上に残っていませんでした。その結果、STD 16は、その標準化の状態を保持するが、それは、この文書でやや後に識別され、新しいSMIv2の仕様に取って代わられているのでお勧めしません。
On a pragmatic level, since about 1993 it has been wise for users of the data definition language to use SMIv2 for all new work because the realities of the marketplace have occasionally required the support of data definitions in both the SMIv1 and SMIv2 formats. While there are tools widely available at low cost or no cost to translate SMIv2 definitions to SMIv1 definitions, it is impractical to build automatic tools that automatically translate SMIv1 definitions to SMIv2 definitions. Consequently, if one works in primarily SMIv2, the cost of providing data definitions in both SMIv1 and SMIv2 formats is trivial. In contrast, if one works primarily in SMIv1 format, providing data definitions in both SMIv1 and SMIv2 is significantly more expensive. The market requirements today for providing data definitions in SMIv1 format are greatly diminished when compared to those of 1993, and SMIv2 continues to be the strongly preferred format even though SMIv1 has not been declared "Historic". Indeed, the IETF currently requires that new MIB modules be written using SMIv2.
市場の現実が時折両方でSMIv1とSMIv2のフォーマットのデータ定義のサポートを必要としているので、実用的なレベルでは、およそ1993年以来、それはすべての新しい仕事のためのSMIv2を使用するには、データ定義言語のユーザーのための賢明されています。でSMIv1定義にSMIv2の定義を翻訳する低コストまたは無償で広く利用可能なツールがありますが、自動的にSMIv2の定義にでSMIv1定義を翻訳自動ツールを構築することは非現実的です。 1は主にSMIv2の中で動作するかどうかしたがって、両方でSMIv1とSMIv2のフォーマットでデータ定義を提供するコストは自明です。 1がでSMIv1とSMIv2の両方にデータ定義を提供し、主にでSMIv1フォーマットで動作するかどうかは対照的に、かなり高価です。 1993年のものと比較した場合、でSMIv1形式のデータ定義を提供するため、市場の要件今日は大幅に減少している、とSMIv2のはでSMIv1は「歴史的」と宣言されていないにもかかわらず、非常に好ましい形式であり続けています。確かに、IETFは現在、新しいMIBモジュールがSMIv2のを使用して書かれている必要があります。
Protocol operations via SNMPv1 and SNMPv2c message wrappers support only trivial authentication based on plain-text community strings and, as a result, are fundamentally insecure. When the SNMPv3 specifications for security and administration, which include strong security, reached full Standard status, the full Standard SNMPv1, formerly STD 15 [5], and the experimental SNMPv2c specifications described in RFC 1901 [16] were declared Historic due to their weaknesses with respect to security and to send a clear message that the third version of the Internet Standard Management Framework is the framework of choice. The Party-based SNMPv2 (SNMPv2p), SNMPv2u, and SNMPv2* were either declared Historic circa 1995 or were never on the standards track.
SNMPv1およびSNMPv2cのメッセージラッパーを介したプロトコル操作はプレーンテキストのコミュニティストリングに基づいてのみ些細な認証をサポートして、その結果として、基本的に安全ではありません。強力なセキュリティを含むセキュリティおよび管理のためのSNMPv3の仕様は、完全な標準状態に達したとき、完全な標準のSNMPv1、以前STD 15 [5]、およびRFC 1901年に記載された実験SNMPv2cの仕様[16]、それらの弱点に歴史的に宣言されましたセキュリティに関しては、インターネット標準管理フレームワークの3番目のバージョンは、選択したフレームワークである明確なメッセージを送信します。パーティー・ベースのSNMPv2（SNMPv2p）、SNMPv2u、およびSNMPv2 *は、いずれかであった歴史的な年頃1995を宣言したり標準化過程の上ことはありませんでした。
On a pragmatic level, it is expected that a number of vendors will continue to produce and users will continue to deploy and use multi-lingual implementations that support SNMPv1 and/or SNMPv2c as well as SNMPv3. It should be noted that the IETF standards process does not control actions of vendors or users who may choose to promote or deploy historic protocols, such as SNMPv1 and SNMPv2c, in spite of known short-comings. However, it is not expected that vendors will produce nor that users will deploy multi-lingual implementations that support the Party-based SNMPv2p (SNMPv2p), SNMPv2u, or SNMPv2*.
実用レベルでは、多くのベンダーが生産し続け、ユーザーが展開およびSNMPv1および/またはSNMPv2cのと同様のSNMPv3をサポートする多言語の実装を使用し続けることが予想されます。 IETFの標準化プロセスは、既知の短欠点にもかかわらず、促進や、SNMPv1とSNMPv2cのよう歴史的なプロトコルを展開することもできますベンダーやユーザーの行動を制御しないことに留意すべきです。しかし、ベンダーが生成されることも、ユーザーが党ベースSNMPv2p（SNMPv2p）、SNMPv2u、またはSNMPv2の*をサポートする多言語の実装を展開することが期待されていません。
Indeed, as described above, one of the SNMPv3 specifications for security and administration, RFC 2576, Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Management Framework [28], addresses these issues.
上述のように実際に、バージョン1、バージョン2、及びインターネット標準管理フレームワーク[28]のバージョン3との間のセキュリティと管理、RFC 2576、共存のためのSNMPv3仕様の1つは、これらの問題に対処します。
Of course, it is important that users deploying multi-lingual systems with insecure protocols exercise sufficient due diligence to insure that configurations limit access via SNMPv1 and SNMPv2c appropriately, in keeping with the organization's security policy, just as they should carefully limit access granted via SNMPv3 with a security level of no authentication and no privacy which is roughly equivalent from a security point of view. For example, it is probably unwise to allow SNMPv1 or SNMPv2c a greater level of access than is provided to unauthenticated SNMPv3 users, e.g., it does not make sense to guard the front door with armed guards, trained attack dogs, moats and drawbridges while providing unfettered access through an open back door.
もちろん、安全でないプロトコルと多言語システムを導入するユーザーが構成が、彼らは慎重にSNMPv3の経由で許可されるアクセスを制限する必要があります同じように、組織のセキュリティポリシーに合わせて、適切にSNMPv1およびSNMPv2cのを経由してアクセスを制限することを保証するのに十分なデューデリジェンスを行使することが重要です認証なしのセキュリティ・レベルとセキュリティの観点からほぼ等しいプライバシーなしています。例えば、提供しながら、SNMPv1またはSNMPv2cのは、認証されていないSNMPv3ユーザ、例えばに提供されるよりも、アクセスの高いレベル、それは武装警備員、訓練を受けた攻撃犬、堀や跳ね橋とフロントドアを守るために意味をなさない可能にし、おそらく賢明ではありませんオープンバックドアから自由なアクセス。
The SNMPv1 framework, SNMPv2 framework, and SNMPv2c had limited capabilities for administering the SNMPv1 and SNMPv2c protocols. For example, there are no objects defined to view and configure communities or destinations for notifications (traps and informs). The result has been vendor defined mechanisms for administration that range from proprietary format configuration files that cannot be viewed or configured via SNMP to enterprise specific object definitions. The SNMPv3 framework provides a rich standards-based approach to administration which, by design, can be used for the SNMPv1 and SNMPv2c protocols. Thus, to foster interoperability of administration of SNMPv1 and SNMPv2c protocols in multi-lingual systems, the mechanisms and objects specified in [25], [27], and [28] should be used to supplement or replace the equivalent proprietary mechanisms.
SNMPv1のフレームワーク、SNMPv2のフレームワーク、およびSNMPv2cは、SNMPv1とSNMPv2cプロトコルを管理するための限られた能力を持っていました。たとえば、表示および通知（トラップおよび情報）のためのコミュニティや目的地を設定するために定義されたオブジェクトがありません。結果は、ベンダー企業、特定のオブジェクト定義にSNMPを介して表示したり設定することができない独自の形式のコンフィギュレーションファイルの範囲で投与するためのメカニズムが定義されています。 SNMPv3フレームワークは、設計により、SNMPv1とSNMPv2cのプロトコルのために使用することができる管理に豊富な標準ベースのアプローチを提供します。したがって、多言語システムでのSNMPv1およびSNMPv2cプロトコルの投与の相互運用性を促進するために、機構およびオブジェクト[25]で指定された、[27]及び[28]補完または同等の独自のメカニズムを置換するために使用されるべきです。
Based on the explanations above, the SNMPv3 Working Group recommends that RFCs 1157, 1441, 1901, 1909 and 1910 be reclassified as Historical documents.
上記の説明に基づいて、SNMPv3のワーキンググループはRFCの1157、1441、1901、1909年と1910年は歴史的文書として再分類することをお勧めします。
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.
この文書は、主にロードマップ文書であるとして、それはどんな新しいセキュリティ問題も紹介しません。読者は、セキュリティ上の考慮事項については、参照文書のそれぞれの関連セクションと呼ばれます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988.
[2]サーフ、V.、 "インターネットネットワークマネージメント規格の開発のためのIABの提言"、RFC 1052、1988年4月。
[3] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[3]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990月。
[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[4]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[5] Case, J., Fedor, M., Schoffstall, M. and Davin, J., "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[5]ケース、J.、ヒョードル、M.、Schoffstall、M.およびデーヴィン、J.、 "簡易ネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[6] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[6] McCloghrie、K.とM.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II"、STD 17、RFC 1213、1991年3月。
[7] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[7]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[8] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, March 1990.
[8] McCloghrie、K.とM.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース"、RFC 1156、1990年3月を。
[9] 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.
[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための経営情報の構造"、RFC 1902、1996年1月。
[10] 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.
[10]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1903、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのテキストの表記法"。
[11] 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.
[11]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1904、1996年1月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための順応文"。
[12] 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.
[12]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[13] 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.
[13]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、RFC 1906 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのトランスポートマッピング"、1996年1月。
[14] 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.
[14]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース（SNMPv2の）"、RFC 1907、1996年1月。
[15] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-Standard Network Management Framework", RFC 2576, January 1996.
[15]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "バージョン1およびインターネット標準ネットワーク管理フレームワークのバージョン2の間の共存"、RFC 2576、1996年1月。
[16] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[16]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。
[17] 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.
[17] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "経営情報バージョン2（SMIv2）の構造"、STD 58、RFC 2578、 1999年4月。
[18] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[18] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[19] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[19] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[20] "Official Internet Protocol Standards", http://www.rfc-editor.org/rfcxx00.html also STD0001.
[20] "公式のインターネットプロトコル標準"、http://www.rfc-editor.org/rfcxx00.htmlもSTD0001。
[21] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[21] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"、STD 62、RFC 3416 、2002年12月。
[22] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[22] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "トランスポートマッピングのSNMP（Simple Network Management Protocol）について"、STD 62、RFC 3417、2002年12月。
[23] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[23]ハリントン、D.、PresuhnとR.とB. Wijnen、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[24] 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.
[24]ケース、J.、ハリントン、D.、PresuhnとR.とB. Wijnen、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、STD 62、RFC 3412、2002年12月。
[25] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[25]レビ、D.、マイヤー、P.とB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
[26] 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.
、STD 62、RFC 3414、2002年12月[26]ブルーメンソール、U.とB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）"。
[27] 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.
[27] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "ビューベースアクセス制御モデル（VACM）簡易ネットワーク管理プロトコル（SNMP）のために"、STD 62、RFC 3415、2002年12月。
[28] 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", RFC 2576, March 2000.
[28]フライ、R.、レヴィ、D.、Routhier、S.およびB. Wijnenの、 "バージョン1、バージョン2、およびインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、RFC 2576、2000年3月。
[29] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
[29]情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）、国際標準化機構の仕様。国際標準8824、（12月、1987）。
[30] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
、STD 62、RFC 3418 "簡易ネットワーク管理プロトコル（SNMP）管理情報ベース（MIB）" [30] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 、2002年12月。
[31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[31]リベスト、R.、 "メッセージダイジェストアルゴリズムMD5"、RFC 1321、1992年4月。
[32] 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)
[32]セキュア・ハッシュ・アルゴリズム。 NIST FIPS 180-1、（1995年4月）http://csrc.nist.gov/fips/fip180-1.txt（ASCII）http://csrc.nist.gov/fips/fip180-1.ps（ポストスクリプト）
[33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[33] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[34] 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).
[34]データ暗号化規格、アメリカ国立標準技術研究所。連邦情報処理標準（FIPS）出版46-1。 FIPS出版46、（;再確認1988年1月、1月、1977年）よりも優先されます。
[35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October, 1996.
[35]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA
ジェフリーケースSNMPリサーチ社3001キンバリンハイツロードノックスビル、テネシー州37920から9716 USA
Phone: +1 865 573 1434 EMail: case@snmp.com
電話：+1 865 573 1434 Eメール：case@snmp.com
Russ Mundy Network Associates Laboratories 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA
ラスマンディネットワークアソシエイツ研究所15204オメガドライブ、スイート300ロックビル、MD 20850から4601 USA
Phone: +1 301 947 7107 EMail: mundy@tislabs.com
電話：+1 301 947 7107 Eメール：mundy@tislabs.com
David Partain Ericsson P.O. Box 1248 SE-581 12 Linkoping Sweden
デビッドパーテインエリクソン私書箱ボックス1248 SE-581 12リンシェーピングスウェーデン
Phone: +46 13 28 41 44 EMail: David.Partain@ericsson.com
電話：+46 13 28 41 44 Eメール：David.Partain@ericsson.com
Bob Stewart Retired
ボブ・スチュワート退職
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。