[要約] RFC 3410は、インターネット標準の管理フレームワークに関する導入と適用性について説明しています。このRFCの目的は、インターネットのネットワーク管理に関する基本的な概念と原則を提供することです。
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.
Copyright（c）The Internet Society（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).
このドキュメントの目的は、SNMPバージョン3フレームワーク（SNMPV3）と呼ばれるインターネット標準管理フレームワークの3番目のバージョンの概要を提供することです。このフレームワークは、元のインターネット標準管理フレームワーク（SNMPV1）と2番目のインターネット標準管理フレームワーク（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を使用することが強く推奨される理由を説明しています。また、この文書は、RFCS 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.
このドキュメントは、SNMPバージョン3管理フレームワーク（SNMPV3）と呼ばれるインターネット標準管理フレームワークの3番目のバージョンの紹介であり、複数の目的があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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）と2番目のインターネット標準管理フレームワーク（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),
* 管理アプリケーションを備えた少なくとも1つの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.
このモジュール性の主要な動機の1つは、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
* これらの4つの基本的なアーキテクチャコンポーネントに基づいて、場合によっては参照により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]は、管理されたオブジェクトへのネットワークアクセスとイベント通知に使用されるプロトコルであるSimple Network Management Protocol（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フレームワークの最初のバージョンの4つの部分を説明しています。
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.
最初の2つと最後のドキュメント、つまりRFCS 1155、1212、および1215は、SNMPV1データ定義言語を記述し、しばしば「SMIV1」と呼ばれます。SMIがプロトコルに依存しないという初期要件により、最初の2つのSMIドキュメントはイベント通知（TRAP）を定義する手段を提供しないことに注意してください。代わりに、SNMPプロトコルドキュメントは、いくつかの標準化されたイベント通知（汎用トラップ）を定義し、追加のイベント通知を定義する手段を提供します。最後のドキュメントは、SNMPV1プロトコルで使用されるイベント通知を定義するための簡単なアプローチを指定します。それが書かれた時点で、インターネット標準のネットワーク管理フレームワークでのトラップの使用は議論の余地がありました。そのため、RFC 1215は「情報」のステータスで提案されました。これは、SNMPフレームワークの2番目のバージョンが最初のバージョンを置き換えると考えられていたため、更新されませんでした。
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].
最初の2つのドキュメントで説明されているデータ定義言語は、最初にRFC 1066 [8]で指定されている現在の歴史的なMIB-Iを定義するために使用され、その後、RFC 1213 [6]で指定されている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の焦点を絞った部分の仕様を作成するためにチャーターされたグループによって並行して分散されたファッションで作成され、ネットワーク管理のさまざまな側面からの特定の分野の専門知識を持つ人員が配置されました。システム管理、およびアプリケーション管理。
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.
3番目のドキュメントであるSTD 15 [5]は、可変バインディングのリストでプロトコルデータユニット（PDU）によって実行されるSNMPV1プロトコル操作を説明し、SNMPV1メッセージの形式を説明します。SNMPV1で定義されている演算子は、Get、Get-Next、Get-Response、Set-Request、およびTrapです。Connectionless Transport Serviceでの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フレームワークはそのブロック内で使用するアーキテクチャを提供し、サブシステムの定義を提供します。
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は、以下を含むいくつかの利点を提供します。
* expanded data types (e.g., 64 bit counter)
* 拡張されたデータ型（例：64ビットカウンター）
* improved efficiency and performance (get-bulk operator)
* 効率とパフォーマンスの向上（Get-Bulkオペレーター）
* 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.
このドキュメントとそのコンパニオンドキュメントは、インターネットエンジニアリングタスクフォース（IETF）のSNMPV3ワーキンググループによって作成されました。SNMPV3ワーキンググループは、次世代のSNMPに関する推奨事項を準備するためにチャーターされました。ワーキンググループの目標は、次世代のコアSNMP関数に単一の基準を提供する必要なドキュメントセットを作成することでした。次世代における単一の最も重要なニーズは、SNMPベースの管理トランザクションをセキュリティと管理の定義であり、SNMPV3を使用してネットワークを管理したいユーザーに役立つ方法で安全になります。これらのネットワークを構成するシステムであるマネージャーからエージェント、エージェントからマネージャー、マネージャー間トランザクションなど、これらのシステムに存在するアプリケーション。
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年頃の「SMP」
* "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa 1993-1995 (RFC 1441 - RFC 1452).
* 「パーティーベースのSNMPV2」（「SNMPV2P」と呼ばれることもあります）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:
これらの取り組みは、RFCS 1902-1908で説明されているようにSNMPV2管理フレームワークの開発を提供しました。ただし、これらのRFCに説明されているフレームワークには、独自の標準ベースのセキュリティと管理フレームワークがありませんでした。むしろ、以下を含む複数のセキュリティおよび管理フレームワークに関連付けられていました。
* "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901 [16],
* RFC 1901 [16]に記載されている「コミュニティベースのSNMPV2」（SNMPV2C）、
* "SNMPv2u" as described in RFCs 1909 and 1910, and
* RFCS 1909および1910で説明されている「SNMPV2U」と
* "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ワーキンググループは、「ホイールを再発明する」ことはありませんでしたが、SNMPV2ドラフト標準ドキュメント、つまりRFCS 1902から1908年から1908年から1908年までのフォーカス範囲外の部分を再利用しました。
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.
最初の3セットのドキュメントは、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、RFC 2578、「管理情報の構造バージョン2（SMIV2）」[17]、および関連する仕様が含まれます。これらのドキュメントは、フレームワークの他の部分から独立して進化し、STD 58、RFCS 2578-2580 [17-19]として、ドラフトスタンダードから宣伝されたときにマイナーな編集の変更で再出版されたRFCS 1902-1904 [9-11]の更新です完全な標準へ。
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、RFCS 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.
「Smiv2」という用語は、少なくとも2つの異なる意味を持つことを意図しているため、「SMIV2」という用語はやや曖昧です。この用語は、RFCS 2578-2580で集合的に定義されているSTD 58のデータ定義言語全体を参照するために使用されることがありますが、他の場合はRFC 2578で定義されたデータ定義言語の部分のみを参照するために使用されます。しかし、実際には重大な問題になることはめったにありません。
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モジュールが大幅に増加しています。この執筆時点では、100を超える標準トラックMIBモジュールがあり、定義されたオブジェクトの合計が10,000を超えています。さらに、さまざまなベンダー、研究グループ、コンソーシアムなどによって一方的に定義されたエンタープライズ固有の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プロトコル操作と互換性があり、それによって伝えることができます。ただし、注目すべき例外が1つあります。SMIV2形式で定義されたMIBモジュールで定義できるCounter64データ型ですが、SNMPV1プロトコルエンジンでは伝達できません。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].
プロトコル操作の仕様は、STD 62、RFC 3416、「Simple Network Management Protocol（SNMP）のプロトコル操作のバージョン2」[21]にあります。
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、「Simple Network Management Protocol（SNMP）アプリケーション」[25]は、SNMPV3エンジンとその手順の要素に関連付けられる5つの初期タイプのアプリケーションについて説明しています。
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、「Simple Network Management Protocol（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モジュールで定義されています。これらのモジュールは、SNMPデータ定義言語で記述されており、OSIの抽象的構文表記1（ASN.1）[29]言語の適応されたサブセットから進化しました。STD 58、RFCS 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マクロ、モジュールアイデンティティは、情報モジュールのセマンティクスを簡潔に伝えるために使用されます。
(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マクロ、オブジェクトタイプは、管理されたオブジェクトの構文とセマンティクスを簡潔に伝達するために使用されます。
(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マクロ、通知タイプは、通知の構文とセマンティクスを簡潔に伝えるために使用されます。
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.
前述のように、「SMIV2」という用語は、少なくとも2つの異なる意味を持つことを意図しているため、「SMIV2」という用語はやや曖昧です。この用語は、RFCS 2578-2580で集合的に定義されているSTD 58のデータ定義言語全体を参照するために使用される場合がありますが、他の場合はRFC 2578で定義されたデータ定義言語の部分のみを参照するために使用されます。残念ながら、実際には重大な問題になることはめったにありません。
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:
STD 58、RFC 2578データ定義言語の基本データ型を指定します。これには、integer32、列挙された整数、unumerated32、ゲージ32、カウンター32、カウンター64、タイムティック、整数、オクテットストリング、オブジェクト識別子、ipadress、opaque、およびbitsが含まれます。また、いくつかのオブジェクト識別子に値を割り当てます。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.
* MIBモジュールに指定するモジュール同一性Aの説明と連絡先履歴などの管理情報。
* OBJECT-IDENTITY and OID value assignments to specify an OID value.
* OID値を指定するためのオブジェクトアイデンティティとOID値の割り当て。
* OBJECT-TYPE to specify the data type, status, and the semantics of managed objects.
* 管理されたオブジェクトのデータ型、ステータス、およびセマンティクスを指定するオブジェクトタイプ。
* SEQUENCE type assignment to list the columnar objects in a table.
* シーケンスタイプの割り当てテーブル内の列オブジェクトをリストします。
* NOTIFICATION-TYPE construct to specify an event notification.
* イベント通知を指定する通知タイプの構成。
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 [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モジュールを設計するときは、類似の動作を持つオブジェクトのセットのセマンティクスを短い方法で指定することがしばしば役立ちます。これは、SMIで指定されたベースデータ型を使用して新しいデータ型を定義することによって行われます。各新しいタイプの名前は異なり、より制限的なセマンティクスを備えたベースタイプを指定します。これらの新たに定義されたタイプは、テキストの規則と呼ばれ、MIBモジュールを読む人間の利便性に使用され、潜在的に「インテリジェント」管理アプリケーションによって使用されます。STD 58、RFC 2579、SMIV2 [18]のテキストコンベンションの目的は、このような新しいタイプを定義するために使用されるデータ定義言語の構成、テキストの協定を定義し、利用可能なテキストの初期のセットを指定するために定義することです。すべての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 [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) コンプライアンスステートメントは、オブジェクトおよびイベント通知の定義に関するエージェントの要件を説明する際に使用されます。モジュールコンプライアンス構造は、そのような要件を簡潔に伝えるために使用されます。
(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) オブジェクトおよびイベント通知の定義に関してエージェントの機能を記述するときに、機能ステートメントが使用されます。エージェントキャピリティコンストラクトは、そのような能力を簡潔に伝えるために使用されます。
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.
最後に、関連するオブジェクトのコレクションと関連するイベント通知のコレクションをグループ化して、適合単位を形成します。オブジェクトグループコンストラクトは、オブジェクトグループのセマンティクスを簡潔に伝達するために使用されます。通知グループ構成は、イベント通知のイベント通知とイベント通知グループのセマンティクスを簡潔に伝えるために使用されます。
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の送信と受信に関するプロトコルの操作を定義するために、STD 62、RFC 3416、「シンプルネットワーク管理プロトコル（SNMP）のプロトコル操作のバージョン2」[21]の目的です。
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 map onto an initial set of transport domains. Other mappings may be defined in the future.
SNMPメッセージは、さまざまなプロトコルスイートで使用できます。これは、STD 62、RFC 3417、「Simple Network Management Protocol（SNMP）のトランスポートマッピング」[22]の目的であり、SNMPメッセージが最初のトランスポートドメインにどのようにマッピングされるかを定義します。その他のマッピングは、将来定義される場合があります。
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.
これは、STD 62、RFC 3418、「Simple Network Management Protocol（SNMP）の管理情報ベース（MIB）」[30]の目的であり、SNMPエンティティの一部の動作を記述する管理オブジェクトを定義します。
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:
これは、STD 62、RFC 3411の目的であり、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」[23]であり、管理フレームワークを指定するアーキテクチャを定義します。一般的な建築の問題に対処しながら、セキュリティと管理に関連する側面に焦点を当てています。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メッセージ処理モデルにディスパッチし、PDUをSNMPアプリケーションにディスパッチする手順を定義します。このドキュメントは、1つのメッセージ処理モデル、つまり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の同時サポートを提供する多言語システムで、複数をサポートする場合があります。たとえば、SNMPV1、SNMPV2C、およびSNMPV3の同時サポートを提供するこのようなTri-Lingualシステムは、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.
STD 62、RFC 3413、「Simple Network Management Protocol（SNMP）アプリケーション」[25]の目的であり、SNMPエンジンに関連付けられる5種類のアプリケーションを記述します。それらは、コマンドジェネレーター、コマンドレスポンダー、通知オリジネーター、通知受信者、およびプロキシフォワーダーです。
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.
STD 62、RFC 3414、「シンプルネットワーク管理プロトコル（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」[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は、データの整合性を提供するためにダイジェスト計算のためにキー付きハッシュアルゴリズム[33]としてMD5 [31]と安全なハッシュアルゴリズム[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セキュリティモデルは、公開キーの暗号化を使用している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.
ユーザーベースのセキュリティモデル（USM）内でAESを使用する方法を指定する作業が進行中です。これは別のドキュメントになります。
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.
単一のエンジン実装で複数の異なる異なるアクセス制御モデルを同時にアクティブにして存在させることはアーキテクチャリーで可能ですが、これは実際には * _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]
* SNMPV1メッセージ処理モデルとコミュニティベースのセキュリティモデルは、SNMPV1とSNMPV2Cをビューベースのアクセス制御モデル（VACM）に適応させるメカニズムを提供します[27]
Readers should consult the latest version of the "Internet Official Protocol Standards" list [20] to determine the standardization status of any document.
読者は、「インターネット公式プロトコル標準」リスト[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.
STD 16、RFCS 1155および1212で説明されているSMIV1は、1990年に完全な標準ステータスに昇格し、SMIV2が完全な標準に達した後も標準のままでした（インターネット標準プロセスの詳細については、RFC 2026 [35]を参照）。多くの場合、標準は、その交換が完全な基準に達すると「歴史的」と宣言されます。たとえば、MIB-1 [8]は、MIB-2 [6]が完全な標準に達したときに「歴史的」と宣言されました。同様に、SMIV2が完全な標準に達したとき、その時点でSMIV1を廃止して「歴史的」と宣言することは合理的であったかもしれませんが、STD 16、RFCS 1155および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.
実用的なレベルでは、1993年頃以来、データ定義言語のユーザーがすべての新しい作業にSMIV2を使用することは賢明でした。これは、市場の現実がSMIV1形式とSMIV2形式の両方でデータ定義のサポートを必要とすることがあるためです。SMIV2定義をSMIV1定義に翻訳するための低コストで広く利用可能なツールが広く利用できますが、SMIV1定義をSMIV2定義に自動的に変換する自動ツールを構築することは非現実的です。その結果、主にSMIV2で動作する場合、SMIV1形式とSMIV2形式の両方でデータ定義を提供するコストは些細なことです。対照的に、主にSMIV1形式で動作する場合、SMIV1とSMIV2の両方でデータ定義を提供することは非常に高価です。SMIV1形式でデータ定義を提供するための今日の市場要件は、1993年のデータ定義と比較して大幅に減少し、SMIV1は「歴史的」と宣言されていないにもかかわらず、強く好ましい形式であり続けています。実際、IETFは現在、SMIV2を使用して新しいMIBモジュールを記述する必要があります。
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 [16]に記載されている実験的なSNMPV2C仕様は、弱点により歴史的と宣言されました。セキュリティに関しては、インターネット標準管理フレームワークの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をサポートする多Lingual実装を展開および使用し続けることが期待されています。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.
実際、上記のように、セキュリティと管理のSNMPV3仕様の1つであるRFC 2576、バージョン1、バージョン2、およびインターネット標準管理フレームワーク[28]のバージョン3の間の共存の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およびSNMPV2Cを介して適切にアクセスを制限するために、構成が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ワーキンググループは、RFCS 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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, April 1988.
[2] Cerf、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] Rose、M。and K. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。
[4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[4] Rose、M。and K. McCloghrie、「Scise MIB Definitions」、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] Case、J.、Fedor、M.、Schoffstall、M。and Davin、J。、「Simple Network Management Protocol」、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. Rose、「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] Rose、M。、「SNMPで使用するトラップを定義するための慣習」、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. Rose、「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] Case、J.、McCloghrie、K.、Rose、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2のテキストコンベンション」、RFC 1903、1996年1月。
[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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2の適合ステートメント」、RFC 1904、1996年1月。
[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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純ネットワーク管理プロトコル（SNMPV2）のバージョン2のプロトコル操作」、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2の輸送マッピング」、RFC 1906、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] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMPV2）のバージョン2の管理情報ベース」、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] Case、J.、McCloghrie、K.、Rose、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] Case、J.、McCloghrie、K.、Rose、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。and 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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M. and 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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。and 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.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（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.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMP）の輸送マッピング」、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] Harrington、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] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「Simple Network Management Protocol（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] Levi、D.、Meyer、P。and B. Stewart、「Simple Network Management Protocol（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.
[26] Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、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] Frye、R.、Levi、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（1987年12月）。
[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.
[30] Presuhn、R.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[31] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, April 1992.
[31] Rivest、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（postscript））
[33] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[33] Krawczyk、H.、Bellare、M。、およびR. Canetti、「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。Supersedes Fips Publication 46、（1977年1月、1988年1月の再確認）。
[35] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October, 1996.
[35] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
Jeffrey Case SNMP Research, Inc. 3001 Kimberlin Heights Road Knoxville, TN 37920-9716 USA
Jeffrey Case SNMP Research、Inc。3001 Kimberlin Heights Road Knoxville、TN 37920-9716 USA
Phone: +1 865 573 1434
EMail: case@snmp.com
Russ Mundy Network Associates Laboratories 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA
Russ Mundy Network Associates Laboratories 15204 Omega Drive、Suite 300 Rockville、MD 20850-4601 USA
Phone: +1 301 947 7107
EMail: mundy@tislabs.com
David Partain Ericsson P.O. Box 1248 SE-581 12 Linkoping Sweden
David Partain Ericsson P.O.Box 1248 SE-581 12リンクススウェーデン
Phone: +46 13 28 41 44
EMail: David.Partain@ericsson.com
Bob Stewart Retired
ボブ・スチュワートは引退した
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。