Network Working Group R. Frye
Request for Comments: 3584 Vibrant Solutions
BCP: 74 D. Levi
Obsoletes: 2576 Nortel Networks
Category: Best Current Practice S. Routhier
Wind River Systems, Inc.
B. Wijnen
Lucent Technologies
August 2003
Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework
Status of this Memo
このメモの位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, (SNMPv3), version 2 of the Internet-standard Network Management Framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1). This document also describes how to convert MIB modules from SMIv1 format to SMIv2 format. This document obsoletes RFC 2576.
この文書の目的は、インターネット標準ネットワーク管理フレームワーク（SNMPv3の）、インターネット標準ネットワーク管理フレームワーク（SNMPv2の）、元インターネット標準ネットワーク管理フレームワーク（SNMPv1のバージョン2のバージョン3との間の共存を説明することです）。この資料はまたSMIv2の形式にでSMIv1形式からMIBモジュールを変換する方法について説明します。この文書はRFC 2576を廃止します。
Table Of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. SNMPv1 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. SNMPv2 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. SNMPv3 . . . . . . . . . . . . . . . . . . . . . . . . 5
2. SMI and Management Information Mappings. . . . . . . . . . . 5
2.1. MIB Modules. . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Object Definitions . . . . . . . . . . . . . . 6
2.1.2. Trap and Notification Definitions . . . . . . 8
2.2. Compliance Statements. . . . . . . . . . . . . . . . . 9
2.3. Capabilities Statements. . . . . . . . . . . . . . . . 9
3. Translating Notification Parameters. . . . . . . . . . . . . 10
3.1. Translating SNMPv1 Notification Parameters to
SNMPv2 Notification Parameters . . . . . . . . . . . . 11
3.2. Translating SNMPv2 Notification Parameters to
SNMPv1 Notification Parameters . . . . . . . . . . . . 12
4. Approaches to Coexistence in a Multi-lingual Network . . . . 14
4.1. SNMPv1 and SNMPv2 Access to MIB Data . . . . . . . . . 14
4.2. Multi-lingual implementations. . . . . . . . . . . . . 15
4.2.1. Command Generator. . . . . . . . . . . . . . . 15
4.2.2. Command Responder. . . . . . . . . . . . . . . 16
4.2.2.1. Handling Counter64 . . . . . . . . . 16
4.2.2.2. Mapping SNMPv2 Exceptions. . . . . . 17
4.2.2.2.1. Mapping noSuchObject
and noSuchInstance. . . . 18
4.2.2.2.2. Mapping endOfMibView. . . 18
4.2.2.3. Processing An SNMPv1 GetReques . . . 18
4.2.2.4. Processing An SNMPv1 GetNextRequest. 19
4.2.2.5. Processing An SNMPv1 SetRequest. . . 20
4.2.3. Notification Originator. . . . . . . . . . . . 21
4.2.4. Notification Receiver. . . . . . . . . . . . . 21
4.3. Proxy Implementations. . . . . . . . . . . . . . . . . 22
4.3.1. Upstream Version Greater Than Downstream
Version. . . . . . . . . . . . . . . . . . . . 22
4.3.2. Upstream Version Less Than Downstream Version. 23
4.4. Error Status Mappings. . . . . . . . . . . . . . . . . 25
5. Message Processing Models and Security Models. . . . . . . . 26
5.1. Mappings . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. The SNMPv1 MP Model and SNMPv1 Community-based
Security Model . . . . . . . . . . . . . . . . . . . . 26
5.2.1. Processing An Incoming Request . . . . . . . . 27
5.2.2. Generating An Outgoing Response. . . . . . . . 29
5.2.3. Generating An Outgoing Notification. . . . . . 29
5.2.4. Proxy Forwarding Of Requests . . . . . . . . . 30
5.3. The SNMP Community MIB Module. . . . . . . . . . . . . 30
6. Intellectual Property Statement. . . . . . . . . . . . . . . 42
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations. . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1. Normative References . . . . . . . . . . . . . . . . . 44
9.2. Informative References . . . . . . . . . . . . . . . . 46
Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 47
A.1. Changes From RFC 2576 . . . . . . . . . . . . . . . . . 47
A.2. Changes Between RFC 1908 and RFC 2576 . . . . . . . . . 49
Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 51
The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework, termed the SNMP version 3 framework (SNMPv3), version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2), and the original Internet-standard Network Management Framework (SNMPv1).
このドキュメントの目的は、インターネット標準ネットワーク管理フレームワークのバージョン3の間の共存を記述することで、SNMPバージョン3のフレームワーク（SNMPv3の）と呼ばれる、インターネット標準ネットワーク管理フレームワークのバージョン2は、SNMPバージョン2フレームワーク（SNMPv2のと呼ばれます）、およびオリジナルのインターネット標準ネットワーク管理フレームワーク（SNMPv1の）。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
There are four general aspects of coexistence described in this document. Each of these is described in a separate section:
この文書で説明共存の4つの一般的な側面があります。これらの各々は、別々のセクションに記載されています。
- Conversion of MIB documents between SMIv1 and SMIv2 formats is documented in section 2.
- でSMIv1とSMIv2のフォーマット間のMIBドキュメントの変換は、セクション2に記載されています。
- Mapping of notification parameters is documented in section 3.
- 通知パラメータのマッピングは、セクション3に記載されています。
- Approaches to coexistence between entities which support the various versions of SNMP in a multi-lingual network is documented in section 4. This section addresses the processing of protocol operations in multi-lingual implementations, as well as behaviour of proxy implementations.
- このセクションでは、多言語の実装においてプロトコル操作の処理、ならびにプロキシ実装の挙動に対処するセクション4に記載されている多言語ネットワークにおけるSNMPの様々なバージョンをサポートするエンティティの共存へのアプローチ。
- The SNMPv1 Message Processing Model and Community-Based Security Model, which provides mechanisms for adapting SNMPv1 into the View-Based Access Control Model (VACM) [20], is documented in section 5 (this section also addresses the SNMPv2c Message Processing Model and Community-Based Security Model).
- SNMPv1のメッセージ処理モデルとビューベースアクセス制御モデル（VACM）[20]、セクション5に記載されている（このセクションはまたSNMPv2cのメッセージ処理モデルのアドレスにSNMPv1のを適応させるためのメカニズムを提供するコミュニティベースのセキュリティモデル、およびコミュニティベースセキュリティモデル）。
SNMPv1 is defined by these documents:
SNMPv1のは、これらの文書で定義されています。
- STD 15, RFC 1157 [RFC1157] which defines the Simple Network Management Protocol (SNMPv1), the protocol used for network access to managed objects.
- STD 15、簡易ネットワーク管理プロトコル（SNMPv1の）、管理オブジェクトへのネットワークアクセスのために使用されるプロトコルを定義するRFC 1157 [RFC1157]。
- STD 16, RFC 1155 [RFC1155] which defines the Structure of Management Information (SMIv1), the mechanisms used for describing and naming objects for the purpose of management.
- STD 16、管理情報（でSMIv1）、管理の目的のためにオブジェクトを記述し、命名のために使用される機構の構造を定義するRFC 1155 [RFC1155]。
- STD 16, RFC 1212 [RFC1212] which defines a more concise description mechanism, which is wholly consistent with the SMIv1.
- でSMIv1と完全に一致してより簡潔な記述メカニズムを定義STD 16、RFC 1212 [RFC1212]。
- RFC 1215 [RFC1215] which defines a convention for defining Traps for use with the SMIv1.
- RFC 1215でSMIv1で使用するためのトラップを定義するための規則を定義[RFC1215]。
Note that throughout this document, the term 'SMIv1' is used. This term generally refers to the information presented in RFC 1155, RFC 1212, and RFC 1215.
この文書を通して、用語「でSMIv1」が使用されていることに注意してください。この用語は、一般に、RFC 1155に提示された情報、RFC 1212及びRFC 1215を指します。
SNMPv2 is defined by these documents:
SNMPv2のは、これらの文書で定義されています。
- STD 58, RFC 2578 which defines Version 2 of the Structure of Management Information (SMIv2) [RFC2578].
- 管理情報（SMIv2の）の構造のバージョン2 [RFC2578]を定義STD 58、RFC 2578。
- STD 58, RFC 2579 which defines common MIB "Textual Conventions" [RFC2579].
- STD 58、共通MIB "テキストの表記法" を定義するRFC 2579 [RFC2579]。
- STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580].
- エージェントとマネージャ機能[RFC2580]を定義するための適合性宣言と要件を定義STD 58、RFC 2580。
- STD 62, RFC 3416 which defines the Protocol Operations used in processing [RFC3416].
- [RFC3416]を処理する際に使用されるプロトコル操作を定義STD 62、RFC 3416。
- STD 62, RFC 3417 which defines the Transport Mappings used "on the wire" [RFC3417].
- トランスポートマッピングが "ワイヤー上" を使用定義STD 62、RFC 3417 [RFC3417]。
- STD 62, RFC 3418 which defines the basic Management Information Base for monitoring and controlling some basic common functions of SNMP entities [RFC3418].
- SNMPエンティティのいくつかの基本的な共通機能を監視及び制御するための基本的な管理情報ベースを規定STD 62、RFC 3418 [RFC3418]。
Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580).
この文書を通して使用されるSMIv2のは、上記の最初の3つの文書（のRFC 2578、2579、および2580）を指すことに留意されたいです。
The following document augments the definition of SNMPv2:
以下のドキュメントは、SNMPv2の定義を強化します：
- RFC 1901 [RFC1901] is an Experimental definition for using SNMPv2 PDUs within a community-based message wrapper. This is referred to throughout this document as SNMPv2c.
- RFC 1901 [RFC1901]は、コミュニティベースのメッセージラッパー内のSNMPv2 PDUを使用するための実験的な定義です。これはSNMPv2cのように、この文書を通じて言及されています。
SNMPv3 is defined by these documents:
SNMPv3のは、これらの文書で定義されています。
- STD 62, RFC 3411 which defines an Architecture for Describing SNMP Management Frameworks [RFC3411].
- SNMP管理フレームワーク[RFC3411]を記述するためのアーキテクチャを定義STD 62、RFC 3411。
- STD 62, RFC 3412 which defines Message Processing and Dispatching [RFC3412].
- メッセージ処理とディスパッチ[RFC3412]を定義STD 62、RFC 3412。
- STD 62, RFC 3413 which defines various SNMP Applications [RFC3413].
- 様々なSNMPアプリケーション[RFC3413]を定義STD 62、RFC 3413。
- STD 62, RFC 3414 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [RFC3414].
- ユーザベースのセキュリティモデル（USM）を定義STD 62、RFC 3414、認証され、プライベート（暗号化）SNMPメッセージ[RFC3414]の両方を提供します。
- STD 62, RFC 3415 which defines the View-based Access Control Model (VACM), providing the ability to limit access to different MIB objects on a per-user basis [RFC3415].
- ユーザーごと[RFC3415]に異なるMIBオブジェクトへのアクセスを制限する能力を提供する、ビューベースアクセス制御モデル（VACM）を定義STD 62、RFC 3415。
SNMPv3 also uses the SNMPv2 definitions of RFCs 3416 through 3418 and the SMIv2 definitions of 2578 through 2580 described above. Note that text throughout this document that refers to SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3.
SNMPv3は、上述2580を介して3418を介したRFC 3416のSNMPv2の定義と2578のSMIv2の定義を使用します。 SNMPv2cのおよびSNMPv3の両方に適用されるのSNMPv2 PDUタイプとプロトコル操作を指し、この文書全体にわたってそのテキストに注意してください。
The SMIv2 approach towards describing collections of managed objects is nearly a proper superset of the approach defined in the SMIv1. For example, both approaches use an adapted subset of ASN.1 [ASN1] as the basis for a formal descriptive notation. Indeed, one might note that the SMIv2 approach largely codifies the existing practice for defining MIB modules, based on extensive experience with the SMIv1.
管理対象オブジェクトのコレクションを記述するに向けたSMIv2のアプローチはほとんどSMIv1の定義されたアプローチの適切なスーパーセットです。例えば、両方のアプローチは、正式な記述表記するための基礎としてASN.1 [ASN1]の適合サブセットを使用します。確かに、人はSMIv2のアプローチが大きくでSMIv1と豊富な経験に基づいて、MIBモジュールを定義するための既存の慣行を成文化することを注意してください可能性があります。
The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.
MIBモジュール、コンプライアンス・ステートメント、および機能文：次のセクションでは、三つの領域を考えます。
MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for SMIv1 MIB modules to conform to the SMIv2, the following changes SHALL be made:
でSMIv1を使用して定義されたMIBモジュールは、SNMPv2のPDUを使用するプロトコルのバージョンで使用し続けることができます。しかし、SMIv2のに適合するためでSMIv1 MIBモジュールのために、以下の変更がなされなければなりません。
In general, conversion of a MIB module does not require the deprecation of the objects contained therein. If the definition of an object is truly inadequate for its intended purpose, the object SHALL be deprecated or obsoleted, otherwise deprecation is not required.
一般に、MIBモジュールの変換は、そこに含まれるオブジェクトの廃止を要求しません。オブジェクトの定義は、その意図された目的のために、本当に不十分である場合、オブジェクトは非推奨または廃止されるものと、そうでない場合は廃止が必要とされていません。
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of RFC1155-SMI and RFC-1212.
（1）Importsステートメント代わりRFC1155-SMIおよびRFC-1212の、のSNMPv2-SMIを参照しなければなりません。
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement.
（2）MODULE-IDENTITYマクロは、任意のインポートステートメントの直後に呼び出されなければなりません。
(3) For any object with a SYNTAX clause value of Counter, the object MUST have the value of its SYNTAX clause changed to Counter32.
（3）カウンタのSYNTAX節価値を有する任意のオブジェクトの場合、オブジェクトは、その構文節の値はCounter32のに変更されていなければなりません。
(4) For any object with a SYNTAX clause value of Gauge, the object MUST have the value of its SYNTAX clause changed to Gauge32, or Unsigned32 where appropriate.
（4）ゲージのSYNTAX節価値を有する任意のオブジェクトの場合、オブジェクトはGauge32に変更構文節の値を持つ必要があり、またはUnsigned32の適切な場合。
(5) For all objects, the ACCESS clause MUST be replaced by a MAX-ACCESS clause. The value of the MAX-ACCESS clause SHALL be the same as that of the ACCESS clause unless some other value makes "protocol sense" as the maximal level of access for the object. In particular, object types for which instances can be explicitly created by a protocol set operation, SHALL have a MAX-ACCESS clause of "read-create". If the value of the ACCESS clause is "write-only", then the value of the MAX-ACCESS clause MUST be "read-write", and the DESCRIPTION clause SHALL note that reading this object will result in implementation-specific results. Note that in SMIv1, the ACCESS clause specifies the minimal required access, while in SMIv2, the MAX-ACCESS clause specifies the maximum allowed access. This should be considered when converting an ACCESS clause to a MAX-ACCESS clause.
（5）すべてのオブジェクトについて、ACCESS句は、MAX-ACCESS句で交換しなければなりません。 MAX-ACCESS節の値は、いくつかの他の値は、オブジェクトに対するアクセスの最大レベルとして「プロトコル感覚」を作る場合を除きACCESS節と同じでなければなりません。具体的には、インスタンスが明示的プロトコル集合操作で作成することができるため、オブジェクトタイプは、「読作成」のMAX-ACCESS節を持たなければなりません。 ACCESS節の値が「書き込み専用」である場合、MAX-ACCESS節の値は、「読み書き可能」でなければなりません、と記述節は、このオブジェクトを読み出すことは実装固有の結果をもたらすであろうことに注意SHALL。 SMIv2の中で、MAX-ACCESS句が最大許容アクセスを指定しながら、SMIv1の、アクセス節は、必要最小限のアクセス権を指定することに注意してください。 MAX-ACCESS節へのアクセス節を変換するときに考慮されるべきです。
(6) For all objects, if the value of the STATUS clause is "mandatory" or "optional", the value MUST be replaced with "current", "deprecated", or "obsolete" depending on the current usage of such objects.
（6）すべてのオブジェクトについて、そのようなオブジェクトの現在の使用状況に応じて、STATUS節の値が「必須」または「任意」である場合、値が「現在」、「非推奨」に置き換える必要があり、または「廃止」。
(7) For any object not containing a DESCRIPTION clause, the object MUST have a DESCRIPTION clause defined.
（7）説明句を含まない任意のオブジェクトについて、オブジェクトが定義された記述句を持たなければなりません。
(8) For any object corresponding to a conceptual row which does not have an INDEX clause, the object MUST have either an INDEX clause or an AUGMENTS clause defined.
（8）INDEX句を持たない概念的な行に対応する任意のオブジェクトについて、オブジェクトは、INDEX句または定義AUGMENTS句のいずれかがなければなりません。
(9) If any INDEX clause contains a reference to an object with a syntax of NetworkAddress, then a new object MUST be created and placed in this INDEX clause immediately preceding the object whose syntax is NetworkAddress. This new object MUST have a syntax of INTEGER, it MUST be not-accessible, and its value MUST always be 1. The effect of this, and the preceding bullet, is to allow one to convert a MIB module in SMIv1 format to one in SMIv2 format, and then use it with the SNMPv1 protocol with no impact to existing SNMPv1 agents and managers.
任意INDEX句はのNetworkAddressの構文でオブジェクトへの参照が含まれている場合（9）、その後、新しいオブジェクトが作成され、直ちに構文のNetworkAddressであるオブジェクトの前に、このINDEX句に置かなければなりません。この新しいオブジェクトはINTEGERの構文で指定する必要があり、それがアクセス可能であってはならないこと、およびその値は常に1本の影響、および前の弾丸でなければならない、1が1つにでSMIv1形式のMIBモジュールを変換できるようにすることですSMIv2の形式は、その後既存のSNMPv1エージェントとマネージャに影響を与えずにSNMPv1プロトコルと共に使用します。
(10) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress).
（10）のNetworkAddressの構文を使用して任意のオブジェクトの場合、構文はIPアドレスに変更しなければなりません。新しいMIBドキュメント内のNetworkAddressの使用が強く推奨されていることに注意してください（実際には、新しいMIBドキュメントはのNetworkAddressを定義していないのSMIv2を使用して記述する必要があります）。
(11) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER value which is expressed as a collection of sub-identifiers, the value MUST be changed to reference a single ASN.1 identifier. This may require defining a series of new administrative assignments (OBJECT IDENTIFIERS) in order to define the single ASN.1 identifier.
（11）副識別子の集合として表現されるオブジェクト識別子値とDEFVAL句を含む任意の目的のために、値は、単一のASN.1識別子を参照するように変更しなければなりません。これは、単一のASN.1識別子を定義するために、新しい管理の割り当て（OBJECT識別子）のシリーズを定義する必要があります。
(12) One or more OBJECT-GROUPS MUST be defined, and related objects MUST be collected into appropriate groups. Note that SMIv2 requires all OBJECT-TYPEs to be a member of at least one OBJECT-GROUP.
（12）は、1つ以上のオブジェクト・グループを定義する必要があり、および関連オブジェクトが適切なグループに集めなければなりません。 SMIv2のは、少なくとも一つのオブジェクト・グループのメンバーであるすべてのOBJECT-タイプを必要とすることに注意してください。
(13) For any non-columnar object that is instanced as if it were immediately subordinate to a conceptual row, the value of the STATUS clause of that object MUST be changed to "obsolete".
（13）これは概念的な列に直接従属であるかのようにインスタンス化される任意の非柱状オブジェクトについて、そのオブジェクトのSTATUS節の値が「廃止」に変更されなければなりません。
(14) For any conceptual row object that is not immediately subordinate to a conceptual table, the value of the STATUS clause of that object (and all subordinate objects) MUST be changed to "obsolete".
（14）直ちに概念テーブルに従属されていない任意の概念的な行オブジェクトについて、そのオブジェクト（およびすべての下位オブジェクト）のSTATUS節の値が「廃止」に変更されなければなりません。
Other changes are desirable, but not necessary:
その他の変更が望ましいが、必須ではありません。
(1) Creation and deletion of conceptual rows is inconsistent using the SMIv1. The SMIv2 corrects this. As such, if the MIB module undergoes review early in its lifetime, and it contains conceptual tables which allow creation and deletion of conceptual rows, then the objects relating to those tables MAY be deprecated and replaced with objects defined using the new approach. The approach based on SMIv2 can be found in section 7 of RFC 2578 [RFC2578], and the RowStatus and StorageType TEXTUAL-CONVENTIONs are described in section 2 of RFC 2579 [RFC2579].
（1）の概念的な行の作成および削除はでSMIv1を使用して矛盾しています。 SMIv2のは、これを修正します。このようにして、MIBモジュールは、早期にその生涯で審査を受け、それが作成し、概念的な行の削除を許可概念的なテーブルが含まれている場合、それらのテーブルに関連するオブジェクトは廃止され、新しいアプローチを使用して定義されたオブジェクトに置き換えてもよいです。 SMIv2のに基づいたアプローチは、RFC 2578 [RFC2578]のセクション7に見出すことができ、RowStatusのとStorageTypeテキストの表記法は、RFC 2579 [RFC2579]のセクション2に記載されています。
(2) For any object with an integer-valued SYNTAX clause, in which the corresponding INTEGER does not have a range restriction (i.e., the INTEGER has neither a defined set of named-number enumerations nor an assignment of lower- and upper-bounds on its value), the object SHOULD have the value of its SYNTAX clause changed to Integer32, or have an appropriate range specified.
（2）対応する整数は、範囲制限（すなわち有していない整数値SYNTAX句、を有する任意のオブジェクトの場合、整数名前番号列挙の定義されたセットも小文字と上部境界の割り当てもありません）その値で、オブジェクトは、その構文節の値がInteger32のに変更された、または指定された適切な範囲を有するべきです。
(3) For any object with a string-valued SYNTAX clause, in which the corresponding OCTET STRING does not have a size restriction (i.e., the OCTET STRING has no assignment of lower- and upper-bounds on its length), the bounds for the size of the object SHOULD be defined.
（3）文字列値SYNTAX節を持つ任意のオブジェクトについて、対応するオクテットSTRING（すなわち、オクテット文字列は、その長さに小文字と上部境界のない割り当てを有していない）サイズ制限を持たないで、の境界オブジェクトのサイズが定義されるべきです。
(4) All textual conventions informally defined in the MIB module SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a change would not necessitate deprecating objects previously defined using an informal textual convention.
（4）非公式MIBモジュールで定義されたすべてのテキストの表記法は、テキストの表記マクロを使用して再定義されるべきです。このような変化は、以前に非公式のテキストの表記法を使用して定義されたオブジェクトを非推奨必要ないでしょう。
(5) For any object which represents a measurement in some kind of units, a UNITS clause SHOULD be added to the definition of that object.
（5）単位のいくつかの種類に測定値を表す任意のオブジェクトについて、UNITS句は、そのオブジェクトの定義に追加されるべきです。
(6) For any conceptual row which is an extension of another conceptual row, i.e., for which subordinate columnar objects both exist and are identified via the same semantics as the other conceptual row, an AUGMENTS clause SHOULD be used in place of the INDEX clause for the object corresponding to the conceptual row which is an extension.
（6）下位の円柱状のオブジェクトが存在し、他の概念的な列と同じセマンティクスを介して同定される両方、AUGMENTS句はINDEX句の代わりに使用する必要のある別の概念的な行の拡張である任意の概念的な列、すなわち、について拡張である概念的な行に対応するオブジェクトのため。
If a MIB module is changed to conform to the SMIv2, then each occurrence of the TRAP-TYPE macro MUST be changed to a corresponding invocation of the NOTIFICATION-TYPE macro: (1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and MUST reference SNMPv2-SMI instead.
MIBモジュールがSMIv2のに適合するように変更された場合、TRAP-TYPEマクロの各発生はNOTIFICATION-TYPEマクロの対応する呼び出しに変更しなければならない：（1）Importsステートメントは、RFC1215 [RFC1215]を参照してはなりません、代わりのSNMPv2-SMIを参照しなければなりません。
(2) The ENTERPRISE clause MUST be removed.
（2）企業の句は、除去しなければなりません。
(3) The VARIABLES clause MUST be renamed to the OBJECTS clause.
（3）変数句は、OBJECTS節に改名されなければなりません。
(4) A STATUS clause MUST be added, with an appropriate value. Normally the value should be 'current', although 'deprecated' or 'obsolete' may be used as needed.
（4）STATUS句は適切な値で、添加されなければなりません。正常値が必要に応じて使用することができる「非推奨」または「廃止」、「カレント」であるべきです。
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an OBJECT IDENTIFIER, not an INTEGER, and MUST be changed accordingly. Specifically, if the value of the ENTERPRISE clause is not 'snmp' then the value of the invocation SHALL be the value of the ENTERPRISE clause extended with two sub-identifiers, the first of which has the value 0, and the second has the value of the invocation of the TRAP-TYPE. If the value of the ENTERPRISE clause is 'snmp', then the value of the invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the same manner as described in section 3.1 in this document.
（5）NOTIFICATION-TYPEマクロの呼び出しの値は、オブジェクト識別子ではない整数であり、それに応じて変更しなければなりません。 ENTERPRISE句の値が「SNMP」でない場合、具体的には、呼び出しの値が値0を有する最初する2つのサブ識別子と拡張エンタープライズ節の値でなければならない、そして第二の値を有しますTRAP-TYPEの呼び出しの。 ENTERPRISE句の値が「SNMP」である場合、NOTIFICATION-TYPEマクロの呼び出しの値は、この文書のセクション3.1に記載したのと同じ方法でマップされなければなりません。
(6) A DESCRIPTION clause MUST be added, if not already present.
既に存在しない場合には（6）DESCRIPTION句は、添加されなければなりません。
(7) One or more NOTIFICATION-GROUPs MUST be defined, and related notifications MUST be collected into those groups. Note that SMIv2 requires that all NOTIFICATION-TYPEs be a member of at least one NOTIFICATION-GROUP.
（7）1種以上のNOTIFICATION-グループが定義されなければならない、および関連する通知がこれらのグループに集めなければなりません。 SMIv2のすべてのNOTIFICATION-型は少なくとも一つのNOTIFICATION-グループのメンバーであることを必要とすることに留意されたいです。
For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review.
これらの情報の情報モジュール内に含まれなければならない「基準トラック」、MODULE-COMPLIANCEマクロと関連するオブジェクト・グループ及び/又はNOTIFICATION-GROUPマクロの対応する呼び出しているモジュール（または、コンパニオン情報モジュールで）、そして任意用遵守に関連する情報モジュールで解説テキストを削除する必要があります。情報モジュールがレビューを受ける場合、通常この編集が発生する可能性があります。
Note that a MODULE-COMPLIANCE statement is not required for a MIB document that is not on the standards track (for example, an enterprise MIB), though it may be useful in some circumstances to define a MODULE-COMPLIANCE statement for such a MIB document.
そのようなMIB文書のMODULE-COMPLIANCE文を定義するために、いくつかの状況において有用であり得るけれどもMODULE-COMPLIANCEステートメントは、（例えば、エンタープライズMIB）規格トラック上にないMIBドキュメントのために必要とされないことに注意してください。
RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules.
RFC 1303 [RFC1303]は一つ以上のMIBモジュールに関してエージェントの能力を記述するためにMODULE-適合マクロを使用します。
Converting such a description for use with the SMIv2 requires these changes:
SMIv2ので使用するために、このような記述を変換すると、これらの変更を必要とします。
(1) The macro name AGENT-CAPABILITIES MUST be used instead of MODULE-CONFORMANCE.
（1）マクロ名AGENT-CAPABILITIESは、MODULE-適合代わりに使用されなければなりません。
(2) The STATUS clause MUST be added, with a value of 'current'.
（2）STATUS句は、「現在」の値で、添加されなければなりません。
(3) All occurrences of the CREATION-REQUIRES clause MUST either be omitted if appropriate, or be changed such that the semantics are consistent with RFC 2580 [RFC2580].
（3）のすべての出現節が適切であればどちらかを省略しなければならない、又は意味論は、RFC 2580 [RFC2580]と一致するように変更すること作成は、必要とします。
In order to ease coexistence, object groups defined in an SMIv1 compliant MIB module may be referenced by the INCLUDES clause of an invocation of the AGENT-CAPABILITIES macro: upon encountering a reference to an OBJECT IDENTIFIER subtree defined in an SMIv1 MIB module, all leaf objects which are subordinate to the subtree and have a STATUS clause value of mandatory are deemed to be INCLUDEd. (Note that this method is ambiguous when different revisions of an SMIv1 MIB have different sets of mandatory objects under the same subtree; in such cases, the only solution is to rewrite the MIB using the SMIv2 in order to define the object groups unambiguously.)
でSMIv1 MIBモジュールで定義されたオブジェクト識別子サブツリー、すべてのリーフへの参照に遭遇すると：共存を容易にするために、でSMIv1準拠MIBモジュールで定義されたオブジェクトグループは、AGENT-CAPABILITIESマクロの呼び出しの句を含んで参照することができますサブツリーに従属すると、必須のSTATUS節の値を持つオブジェクトが含まれると考えられます。 （でSMIv1 MIBの異なるリビジョンが同じサブツリーの下に必須オブジェクトの異なるセットを有する場合、この方法が曖昧であることに留意されたい。そのような場合、唯一の解決策は、明確にオブジェクトグループを定義するためのSMIv2を使用してMIBを書き換えることです。）
This section describes how parameters used for generating notifications are translated between the format used for SNMPv1 notification protocol operations and the format used for SNMPv2 notification protocol operations. The parameters used to generate a notification are called 'notification parameters'. The format of parameters used for SNMPv1 notification protocol operations is referred to in this document as 'SNMPv1 notification parameters'. The format of parameters used for SNMPv2 notification protocol operations is referred to in this document as 'SNMPv2 notification parameters'.
このセクションでは、通知を生成するために使用されるパラメータは、SNMPv1の通知プロトコル操作に使用されるフォーマットとSNMPv2通知プロトコル操作に使用されるフォーマットとの間で翻訳される方法を記載しています。通知を生成するために使用されるパラメータは、「通知パラメータ」と呼ばれています。 SNMPv1の通知プロトコル操作のために使用されるパラメータのフォーマットは、「SNMPv1の通知パラメータ」として本書で参照されます。 SNMPv2の通知プロトコル操作のために使用されるパラメータのフォーマットは、「SNMPv2の通知パラメータ」として本書で参照されます。
The situations where notification parameters MUST be translated are:
通知パラメータが変換されなければならない状況は以下のとおりです。
- When an entity generates a set of notification parameters in a particular format, and the configuration of the entity indicates that the notification must be sent using an SNMP message version that requires the other format for notification parameters.
- 実体が特定のフォーマットで通知パラメータのセットを生成し、エンティティの構成が通知が通知パラメータのための他の形式を必要とするSNMPメッセージバージョンを使用して送信されなければならないことを示す場合。
- When a proxy receives a notification that was sent using an SNMP message version that requires one format of notification parameters, and must forward the notification using an SNMP message version that requires the other format of notification parameters.
- プロキシが通知パラメータの形式を必要とし、通知パラメータの他の形式を必要とするSNMPメッセージバージョンを使用して通知を転送しなければならないSNMPメッセージバージョンを使用して送信された通知を受信します。
In addition, it MAY be desirable to translate notification parameters in a notification receiver application in order to present notifications to the end user in a consistent format.
また、一貫性のある形式でエンドユーザに通知を提示するために通知の受信機アプリケーションに通知パラメータを変換することが望ましい場合があります。
Note that for the purposes of this section, the set of notification parameters is independent of whether the notification is to be sent as a trap or an inform.
このセクションの目的のために、通知パラメータのセットは、通知トラップまたは通知として送信するか否かとは無関係であることに留意されたいです。
SNMPv1 notification parameters consist of:
SNMPv1の通知パラメータは、で構成されています。
- An enterprise parameter (OBJECT IDENTIFIER).
- エンタープライズパラメータ（オブジェクト識別子）。
- An agent-addr parameter (NetworkAddress).
- エージェント - addrパラメータ（のNetworkAddress）。
- A generic-trap parameter (INTEGER).
- 一般的なトラップパラメータ（INTEGER）。
- A specific-trap parameter (INTEGER).
- 特定のトラップパラメータ（INTEGER）。
- A time-stamp parameter (TimeTicks).
- タイムスタンプのパラメータ（時間刻み）。
- A list of variable-bindings (VarBindList).
- 可変バインディングのリスト（VarBindList）。
SNMPv2 notification parameters consist of:
SNMPv2の通知パラメータは、で構成されています。
- A sysUpTime parameter (TimeTicks). This appears in the first variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
- のsysUpTimeパラメータ（時間刻み）。これは、第1の可変結合のSNMPv2トラップ-PDUまたはInformRequest-PDU内に表示されます。
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in the second variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU, and is equal to the value portion of that variable-binding (not the name portion, as both the name and value are OBJECT IDENTIFIERs).
- snmpTrapOIDパラメータ（オブジェクト識別子）。これにより、第2の可変結合のSNMPv2トラップ-PDUまたはInformRequest-PDU内に表示され、（名前と値の両方がオブジェクト識別子であるとしてではない名前の部分、）その変数バインディングの値部分と同じです。
- A list of variable-bindings (VarBindList). This refers to all but the first two variable-bindings in an SNMPv2-Trap-PDU or InformRequest-PDU.
- 可変バインディングのリスト（VarBindList）。これは、すべてが、SNMPv2のトラップ-PDUまたはInformRequest-PDUの最初の2つの変数バインディングを指します。
3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification Parameters
3.1. SNMPv2の通知パラメータにSNMPv1の通知パラメータを翻訳
The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters:
次の手順では、SNMPv2の通知パラメータにSNMPv1の通知パラメータを変換する方法について説明します。
(1) The SNMPv2 sysUpTime parameter SHALL be taken directly from the SNMPv1 time-stamp parameter.
（1）のSNMPv2のsysUpTimeパラメータは、SNMPv1タイムスタンプパラメータから直接講じなければなりません。
(2) If the SNMPv1 generic-trap parameter is 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the concatenation of the SNMPv1 enterprise parameter and two additional sub-identifiers, '0', and the SNMPv1 specific-trap parameter.
SNMPv1の一般的なトラップパラメータがある場合（2）「enterpriseSpecificを（6）」、SNMPv2のsnmpTrapOIDパラメータは、SNMPv1エンタープライズパラメータの連結及び二つの追加サブ識別子、「0」、およびSNMPv1の特定のトラップパラメータでなければなりません。
(3) If the SNMPv1 generic-trap parameter is not 'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL be the corresponding trap as defined in section 2 of RFC 3418 [RFC3418]:
SNMPv1の一般的なトラップパラメータがない場合は、RFC 3418 [RFC3418]のセクション2で定義されるように（3）「enterpriseSpecificを（6）」、SNMPv2のsnmpTrapOIDパラメータは、対応するトラップをしなければなりません。
generic-trap
parameter snmpTrapOID.0
============ =============
0 1.3.6.1.6.3.1.1.5.1 (coldStart)
1 1.3.6.1.6.3.1.1.5.2 (warmStart)
2 1.3.6.1.6.3.1.1.5.3 (linkDown)
3 1.3.6.1.6.3.1.1.5.4 (linkUp)
4 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)
5 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)
(4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings. In addition, if the translation is being performed by a proxy in order to forward a received trap, three additional variable-bindings will be appended, if these three additional variable-bindings do not already exist in the SNMPv1 variable-bindings. The name portion of the first additional variable binding SHALL contain snmpTrapAddress.0, and the value SHALL contain the SNMPv1 agent-addr parameter. The name portion of the second additional variable binding SHALL contain snmpTrapCommunity.0, and the value SHALL contain the value of the community-string field from the received SNMPv1 message which contained the SNMPv1 Trap-PDU. The name portion of the third additional variable binding SHALL contain snmpTrapEnterprise.0 [RFC3418], and the value SHALL be the SNMPv1 enterprise parameter.
（4）のSNMPv2変数バインディングは、SNMPv1可変束縛されなければなりません。翻訳は、受信トラップを転送するためにプロキシによって行われている場合は、これらの三つの追加変数バインディングが既にSNMPv1の可変束縛に存在しない場合に加えて、三追加の変数バインディングは、添付されるであろう。第1の追加の変数の名前部分はsnmpTrapAddress.0を含まなければならない結合、および値は、SNMPv1エージェント-addrパラメータを含まなければなりません。 snmpTrapCommunity.0を含まなければならない結合第二の追加の変数の名前部分、および値は、SNMPv1トラップ-PDUに含まれる受信のSNMPv1メッセージからのコミュニティ文字列フィールドの値を含まなければなりません。 snmpTrapEnterprise.0 [RFC3418]を含まなければならないバインディング第3の付加変数の名前部分、および値は、SNMPv1エンタープライズパラメータでなければなりません。
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification Parameters
3.2. SNMPv1の通知パラメータにSNMPv2の通知パラメータを翻訳
The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters:
次の手順では、SNMPv1通知パラメタへのSNMPv2通知パラメータを変換する方法について説明します。
(1) The SNMPv1 enterprise parameter SHALL be determined as follows:
次のように（1）のSNMPv1エンタープライズパラメータを決定しなければなりません。
- If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be set to the value of the variable-binding in the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0 if that variable-binding exists. If it does not exist, the SNMPv1 enterprise parameter SHALL be set to the value 'snmpTraps' as defined in RFC 3418 [RFC3418].
- RFC 3418で定義されるようにSNMPv2 snmpTrapOIDパラメータは、[RFC3418]標準トラップの一つである場合、SNMPv1のエンタープライズパラメータは、可変結合のSNMPv2変数バインディング内の名前snmpTrapEnterprise.0がある場合の値に設定されますその変数バインディングが存在します。それが存在しない場合は、SNMPv1のエンタープライズパラメータは、RFC 3418 [RFC3418]で定義されるように値「snmpTraps」に設定されます。
- If the SNMPv2 snmpTrapOID parameter is not one of the standard traps as defined in RFC 3418 [RFC3418], then the SNMPv1 enterprise parameter SHALL be determined from the SNMPv2 snmpTrapOID parameter as follows:
- RFC 3418 [RFC3418]で定義されるようにSNMPv2 snmpTrapOIDパラメータは標準トラップのいずれでもない場合は、次のようにSNMPv1のエンタープライズパラメータは、SNMPv2のsnmpTrapOIDパラメータから決定しなければなりません。
- If the next-to-last sub-identifier of the snmpTrapOID value
is zero, then the SNMPv1 enterprise SHALL be the SNMPv2
snmpTrapOID value with the last 2 sub-identifiers removed,
otherwise
- If the next-to-last sub-identifier of the snmpTrapOID value is non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2 snmpTrapOID value with the last sub-identifier removed.
- snmpTrapOID値の次から最後のサブ識別子がゼロでない場合、その後のSNMPv1企業は、最後のサブ識別子を除去したSNMPv2のsnmpTrapOID値でなければなりません。
(2) The SNMPv1 agent-addr parameter SHALL be determined based on the situation in which the translation occurs.
（2）のSNMPv1エージェント-addrパラメータは、変換が発生した状況に基づいて決定しなければなりません。
- If the translation occurs within a notification originator application, and the notification is to be sent over IP, the SNMPv1 agent-addr parameter SHALL be set to the IP address of the SNMP entity in which the notification originator resides. If the notification is to be sent over some other transport, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- 翻訳が通知創始者アプリケーション内で発生し、通知はIP上で送信される場合は、SNMPv1のエージェント - addrパラメータは、通知創始者が存在するSNMPエンティティのIPアドレスを設定しなければなりません。通知は、他のいくつかのトランスポートを介して送信される場合は、SNMPv1のエージェント - addrパラメータは0.0.0.0に設定されなければなりません。
- If the translation occurs within a proxy application, the proxy must attempt to extract the original source of the notification from the variable-bindings. If the SNMPv2 variable-bindings contains a variable binding whose name is snmpTrapAddress.0, the agent-addr parameter SHALL be set to the value of that variable binding. Otherwise, the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
- 翻訳は、プロキシ・アプリケーション内で発生した場合、プロキシは、変数バインディングからの通知の元のソースを抽出しようとしなければなりません。 SNMPv2の変数バインディングは、名前snmpTrapAddress.0あるバインディング変数が含まれている場合は、エージェント-addrパラメータは、バインディングその変数の値に設定されなければなりません。それ以外の場合は、SNMPv1のエージェント - addrパラメータは0.0.0.0に設定されなければなりません。
(3) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], the SNMPv1 generic-trap parameter SHALL be set as follows:
[RFC3418] RFC 3418で定義されるようにSNMPv2 snmpTrapOIDパラメータは標準トラップのいずれかである場合、以下のように（3）、SNMPv1の一般的なトラップパラメータが設定されなければなりません。
snmpTrapOID.0 parameter generic-trap
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
それ以外の場合は、SNMPv1の一般的なトラップパラメータが6に設定されなければなりません。
(4) If the SNMPv2 snmpTrapOID parameter is one of the standard traps as defined in RFC 3418 [RFC3418], the SNMPv1 specific-trap parameter SHALL be set to zero. Otherwise, the SNMPv1 specific-trap parameter SHALL be set to the last sub-identifier of the SNMPv2 snmpTrapOID parameter.
[RFC3418] RFC 3418で定義されるようにSNMPv2 snmpTrapOIDパラメータは標準トラップのいずれかである場合（4）、SNMPv1の特定のトラップパラメータがゼロに設定されます。そうでない場合は、SNMPv1の特定のトラップパラメータは、SNMPv2 snmpTrapOIDパラメータの最後のサブ識別子に設定されなければなりません。
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the SNMPv2 sysUpTime parameter.
（5）のSNMPv1タイムスタンプパラメータは、SNMPv2のsysUpTimeパラメータから直接講じなければなりません。
(6) The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-bindings (and note that the SNMPv2 variable-bindings do not include the variable-bindings containing sysUpTime.0, snmpTrapOID.0). Note, however, that if the SNMPv2 variable-bindings contain any objects whose type is Counter64, the translation to SNMPv1 notification parameters cannot be performed. In this case, the notification cannot be encoded in an SNMPv1 packet (and so the notification cannot be sent using SNMPv1, see section 4.2.3 and section 4.3).
（6）SNMPv1の可変束縛はSNMPv2の可変束縛すること（およびSNMPv2変数バインディングがsysUpTime.0、snmpTrapOID.0を含む変数バインディングが含まれていないことに注意）SHALL。 SNMPv2の可変バインディングがSNMPv1の通知パラメータに変換を行うことができない、そのタイプCounter64の任意のオブジェクトを含む場合に、しかし、注意してください。この場合、通知は、SNMPv1のパケットに符号化することができない（したがって、通知のSNMPv1を使用して送信することができない、セクション4.2.3及びセクション4.3を参照）。
There are two basic approaches to coexistence in a multi-lingual network, multi-lingual implementations and proxy implementations. Multi-lingual implementations allow elements in a network to communicate with each other using an SNMP version which both elements support. This allows a multi-lingual implementation to communicate with any mono-lingual implementation, regardless of the SNMP version supported by the mono-lingual implementation.
マルチリンガルネットワーク、マルチリンガルの実装およびプロキシの実装に共存するには、2つの基本的なアプローチがあります。多言語の実装では、ネットワーク内の要素は、両方の要素がサポートするSNMPバージョンを使用して互いに通信することを可能にします。これは、多言語の実装は、モノ言語インプリメンテーションによってサポートされるSNMPバージョンにかかわらず、任意のモノ言語インプリメンテーションと通信することを可能にします。
Proxy implementations provide a mechanism for translating between SNMP versions using a third party network element. This allows network elements which support only a single, but different, SNMP version to communicate with each other. Proxy implementations are also useful for securing communications over an insecure link between two locally secure networks.
プロキシ実装は、サードパーティのネットワーク要素を使用して、SNMPバージョンの間で変換するための機構を提供します。これは、互いに通信するための単一の、しかし異なる、SNMPバージョンをサポートするネットワーク要素を可能にします。プロキシの実装は、2つの局所的に安全なネットワークの間のセキュアでないリンクを介して通信を保護するために有用です。
Throughout section 4., this document refers to 'SNMPv1 Access to MIB Data' and 'SNMPv2 Access to MIB Data'. These terms refer to the part of an SNMP agent which actually accesses instances of MIB objects, and which actually initiates generation of notifications. Differences between the two types of access to MIB data are:
部4を通して、本書は「MIBデータへのSNMPv1アクセス」と「MIBデータへのSNMPv2アクセス」に言及します。これらの用語は、実際にMIBオブジェクトのインスタンスにアクセスし、実際の通知の生成を開始するSNMPエージェントの一部を参照してください。 MIBデータへのアクセスの2つのタイプの違いは次のとおりです。
- Error-status values generated.
- エラー・ステータス値を生成します。
- Generation of exception codes.
- 例外コードの生成。
- Use of the Counter64 data type.
- Counter64のデータ型を使用します。
- The format of parameters provided when a notification is generated.
- 通知が生成されたときに提供されたパラメータのフォーマット。
SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error).
MIBデータへのSNMPv1アクセスは例外コードを生成することも、Counter64のデータ型を使用して、通知を生成するためのSNMPv1形式のパラメータを提供します決して、SNMPv1のエラーステータス値を生成してもよいです。注また、MIBデータへのSNMPv1アクセスは、実際に（noSuchNameエラーが常に1が読み取り専用のエラーを期待するような状況で発生するであろう）読み取り専用エラーを発生しないこと。
SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors.
MIBデータへのSNMPv2アクセスがCounter64のデータ型を使用することができ、通知を生成するためのSNMPv2形式のパラメータを提供し、例外コードを生成することができる、SNMPv2のエラー状態値を生成することができます。 MIBデータへのSNMPv2アクセスが読み取り専用、noSuchName、またはBadValueを起こすことはありませんので注意してください。
Note that a particular multi-lingual implementation may choose to implement all access to MIB data as SNMPv2 access to MIB data, and perform the translations described herein for SNMPv1-based transactions.
特定の多言語実装はMIBデータへのSNMPv2アクセスとしてMIBデータへのすべてのアクセスを実現するために選択し、SNMPv1のベースのトランザクションのために本明細書に記載の翻訳を行ってもよいことに留意されたいです。
Further, note that there is no mention of 'SNMPv3 access to MIB data' in this document, as SNMPv3 uses SNMPv2 PDU types and protocol operations.
さらに、SNMPv3はSNMPv2のPDUタイプとプロトコル動作を使用して、このドキュメントの「MIBデータへのSNMPv3アクセス」の言及がないことに注意してください。
This approach requires an entity to support multiple SNMP message versions. Typically this means supporting SNMPv1, SNMPv2c, and SNMPv3 message versions. The behaviour of various types of SNMP applications which support multiple message versions is described in the following sections. This approach allows entities which support multiple SNMP message versions to coexist with and communicate with entities which support only a single SNMP message version.
このアプローチは、複数のSNMPメッセージバージョンをサポートすることを企業に要求します。典型的には、これは、SNMPv1、SNMPv2c、およびSNMPv3のメッセージバージョンをサポートすることを意味します。複数のメッセージのバージョンをサポートするSNMPアプリケーションの様々なタイプの動作は、以下のセクションに記載されています。このアプローチは、複数のSNMPメッセージバージョンをサポートするエンティティは、と共存し、単一のSNMPメッセージバージョンをサポートするエンティティと通信することを可能にします。
A command generator must select an appropriate message version when sending requests to another entity. One way to achieve this is to consult a local database to select the appropriate message version.
別のエンティティに要求を送信するとき、コマンドジェネレータは、適切なメッセージバージョンを選択する必要があります。これを達成する1つの方法は、適切なメッセージバージョンを選択するために、ローカルデータベースに相談することです。
In addition, a command generator MUST 'downgrade' GetBulk requests to GetNext requests when selecting SNMPv1 as the message version for an outgoing request. This is done by simply changing the operation type to GetNext, ignoring any non-repeaters and max-repetitions values, and setting error-status and error-index to zero.
発信要求のためのメッセージバージョンとしてのSNMPv1を選択する場合に加えて、コマンドジェネレータは、「ダウングレード」のGetBulk要求は、要求をGETNEXTしなければなりません。これは、単に、GetNextのに操作種別を変更する任意の非リピータおよび最大反復値を無視し、ゼロにエラーステータスとエラーインデックスを設定することによって行われます。
A command responder must be able to deal with both SNMPv1 and SNMPv2 access to MIB data. There are three aspects to dealing with this. A command responder must:
コマンド応答は、SNMPv1とSNMPv2の両方でMIBデータへのアクセスを扱うことができなければなりません。これに対処するには3つの側面があります。コマンド応答しなければなりません：
- Deal correctly with SNMPv2 access to MIB data that returns a Counter64 value while processing an SNMPv1 message,
- 、SNMPv1のメッセージを処理しながらカウンターに値を返すMIBデータへのSNMPv2アクセスで正しく対処
- Deal correctly with SNMPv2 access to MIB data that returns one of the three exception values while processing an SNMPv1 message, and
- SNMPv1のメッセージを処理しながら3つの例外のいずれかの値を返すMIBデータへのSNMPv2アクセスを正しく扱う、および
- Map SNMPv2 error codes returned from SNMPv2 access to MIB data into SNMPv1 error codes when processing an SNMPv1 message.
- マップのSNMPv2エラーコードのSNMPv1メッセージを処理するときのSNMPv1エラーコードにMIBデータへのSNMPv2アクセスから返されます。
Note that SNMPv1 error codes SHOULD NOT be used without any change when processing SNMPv2c or SNMPv3 messages, except in the case of proxy forwarding. Also, SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages. In the case of proxy forwarding, for backwards compatibility, SNMPv1 error codes may be used without any change in a forwarded SNMPv2c or SNMPv3 message.
プロキシ転送の場合を除いて、SNMPv2cのまたはSNMPv3のメッセージを処理するときのSNMPv1エラーコードをそのまま使用してはならないことに注意してください。また、MIBデータへのSNMPv1アクセスはSNMPv2cのか、SNMPv3のメッセージを処理するときに使用されるべきではありません。プロキシ転送の場合には、下位互換性のために、SNMPv1のエラーコードが転送SNMPv2cのまたはSNMPv3のメッセージにそのまま使用することができます。
The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which uses SNMPv2 access to MIB data when processing an SNMPv1 message.
以下のセクションでは、複数のSNMPメッセージバージョンをサポートしているコマンド応答アプリケーションの動作を記述し、SNMPv1のメッセージを処理するときにMIBデータへのSNMPv2アクセスを使用します。
The SMIv2 [RFC2578] defines one new syntax that is incompatible with SMIv1. This syntax is Counter64. All other syntaxes defined by SMIv2 are compatible with SMIv1.
SMIv2の[RFC2578]はでSMIv1と互換性がありませんつの新しい構文を定義します。この構文はCounter64のです。 SMIv2ので定義されたすべての他の構文はでSMIv1と互換性があります。
The impact on multi-lingual command responders is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version.
多言語コマンド応答に対する影響は、彼らがこれまでのSNMPv1メッセージバージョンを使用して受信された要求に応答してカウンターに値を含むバインディング変数を返してはならないということです。
Multi-lingual command responders SHALL take the approach that object instances whose type is Counter64 are implicitly excluded from view when processing an SNMPv1 message. So:
多言語コマンド応答型であるCounter64のSNMPv1のメッセージを処理するときに暗黙的にビューから除外されているオブジェクトインスタンスアプローチを講じなければなりません。そう：
- On receipt of an SNMPv1 GetRequest-PDU containing a variable binding whose name field points to an object instance of type Counter64, a GetResponsePDU SHALL be returned, with an error- status of noSuchName and the error-index set to the variable binding that caused this error.
- 名前フィールドポイントタイプCounter64ののオブジェクトインスタンスにバインド変数を含むのSNMPv1のGetRequest-PDUを受信すると、GetResponsePDUはnoSuchNameのエラー - ステータスと引き起こしたことをバインディング変数にエラーインデックスセットで、返却されますこのエラー。
- On an SNMPv1 GetNextRequest-PDU, any object instance which contains a syntax of Counter64 SHALL be skipped, and the next accessible object instance that does not have the syntax of Counter64 SHALL be retrieved. If no such object instance exists, then an error-status of noSuchName SHALL be returned, and the error-index SHALL be set to the variable binding that caused this error.
- SNMPv1のGetNextRequest-PDU、Counter64の構文がスキップさSHALL含む任意のオブジェクトのインスタンス、およびCounter64の構文を取得できないものとしていません、次のアクセス可能なオブジェクトインスタンスで。そのようなオブジェクトのインスタンスが存在しない場合、次にnoSuchNameのエラーステータスが返されるものとし、誤り率は、このエラーの原因となったバインディング変数に設定されなければなりません。
- Any SNMPv1 request which contains a variable binding with a Counter64 value is ill-formed, so the foregoing rules do not apply. If that error is detected, a response SHALL NOT be returned, since it would contain a copy of the ill-formed variable binding. Instead, the offending PDU SHALL be discarded and the counter snmpInASNParseErrs SHALL be incremented.
- 上記の規則が適用されないようにCounter64の値との結合変数を含む任意のSNMPv1要求は、病気に形成されています。そのエラーが検出された場合は、それが結合病気に形成された変数のコピーが含まれているであろうから、応答が返されないものとします。代わりに、問題のあるPDUは破棄されなければならず、カウンターsnmpInASNParseErrsがインクリメントされるものとする（SHALL）。
SNMPv2 provides a feature called exceptions, which allow an SNMPv2 Response PDU to return as much management information as possible, even when an error occurs. However, SNMPv1 does not support exceptions, and so an SNMPv1 Response PDU cannot return any management information, and can only return an error-status and an error-index value.
SNMPv2のは、SNMPv2のレスポンスPDUにエラーが発生した場合でも、できるだけ多くの管理情報を返すことができるように、例外、と呼ばれる機能を提供します。しかし、SNMPv1の例外をサポートしていない、ので、SNMPv1のレスポンスPDUは、任意の管理情報を返すことができない、とだけエラーステータスとエラーインデックス値を返すことができます。
When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert these exception values into SNMPv1 error codes.
SNMPv1の要求を受信すると、コマンド応答は、例外値のMIBデータへのSNMPv2アクセスを使用して、返された任意の変数バインディングを確認し、SNMPv1のエラーコードにこれらの例外値を変換しなければなりません。
The type of exception that can be returned when accessing MIB data and the action taken depends on the type of SNMP request.
MIBデータとアクションをアクセスする際に返すことができる例外の種類は、SNMP要求の種類によって異なります。
- For a GetRequest, a noSuchObject or noSuchInstance exception may be returned.
- のGetRequestに関しては、noSuchObjectかnoSuchInstance例外が返されることがあります。
- For a GetNextRequest, an endOfMibView exception may be returned.
- GetNextRequestについて、endOfMibView例外が返されてもよいです。
- No exceptions will be returned for a SetRequest, and a GetBulkRequest should only be received in an SNMPv2c or SNMPv3 message, so these request types may be ignored when mapping exceptions.
- なし例外のSetRequestに対して返されません、そしてGetBulkRequestのみSNMPv2cのまたはSNMPv3のメッセージで受信されなければならないので、例外をマッピングするとき、これらの要求タイプは無視することができます。
Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference.
応答が複数の例外が含まれている場合、それが参照する必要があり、誤りインデックスを結合するためにどの変数として実装の選択肢があることに注意してください。
A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data indicates that the requested object instance can not be returned. The SNMPv1 error code for this condition is noSuchName, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.
MIBデータへのSNMPv2アクセスによって生成noSuchObjectまたはnoSuchInstance例外が要求されたオブジェクトのインスタンスを返すことができないことを示しています。この条件のためのSNMPv1エラーコードはnoSuchNameであるので応答PDUのエラーステータス・フィールドがnoSuchNameに設定されなければなりません。また、エラーインデックスフィールドは、例外が発生した変数バインディングのインデックス（つ以上が存在する場合、それが使用されるような実装の決定である）、そして元から変数バインディングリストに設定されなければなりません要求は、応答PDUで返送されなければなりません。
When an SNMPv2 access to MIB data returns a variable binding containing an endOfMibView exception, it indicates that there are no object instances available which lexicographically follow the object in the request. In an SNMPv1 agent, this condition normally results in a noSuchName error, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.
MIBデータへのSNMPv2アクセスがendOfMibView例外を含むバインディング変数を返す場合には、辞書編集リクエスト内のオブジェクトに追従利用可能なオブジェクトインスタンスが存在しないことを示しています。 SNMPv1エージェントでは、この状態は通常、noSuchNameエラーになり、そのため応答PDUのエラーステータス・フィールドがnoSuchNameに設定されなければなりません。また、エラーインデックスフィールドは、例外が発生した変数バインディングのインデックス（つ以上が存在する場合、それが使用されるような実装の決定である）、そして元から変数バインディングリストに設定されなければなりません要求は、応答PDUで返送されなければなりません。
When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data.
SNMPv1のGetRequestを処理するときにMIBデータへのSNMPv2アクセスを使用する場合、以下の手順に従わなければなりません。
When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then:
MIBデータへのそのようなアクセスは、次に、SNMPv2の構文とエラーステータス値を使用して応答データを返すとき。
(1) If the error-status is anything other than noError,
（1）エラーステータスがNOERROR以外の場合は、
- The error status SHALL be translated to an SNMPv1 error-
status using the table in section 4.4, "Error Status
Mappings".
- The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
- エラー率は、エラー状態を引き起こした結合可変の（オリジナルの要求で）位置に設定されなければなりません。
- The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
- 応答PDUの変数バインディングリストは正確にオリジナルの要求で受信した変数バインディングリストと同じにしなければなりません。
(2) If the error-status is noError, the variable bindings SHALL be checked for any SNMPv2 exception (noSuchObject or noSuchInstance) or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64). If there are any such variable bindings, one of those variable bindings SHALL be selected (it is an implementation choice as to which is selected), and:
エラーステータスがNOERROR（2）である場合、変数バインディングは、任意のSNMPv2例外（noSuchObjectまたはnoSuchInstance）またはSNMPv1の（Counter64の）に未知であるのSNMPv2構文をチェックしなければなりません。このような変数バインディングが存在する場合、それらの変数バインディングの一方が（れるが選択されているように、それが実装選択である）を選択し、なければなりません。
- The error-status SHALL be set to noSuchName,
- エラーステータスがnoSuchNameに設定されなければなりません、
- The error-index SHALL be set to the position (in the variable binding list of the original request) of the selected variable binding, and
- エラーインデックスは、選択された変数バインディングの（元の要求の変数バインディングリスト内の）位置に設定されなければならない、そして
- The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
- 応答PDUの変数バインディングリストは、元の要求で受信した変数バインディングリストと全く同じでなければなりません。
(3) If there are no such variable bindings, then:
（3）そのような変数バインディングが存在しない場合、その後：
- The error-status SHALL be set to noError,
- エラーステータスはNOERRORに設定されなければなりません、
- The error-index SHALL be set to zero, and
- エラーインデックスがゼロに設定されるもの、及び
- The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data.
- それは、MIBデータへのアクセスによって返されるように、応答の変数バインディングリストは、データから構成されなければなりません。
When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when SNMPv2 access to MIB data is used as part of processing the request. There may be repetitive accesses to MIB data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures are followed only for data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request.
SNMPv1のGetNextRequestを処理するときにMIBデータへのSNMPv2アクセス要求の処理の一部として使用する場合、以下の手順に従わなければなりません。 MIBデータへの繰り返しアクセスが辞書的要求の各オブジェクトを次の最初のオブジェクトを見つけようとすることがあるかもしれません。これは実装固有のものです。これらの手順は、唯一のMIBデータへのSNMPv2アクセスを使用するときに返されたデータのために続いています。データは、SNMPv1要求の通常の方法で処理することができるMIBデータへのSNMPv1アクセスを使用して返さ。
First, if the access to MIB data returns an error-status of anything other than noError:
まず、MIBデータへのアクセスはNOERROR以外のエラーステータスを返した場合：
(1) The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.4, "Error Status Mappings".
（1）エラーステータスは、セクション4.4、「エラー状態マッピング」のテーブルを使用してのSNMPv1エラーステータスに翻訳するもの。
(2) The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
（2）エラー率は、エラー状態を引き起こした結合可変の（オリジナルの要求で）位置に設定されなければなりません。
(3) The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
（3）応答の変数バインディングリストは、PDUは、元の要求で受信した変数バインディングリストと全く同じでなければなりません。
Otherwise, if the access to MIB data returns an error-status of noError:
それ以外の場合は、MIBデータへのアクセスは、NOERRORのエラーステータスを返した場合：
(1) Any variable bindings containing an SNMPv2 syntax of Counter64 SHALL be considered to be not in view, and MIB data SHALL be accessed as many times as is required until either a value other than Counter64 is returned, or an error or endOfMibView exception occurs.
（1）カウンターにのSNMPv2の構文を含む任意の変数バインディングはないビューであると見なされるものとし、必要とされるようCounter64の以外のいずれかの値が返されるまで、MIBデータを何度もアクセスされるべきであり、またはエラーまたはendOfMibView例外が発生します。
(2) If there is any variable binding that contains an SNMPv2 exception endOfMibView (if there is more than one then it is an implementation decision as to which is chosen):
（2）任意の変数（2つ以上が存在する場合、それがどのように実装決定で選択される）ことがSNMPv2の例外endOfMibViewを含有する結合がある場合。
- The error-status SHALL be set to noSuchName,
- エラーステータスがnoSuchNameに設定されなければなりません、
- The error-index SHALL be set to the position (in the variable binding list of the original request) of the variable binding that returned such an SNMPv2 exception, and
- エラーインデックスは、SNMPv2の例外が返された変数バインディングの位置（元の要求の変数バインディングリスト内）に設定すると
- The variable binding list of the response PDU SHALL be exactly the same as the variable binding list that was received in the original request.
- 応答PDUの変数バインディングリストは、元の要求で受信した変数バインディングリストと全く同じでなければなりません。
(3) If there are no such variable bindings, then:
（3）そのような変数バインディングが存在しない場合、その後：
- The error-status SHALL be set to noError,
- エラーステータスはNOERRORに設定されなければなりません、
- The error-index SHALL be set to zero, and
- エラーインデックスがゼロに設定されるもの、及び
- The variable binding list of the response SHALL be composed from the data as it is returned by the access to MIB data.
- それは、MIBデータへのアクセスによって返されるように、応答の変数バインディングリストは、データから構成されなければなりません。
When processing an SNMPv1 SetRequest, the following procedures MUST be followed when using SNMPv2 access to MIB data.
SNMPv1のSetRequestを処理するときにMIBデータへのSNMPv2アクセスを使用する場合、以下の手順に従わなければなりません。
When such MIB access returns response data using SNMPv2 syntax and error-status values, and the error-status is anything other than noError, then:
そして、そのようなMIBアクセスがSNMPv2の構文とエラーステータス値を使用して応答データを返し、エラーステータスはNOERROR以外のとき：
- The error status SHALL be translated to an SNMPv1 error-status using the table in section 4.4, "Error Status Mappings".
- エラーステータスは、セクション4.4、「エラー状況マッピング」でテーブルを使用してのSNMPv1エラー状況に翻訳するもの。
- The error-index SHALL be set to the position (in the original request) of the variable binding that caused the error-status.
- エラー率は、エラー状態を引き起こした結合可変の（オリジナルの要求で）位置に設定されなければなりません。
- The variable binding list of the response PDU SHALL be made exactly the same as the variable binding list that was received in the original request.
- 応答PDUの変数バインディングリストは正確にオリジナルの要求で受信した変数バインディングリストと同じにしなければなりません。
A notification originator must be able to translate between SNMPv1 notification parameters and SNMPv2 notification parameters in order to send a notification using a particular SNMP message version. If a notification is generated using SNMPv1 notification parameters, and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2 notification parameters. Likewise, if a notification is generated using SNMPv2 notification parameters, and configuration information specifies that notifications be sent using SNMPv1, the notification parameters must be translated to SNMPv1 notification parameters. In this case, if the notification cannot be translated (due to the presence of a Counter64 type), it will not be sent using SNMPv1.
通知発信者は、特定のSNMPメッセージバージョンを使用して通知を送信するために、SNMPv1の通知パラメータとSNMPv2通知パラメータの間で翻訳することができなければなりません。通知はSNMPv1の通知パラメータを使用して生成、および構成情報が通知はSNMPv2cのか、SNMPv3のを使用して送信することを指定した場合、通知パラメータは、SNMPv2の通知パラメータに変換する必要があります。通知はSNMPv2の通知パラメータを使用して生成、および構成情報が通知がSNMPv1のを使用して送信することを指定した場合同様に、通知パラメータは、SNMPv1通知パラメータに変換する必要があります。通知は、（原因Counter64のタイプが存在するために）変換できない場合は、この場合には、それは、SNMPv1を使用して送信されません。
When a notification originator generates a notification, using parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB, if the SNMP version used to generate the notification is SNMPv1, the PDU type used will always be a TrapPDU, regardless of whether the value of snmpNotifyType is trap(1) or inform(2).
通知の発信者は、SNMP-TARGET-MIBやSNMP-NOTIFICATION-MIBから得られたパラメータを使用して、通知を生成するときに、通知を生成するために使用されるSNMPバージョンがSNMPv1のであれば、使用されるPDUタイプは関係なく、常にかどうか、TrapPDUなりするsnmpNotifyTypeの値はトラップである（1）又は（2）を通知します。
Note also that access control and notification filtering are performed in the usual manner for notifications, regardless of the SNMP message version to be used when sending a notification. The parameters for performing access control are found in the usual manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in order to perform the access check specified in [RFC3413], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated.
メモはまた、アクセス制御および通知フィルタリングは関係なく、通知を送信するときに使用するSNMPメッセージバージョンを、通知のための通常の方法で行われます。アクセス制御を行うためのパラメータ（すなわち、SNMP-TARGET-MIBやSNMP-NOTIFICATION-MIBを検査から）通常の方法で見出されます。セクション3.1で説明したように、特に、[RFC3413]で指定されたアクセスチェック、セクション3.3を実行するために、弾丸をSNMPv1トラップを生成する場合（3）、通知元はsnmpTrapOID.0の値を生成する必要がある場合があり、弾丸（2）及び（3）は、この文書の。使用されているSNMPv1の通知パラメータは、以前にSNMPv2の通知パラメータのセットから翻訳された場合、この値は既にそれが発生しない必要がある場合には、知られていてもよいです。
There are no special requirements of a notification receiver. However, an implementation may find it useful to allow a higher level application to request whether notifications should be delivered to a higher level application using SNMPv1 notification parameter or SNMPv2 notification parameters. The notification receiver would then translate notification parameters when required in order to present a notification using the desired set of parameters.
通知受信の特別な要件はありません。しかし、実装は、それが有用な通知がSNMPv1の通知パラメータまたはSNMPv2の通知パラメータを使用して、より高いレベルのアプリケーションに配信されるべきかどうかを要求するために、より高いレベルのアプリケーションを可能にするかもしれません。パラメータの所望のセットを使用して通知を提示するために必要なときに通知受信機は、通知パラメータを変換することになります。
A proxy implementation may be used to enable communication between entities which support different SNMP message versions. This is accomplished in a proxy forwarder application by performing translations on PDUs. These translations depend on the PDU type, the SNMP version of the packet containing a received PDU, and the SNMP version to be used to forward a received PDU. The following sections describe these translations. In all cases other than those described below, the proxy SHALL forward a received PDU without change, subject to size constraints as defined in section 5.3 (Community MIB) of this document. Note that in the following sections, the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator, regardless of the PDU type or direction.
プロキシ実装が異なるSNMPメッセージバージョンをサポートするエンティティ間の通信を可能にするために使用されてもよいです。これは、PDUの上で翻訳を実行することにより、プロキシフォワーダアプリケーションで達成されます。これらの翻訳は、PDUの種類によって異なり、受信されたPDUを含むパケット、及びSNMPバージョンのSNMPバージョンが受信されたPDUを転送するために使用されます。次のセクションでは、これらの翻訳を説明します。以下に記載されたもの以外のすべての場合において、プロキシはこの文書のセクション5.3（コミュニティMIB）で定義されるようにサイズの制約を受け、変化することなく、受信したPDUを送付しなければなりません。以下のセクションでは、「上流バージョン」コマンド生成または通知の受信機とプロキシの間で使用されるバージョンを意味し、「下流版」プロキシとコマンド応答又は通知元の間で使用されるバージョンを意味することに注意してくださいかかわらず、PDUの種類または方向。
- If a GetBulkRequest-PDU is received and must be forwarded using the SNMPv1 message version, the proxy forwarder SHALL act as if the non-repeaters and max-repetitions fields were both set to 0, and SHALL set the tag of the PDU to GetNextRequest-PDU.
- GetBulkRequest-PDUが受信されるとのSNMPv1メッセージバージョンを使用して転送されなければならない場合、プロキシ・フォワーダは、非リピータおよび最大繰り返しフィールドは0に両方のセットであるかのように行動するもの、およびGetNextRequestにPDUのタグを設定するものと-PDU。
- If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was not a GetBulkRequest-PDU, the proxy forwarder SHALL remove the contents of the variable-bindings field and ensure that the error-index field is set to 0 before forwarding the response.
- のGetResponse-PDUは、そのエラーステータスフィールド「がtooBig」の値を有する受信され、メッセージはSNMPv2cのまたはSNMPv3のメッセージバージョンを使用して転送され、プロキシによって受信された元の要求がGetBulkRequest-PDUなかった場合、プロキシフォワーダは、変数バインディング・フィールドの内容を削除し、エラーインデックスフィールドは応答を転送する前に0に設定されていることを保証しなければなりません。
- If a GetResponse-PDU is received whose error-status field has a value of 'tooBig', and the message will be forwarded using the SNMPv2c or SNMPv3 message version, and the original request received by the proxy was a GetBulkRequest-PDU, the proxy forwarder SHALL re-send the forwarded request (which would have been altered to be a GetNextRequest-PDU) with all but the first variable-binding removed. The proxy forwarder SHALL only re-send such a request a single time. If the resulting GetResponse-PDU also contains an error-status field with a value of 'tooBig', then the proxy forwarder SHALL remove the contents of the variable- bindings field, and change the error-status field to 'noError', and ensure that the error-index field is set to 0 before forwarding the response. Note that if the original request only contained a single variable-binding, the proxy may skip re-sending the request and simply remove the variable-bindings and change the error-status to 'noError'. Further note that, while it might have been possible to fit more variable bindings if the proxy only re-sent the request multiple times, and stripped only a single variable binding from the request at a time, this is deemed too expensive. The approach described here preserves the behaviour of a GetBulkRequest as closely as possible, without incurring the cost of re-sending the request multiple times.
- のGetResponse-PDUは、そのエラーステータスフィールド「がtooBig」の値を有し、メッセージはSNMPv2cのまたはSNMPv3のメッセージバージョンを使用して転送され、プロキシによって受信された元の要求は、GetBulkRequest-PDUた受信された場合プロキシフォワーダは、すべてが、最初の変数が結合を除去して（GetNextRequest-PDUであるように変更されていたであろう）転送された要求を再送信しなければなりません。プロキシフォワーダは、そのような要求に単一の時間を再送信しなければなりません。得られたGetResponse-PDUも「がtooBig」の値とエラーステータス・フィールドが含まれている場合、プロキシ・フォワーダはvariable-バインディングフィールドの内容を削除し、エラーステータスフィールドに「NOERROR」に変更し、確認しなければなりませんエラーインデックスフィールドは、応答を転送する前に0に設定されていること。元の要求は、単一の可変結合が含まれている場合、プロキシは再送要求をスキップし、単に変数バインディングを削除し、「NOERROR」にエラーステータスを変更してもよいことに留意されたいです。プロキシが唯一の要求を再送信した場合より多くの変数束縛を合わせて複数回可能となって、その時の要求から結合のみ単一の変数を剥奪しているかもしれないが、ことを更に注目すべきは、これはあまりにも高価であると考えられます。ここで説明するアプローチは、再送要求を複数回のコストをかけず、可能な限り厳密GetBulkRequestの動作を維持します。
- If a Trap-PDU is received, and will be forwarded using the SNMPv2c or SNMPv3 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as an SNMPv2-Trap-PDU.
- トラップPDUが受信され、およびSNMPv2cまたはSNMPv3のメッセージバージョンを使用して転送される場合、プロキシはセクション3に記載の変換規則を適用しなければならない、およびSNMPv2トラップ-PDUのような通知を送付しなければなりません。
Note that when an SNMPv1 agent generates a message containing a Trap-PDU which is subsequently forwarded by one or more proxy forwarders using SNMP versions other than SNMPv1, the community string and agent-addr fields from the original message generated by the SNMPv1 agent will be preserved through the use of the snmpTrapAddress and snmpTrapCommunity objects.
SNMPv1エージェントがその後のSNMPv1以外のSNMPバージョンを使用して、1つのまたは複数のプロキシフォワーダによって転送されるトラップPDUを含むメッセージを生成するとき、SNMPv1エージェントによって生成された元のメッセージからのコミュニティ・ストリングとエージェントADDRフィールドは、あろうことに注意してくださいsnmpTrapAddressとsnmpTrapCommunityオブジェクトを使用して保存しました。
- If a GetResponse-PDU is received in response to a GetRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64 or which contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the Counter64 type or exception code.
- のGetResponse-PDUはSNMPv2の例外コードを含むタイプCounter64のまたは可変束縛を含んのGetRequest-PDU（以前にプロキシによって生成される）に応答して受信され、メッセージは、SNMPv1のメッセージバージョンを使用して転送される場合、プロキシはnoSuchNameエラーステータス値を含む、オリジナルのSNMPv1要求からリクエストIDと変数バインディングからなる代替応答PDUを生成し、可変結合Counter64のタイプを含むの位置を示すエラーインデックス値を含有しなければなりませんまたは例外コード。
- If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings that contain an SNMPv2 exception code, and the message would be forwarded using the SNMPv1 message version, the proxy MUST generate an alternate response PDU consisting of the request-id and variable bindings from the original SNMPv1 request, containing a noSuchName error-status value, and containing an error-index value indicating the position of the variable-binding containing the exception code.
- のGetResponse-PDUはSNMPv2の例外コードを含む可変束縛を含んGetNextRequest-PDU（以前にプロキシによって生成される）に応答して受信され、メッセージは、SNMPv1のメッセージバージョンを使用して転送される場合、プロキシは生成しなければなりません代替応答PDU noSuchNameエラーステータス値を含む、可変結合例外コードを含むの位置を示すエラーインデックス値を含む、オリジナルのSNMPv1要求からリクエストIDと変数バインディングからなります。
- If a GetResponse-PDU is received in response to a GetNextRequest-PDU (previously generated by the proxy) which contains variable-bindings of type Counter64, the proxy MUST re-send the entire GetNextRequest-PDU, with the following modifications. For any variable bindings in the received GetResponse which contained Counter64 types, the proxy substitutes the object names of these variable bindings for the corresponding object names in the previously-sent GetNextRequest. The proxy MUST repeat this process until no Counter64 objects are returned. Note that an implementation may attempt to optimize this process of skipping Counter64 objects. One approach to such an optimization would be to replace the last sub-identifier of the object names of varbinds containing a Counter64 type with 65535 if that sub-identifier is less than 65535, or with 4294967295 if that sub-identifier is greater than 65535. This approach should skip multiple instances of the same Counter64 object, while maintaining compatibility with some broken agent implementations (which only use 16-bit integers for sub-identifiers).
- のGetResponse-PDUタイプCounter64のの可変束縛を含み（以前にプロキシによって生成された）GetNextRequest-PDUに応答して受信された場合、プロキシは、以下の改変を、全体GetNextRequest-PDUを再送信しなければなりません。 Counter64のタイプを含んでいた受信したGetResponseにおける任意の変数バインディングのために、プロキシは、以前に送信されたGetNextRequestに対応するオブジェクト名のこれらの変数のバインディングのオブジェクト名を代入します。何Counter64のオブジェクトが返されなくなるまで、プロキシは、このプロセスを繰り返す必要があります。実装はCounter64のオブジェクトをスキップし、このプロセスを最適化しようと試みることができることに留意されたいです。そのような最適化するための一つのアプローチは、そのサブ識別子が65535より大きい場合、そのサブ識別子は65535未満、または4294967295である場合は65535でCounter64のタイプを含む変数バインドのオブジェクト名の最後のサブ識別子を置換することであろう。 （唯一の副識別子の16ビット整数を使用する）いくつかの壊れたエージェントの実装との互換性を維持しながら、このアプローチは、同じCounter64のオブジェクトの複数のインスタンスをスキップしなければなりません。
Deployment Hint: The process of repeated GetNext requests used by a proxy when Counter64 types are returned can be expensive. When deploying a proxy, this can be avoided by configuring the target agents to which the proxy forwards requests in a manner such that any objects of type Counter64 are in fact not-in-view for the principal that the proxy is using when communicating with these agents. However, when using such a configuration, one should be careful to use a different principal for communicating with the target agent when an incoming SNMPv2c or SNMPv3 request is received, to ensure that objects of type Counter64 are properly returned.
展開のヒント：Counter64のタイプは高価なことができます返されたプロキシが使用する繰り返しのGetNext要求のプロセス。プロキシを配備するとき、これは、プロキシがタイプCounter64の任意のオブジェクトが実際にあるように要求を転送しないようにインビュープリンシパルのこれらと通信するとき、プロキシが使用しているターゲット・エージェントを構成することによって回避することができます薬。このような構成を使用する場合しかし、1型Counter64ののオブジェクトが適切に返されることを保証するために、着信SNMPv2cのまたはSNMPv3の要求を受信するターゲットエージェントと通信するための異なるプリンシパルを使用するように注意しなければなりません。
- If a GetResponse-PDU is received which contains an SNMPv2 error-status value of wrongValue, wrongEncoding, wrongType, wrongLength, inconsistentValue, noAccess, notWritable, noCreation, inconsistentName, resourceUnavailable, commitFailed, undoFailed, or authorizationError, and the message would be forwarded using the SNMPv1 message version, the error-status value is modified using the mappings in section 4.4.
- のGetResponse-PDUはwrongValue、wrongEncoding、wrongType、wrongLength、はinconsistentValue、NOACCESS、notWritable、noCreation、inconsistentName、resourceUnavailable、commitFailed、undoFailed、又はauthorizationErrorのSNMPv2のエラーステータス値を含む受信され、メッセージが転送された場合SNMPv1のメッセージバージョンを使用して、エラー状態値はセクション4.4でマッピングを使用して修正されます。
- If an SNMPv2-Trap-PDU is received, and will be forwarded using the SNMPv1 message version, the proxy SHALL apply the translation rules described in section 3, and SHALL forward the notification as a Trap-PDU. Note that if the translation fails due to the existence of a Counter64 data-type in the received SNMPv2-Trap-PDU, the trap cannot be forwarded using SNMPv1.
- SNMPv2のトラップ-PDUが受信され、そしてSNMPv1のメッセージバージョンを使用して転送される場合、プロキシはセクション3に記載の変換規則を適用しなければならない、およびトラップ-PDUのような通知を送付しなければなりません。翻訳による受信のSNMPv2トラップ-PDUにおけるCounter64のデータ型の存在に失敗した場合、トラップのSNMPv1を使用して転送することができないことに留意されたいです。
- If an InformRequest-PDU is received, any configuration information indicating that it would be forwarded using the SNMPv1 message version SHALL be ignored. An InformRequest-PDU can only be forwarded using the SNMPv2c or SNMPv3 message version. The InformRequest-PDU may still be forwarded if there is other configuration information indicating that it should be forwarded using SNMPv2c or SNMPv3.
- InformRequest-PDUを受信した場合、それはSNMPv1のメッセージバージョンを使用して転送されることを示す任意の構成情報は無視されます。 InformRequest-PDUのみSNMPv2cのまたはSNMPv3のメッセージバージョンを使用して転送することができます。 InformRequest-PDUは、まだそれがSNMPv2cのまたはSNMPv3のを使用して転送されるべきであることを示すその他の設定情報がある場合に転送されてもよいです。
The following tables shows the mappings of SNMPv1 error-status values into SNMPv2 error-status values, and the mappings of SNMPv2 error-status values into SNMPv1 error-status values.
次の表のSNMPv1エラーステータス値にSNMPv2のエラーステータス値、およびSNMPv2エラーステータス値のマッピングへのSNMPv1エラーステータス値のマッピングを示します。
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
Whenever the SNMPv2 error-status value of authorizationError is translated to an SNMPv1 error-status value of noSuchName, the value of snmpInBadCommunityUses MUST be incremented.
authorizationErrorのSNMPv2のエラーステータスの値がnoSuchNameのSNMPv1のエラーステータス値に変換されるたびに、snmpInBadCommunityUsesの値が増加しなければなりません。
In order to adapt SNMPv1 (and SNMPv2c) into the SNMP architecture, the following Message Processing (MP) models are defined in this document:
SNMPアーキテクチャにSNMPv1の（およびSNMPv2c）を適合させるためには、以下のメッセージ処理（MP）のモデルは、この文書で定義されています。
- The SNMPv1 Message Processing Model
- SNMPv1のメッセージ処理モデル
- The SNMPv1 Community-Based Security Model
- SNMPv1のコミュニティベースのセキュリティモデル
- The SNMPv2c Message Processing Model
- SNMPv2cのメッセージ処理モデル
- The SNMPv2c Community-Based Security Model
- SNMPv2cのコミュニティベースのセキュリティモデル
In most respects, the SNMPv1 Message Processing Model and the SNMPv2c Message Processing Model are identical, and so these are not discussed independently in this document. Differences between the two models are described as required.
ほとんどの点では、SNMPv1のメッセージ処理モデルとSNMPv2cのメッセージ処理モデルは同じであるので、これらは、本文書に独立して議論されていません。二つのモデル間の違いは、必要に応じて記載されています。
Similarly, the SNMPv1 Community-Based Security Model and the SNMPv2c Community-Based Security Model are nearly identical, and so are not discussed independently. Differences between these two models are also described as required.
同様に、SNMPv1のコミュニティベースのセキュリティモデルおよびSNMPv2cコミュニティベースのセキュリティモデルは、ほぼ同一であるので、独立して議論されていません。必要に応じて、これらの二つのモデルの違いについても説明されています。
The SNMPv1 (and SNMPv2c) Message Processing Model and Security Model require mappings between parameters used in SNMPv1 (and SNMPv2c) messages, and the version independent parameters used in the SNMP architecture [RFC3411]. The parameters which MUST be mapped consist of the SNMPv1 (and SNMPv2c) community name, and the SNMP securityName and contextEngineID/contextName pair. A MIB module (the SNMP-COMMUNITY-MIB) is provided in this document in order to perform these mappings. This MIB provides mappings in both directions, that is, a community name may be mapped to a securityName, contextEngineID, and contextName, or the combination of securityName, contextEngineID, and contextName may be mapped to a community name.
SNMPv1の（およびSNMPv2c）メッセージ処理モデルとセキュリティモデルは、SNMPv1（およびSNMPv2c）メッセージで使用されるパラメータ、およびSNMPアーキテクチャ[RFC3411]で使用されるバージョンの独立したパラメータ間のマッピングが必要です。マッピングされなければならないパラメータは、SNMPv1（およびSNMPv2c）コミュニティ名、およびSNMPのsecurityNameとcontextEngineID /のcontextNameペアから成ります。 MIBモジュール（SNMPコミュニティ-MIB）は、これらのマッピングを実行するために、本書で提供されます。このMIBは、それは、コミュニティ名のsecurityName、contextEngineIDとcontextNameは、またはのsecurityName、contextEngineIDの組み合わせにマッピングされてもよいし、両方向でのマッピングを提供し、のcontextNameはコミュニティ名にマッピングすることができます。
The SNMPv1 Message Processing Model handles processing of SNMPv1 messages. The processing of messages is handled generally in the same manner as described in RFC 1157 [RFC1157], with differences and clarifications as described in the following sections. The SnmpMessageProcessingModel value for SNMPv1 is 0 (the value for SNMPv2c is 1).
SNMPv1のメッセージ処理モデルは、SNMPv1メッセージの処理を処理します。 RFC 1157に記載されているようにメッセージの処理は、以下のセクションに記載されるような違いと説明して、[RFC1157]と同様に、一般的に処理されます。 SNMPv1のためSnmpMessageProcessingModel値（SNMPv2cのための値が1である）0です。
In RFC 1157 [RFC1157], section 4.1, item (3) for an entity which receives a message, states that various parameters are passed to the "desired authentication scheme". The desired authentication scheme in this case is the SNMPv1 Community-Based Security Model, which will be called using the processIncomingMsg ASI. The parameters passed to this ASI are:
メッセージを受信したエンティティのRFC 1157 [RFC1157]、セクション4.1、アイテム（3）において、様々なパラメータが「所望の認証方式」に渡されることを述べています。この場合、必要な認証スキームはprocessIncomingMsg ASIを使用して呼び出されますSNMPv1のコミュニティベースのセキュリティモデル、です。このASIに渡されたパラメータは次のとおりです。
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- （SNMPv2cのために、または1）が0になりmessageProcessingModel、。
- The maxMessageSize, which should be the maximum size of a message that the receiving entity can generate (since there is no such value in the received message).
- （受信されたメッセージには、そのような値が存在しないため）、受信エンティティが生成できるメッセージの最大サイズであるべきであるmaxMessageSize、。
- The securityParameters, which consist of the community string and the message's source and destination transport domains and addresses.
- コミュニティ文字列で構成さsecurityParameters、およびメッセージの送信元と送信先の輸送ドメインとアドレス。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- （SNMPv2cのために、または2）1あろうsecurityModel、。
- The securityLevel, which will be noAuthNoPriv.
- noAuthNoPrivになりたsecurityLevel、。
- The wholeMsg and wholeMsgLength.
- wholeMsgとwholeMsgLength。
The Community-Based Security Model will attempt to select a row in the snmpCommunityTable. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:
コミュニティベースのセキュリティモデルはsnmpCommunityTableで行を選択しようとします。これは、辞書式順序でsnmpCommunityTableて検索を実行することによって行われます。次のマッチング基準が満たされている最初のエントリが選択されます。
- The community string is equal to the snmpCommunityName value.
- コミュニティストリングはsnmpCommunityName値に等しいです。
- If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress from which the message was received must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value. The snmpTargetAddrTMask object is used as described in section 5.3 when checking whether the transportDomain and transportAddress matches a entry in the snmpTargetAddrTable.
- snmpCommunityTransportTagが空の文字列である場合、それはマッチングの目的のために無視されます。 snmpCommunityTransportTagが空の文字列でない場合は、メッセージが受信されたtransportDomainとtransportAddressはsnmpCommunityTransportTag値によって選択されたsnmpTargetAddrTableのエントリのいずれかと一致しなければなりません。 transportDomainか否かをチェックするときセクション5.3に記載されtransportAddressはsnmpTargetAddrTableのエントリと一致するようにsnmpTargetAddrTMaskオブジェクトが使用されます。
If no such entry can be found, an authentication failure occurs as described in RFC 1157 [RFC1157], and the snmpInBadCommunityNames counter is incremented.
そのようなエントリが見つからない場合、認証失敗は、RFC 1157 [RFC1157]に記載されているように発生し、のsnmpInBadCommunityNamesカウンタがインクリメントされます。
The parameters returned from the Community-Based Security Model are:
コミュニティベースのセキュリティモデルから返されたパラメータは次のとおりです。
- The securityEngineID, which will always be the local value of snmpEngineID.0.
- 常にsnmpEngineID.0の局所的な値になりますsecurityEngineID、。
- The securityName, which will be the value of snmpCommunitySecurityName from the selected row in the snmpCommunityTable.
- snmpCommunityTableで選択された行からsnmpCommunitySecurityNameの値となるのsecurityName。
- The scopedPDU. Note that this parameter will actually consist of three values, the contextSnmpEngineID (which will be the value of snmpCommunityContextEngineID from the selected entry in the snmpCommunityTable), the contextName (which will be the value of snmpCommunityContextName from the selected entry in the snmpCommunityTable), and the PDU. These must be separate values, since the first two do not actually appear in the message.
- scopedPDUに。このパラメータは、実際には3つの値、（snmpCommunityTableで選択されたエントリからsnmpCommunityContextEngineIDの値となる）contextSnmpEngineID、（snmpCommunityTableで選択されたエントリからsnmpCommunityContextNameの値となる）のcontextNameで構成することに注意してください、そしてPDU。最初の二つは実際にメッセージに表示されませんので、これらは、別々の値でなければなりません。
- The maxSizeResponseScopedPDU, which will be derived using the minimum of the maxMessageSize above, and the value of snmpTargetAddrMMS of the selected row in the snmpTargetAddrTable. If no such entry was selected, then this value will be derived from the maxMessageSize only.
- 上記maxMessageSizeの最小値、およびsnmpTargetAddrTableの選択された行のsnmpTargetAddrMMSの値を用いて導出されるmaxSizeResponseScopedPDU、。このようなエントリが選択されなかった場合、この値は、maxMessageSizeから誘導されます。
- The securityStateReference, which MUST contain the community string from the original request.
- 元の要求からのコミュニティ文字列を含まなければならないsecurityStateReference、。
The appropriate SNMP application will then be called (depending on the value of the contextEngineID and the request type in the PDU) using the processPdu ASI. The parameters passed to this ASI are:
適切なSNMPアプリケーションは、processPdu ASIを使用して（contextEngineIDの値とPDUのリクエストタイプに応じて）と呼ぶことにします。このASIに渡されたパラメータは次のとおりです。
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- （SNMPv2cのために、または1）が0になりmessageProcessingModel、。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- （SNMPv2cのために、または2）1あろうsecurityModel、。
- The securityName, which was returned from the call to processIncomingMsg.
- processIncomingMsgへの呼び出しから返されたセキュリティ名、。
- The securityLevel, which is noAuthNoPriv.
- noAuthNoPrivにあるたsecurityLevel、。
- The contextEngineID, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- processIncomingMsgへの呼び出しからたscopedPDUの一部として返されたcontextEngineID、。
- The contextName, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- processIncomingMsgへの呼び出しからたscopedPDUの一部として返されたcontextNameは、。
- The pduVersion, which should indicate an SNMPv1 version PDU (if the message version was SNMPv2c, this would be an SNMPv2 version PDU).
- SNMPv1のバージョンPDUを示すべきpduVersionは、（メッセージバージョンがSNMPv2cのだった場合、これはSNMPv2のバージョンPDUであろう）。
- The PDU, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- processIncomingMsgへの呼び出しからたscopedPDUの一部として返されたPDU、。
- The maxSizeResponseScopedPDU which was returned from the call to processIncomingMsg.
- processIncomingMsgへの呼び出しから返されたmaxSizeResponseScopedPDU。
- The stateReference which was returned from the call to processIncomingMsg.
- processIncomingMsgへの呼び出しから返されたstateReference。
The SNMP application should process the request as described previously in this document. Note that access control is applied by an SNMPv3 command responder application as usual. The parameters as passed to the processPdu ASI will be used in calls to the isAccessAllowed ASI.
SNMPアプリケーションは、このドキュメントで前述したように、要求を処理する必要があります。そのアクセス制御は、通常通りのSNMPv3コマンド応答アプリケーションによって適用されます。 processPdu ASIに渡されるパラメータはisAccessAllowedのASIへの呼び出しで使用されます。
There is no special processing required for generating an outgoing response. However, the community string used in an outgoing response must be the same as the community string from the original request. The original community string MUST be present in the securityStateReference information of the original request.
送信応答を生成するために必要な特別な処理はありません。しかし、送信応答で使用されるコミュニティ文字列は、元の要求から、コミュニティストリングと同じでなければなりません。オリジナルのコミュニティ文字列は、元の要求のsecurityStateReference情報中に存在しなければなりません。
In a multi-lingual SNMP entity, the parameters used for generating notifications will be obtained by examining the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:
多言語SNMPエンティティに、通知を生成するために使用されるパラメータは、SNMP-TARGET-MIBやSNMP-NOTIFICATION-MIBを調べることによって得られるであろう。これらのパラメータは、sendPdu ASIを使用してのSNMPv1メッセージ処理モデルに渡されます。 SNMPv1のメッセージ処理モデルはsendPdu ASIに渡されたパラメータに基づいてsnmpCommunityTableで適切なコミュニティ文字列を検索しようとします。これは、辞書式順序でsnmpCommunityTableて検索を実行することによって行われます。次のマッチング基準が満たされている最初のエントリが選択されます。
- The securityName must be equal to the snmpCommunitySecurityName value.
- のsecurityNameはsnmpCommunitySecurityName値に等しくなければなりません。
- The contextEngineID must be equal to the snmpCommunityContextEngineID value.
- contextEngineIDはsnmpCommunityContextEngineID値に等しくなければなりません。
- The contextName must be equal to the snmpCommunityContextName value.
- のcontextNameはsnmpCommunityContextName値に等しくなければなりません。
- If the snmpCommunityTransportTag is an empty string, it is ignored for the purpose of matching. If the snmpCommunityTransportTag is not an empty string, the transportDomain and transportAddress must match one of the entries in the snmpTargetAddrTable selected by the snmpCommunityTransportTag value.
- snmpCommunityTransportTagが空の文字列である場合、それはマッチングの目的のために無視されます。 snmpCommunityTransportTagが空の文字列でない場合は、transportDomainとtransportAddressはsnmpCommunityTransportTag値によって選択されたsnmpTargetAddrTableのエントリのいずれかと一致する必要があります。
If no such entry can be found, the notification is not sent. Otherwise, the community string used in the outgoing notification will be the value of the snmpCommunityName column of the selected row.
そのようなエントリが見つからない場合は、通知が送信されません。そうでなければ、発信通知に使用されるコミュニティストリングは、選択された行のsnmpCommunityName列の値となります。
In a proxy forwarding application, when a received request is to be forwarded using the SNMPv1 Message Processing Model, the parameters used for forwarding will be obtained by examining the SNMP-PROXY-MIB and the SNMP-TARGET-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:
受信した要求がSNMPv1のメッセージ処理モデルを使用して転送するプロキシ転送アプリケーションにおいて、転送のために使用されるパラメータは、SNMP-PROXY-MIBやSNMP-TARGET-MIBを調べることによって得られるであろう。これらのパラメータは、sendPdu ASIを使用してのSNMPv1メッセージ処理モデルに渡されます。 SNMPv1のメッセージ処理モデルはsendPdu ASIに渡されたパラメータに基づいてsnmpCommunityTableで適切なコミュニティ文字列を検索しようとします。これは、辞書式順序でsnmpCommunityTableて検索を実行することによって行われます。次のマッチング基準が満たされている最初のエントリが選択されます。
- The securityName must be equal to the snmpCommunitySecurityName value.
- のsecurityNameはsnmpCommunitySecurityName値に等しくなければなりません。
- The contextEngineID must be equal to the snmpCommunityContextEngineID value.
- contextEngineIDはsnmpCommunityContextEngineID値に等しくなければなりません。
- The contextName must be equal to the snmpCommunityContextName value.
- のcontextNameはsnmpCommunityContextName値に等しくなければなりません。
If no such entry can be found, the proxy forwarding application should follow the procedure described in RFC 3413 [RFC3413], section 3.5.1.1, item (2). This procedure states that the snmpProxyDrops counter [RFC3418] is incremented, and that a Response-PDU is generated by calling the Dispatcher using the returnResponsePdu abstract service interface.
そのようなエントリが見つからない場合、プロキシ転送アプリケーションは[RFC3413]、セクション3.5.1.1、項目（2）RFC 3413に記載された手順に従うべきです。この手順はsnmpProxyDropsは[RFC3418]をカウンタインクリメントされ、応答-PDUがreturnResponsePdu抽象サービスインタフェースを使用して、ディスパッチャを呼び出すことによって生成されることを述べています。
The SNMP-COMMUNITY-MIB contains objects for mapping between community strings and version-independent SNMP message parameters. In addition, this MIB provides a mechanism for performing source address validation on incoming requests, and for selecting community strings based on target addresses for outgoing notifications. These two features are accomplished by providing a tag in the snmpCommunityTable which selects sets of entries in the snmpTargetAddrTable [RFC3413]. In addition, the SNMP-COMMUNITY-MIB augments the snmpTargetAddrTable with a transport address mask value and a maximum message size value. These values are used only where explicitly stated. In cases where the snmpTargetAddrTable is used without mention of these augmenting values, the augmenting values should be ignored.
SNMP-COMMUNITY-MIBには、コミュニティストリングとバージョンに依存しないSNMPメッセージパラメータ間のマッピングのためのオブジェクトが含まれています。また、このMIBは、受信した要求の送信元アドレスの検証を行い、発信する通知のターゲットアドレスに基づいてコミュニティストリングを選択するためのメカニズムを提供します。これら2つの機能はのsnmpTargetAddrTable [RFC3413]のエントリのセットを選択snmpCommunityTableにタグを提供することによって達成されます。また、SNMPコミュニティ-MIBは、トランスポート・アドレスのマスク値と最大メッセージサイズ値とのsnmpTargetAddrTableを増強します。これらの値は、明示的に述べ場所でのみ使用されます。 snmpTargetAddrTableは、これらの増強値の言及なしで使用される場合には、増強値は無視されなければなりません。
The mask value, snmpTargetAddrTMask, allows selected entries in the snmpTargetAddrTable to specify multiple addresses (rather than just a single address per entry). This would typically be used to specify a subnet in an snmpTargetAddrTable rather than just a single address. The mask value is used to select which bits of a transport address must match bits of the corresponding instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the snmpTargetAddrTable. The value of an instance of snmpTargetAddrTMask must always be an OCTET STRING whose length is either zero or the same as that of the corresponding instance of snmpTargetAddrTAddress.
マスク値、snmpTargetAddrTMaskは、snmpTargetAddrTableの選択されたエントリは、（むしろエントリ当たりただ1つのアドレスよりも）複数のアドレスを指定することを可能にします。これは通常、snmpTargetAddrTableのサブネットだけではなく、単一のアドレスを指定するために使用されるだろう。マスク値は、トランスポート・アドレスのビットがsnmpTargetAddrTableの特定のエントリと一致するトランスポートアドレスために、snmpTargetAddrTAddressの対応するインスタンスのビットと一致しなければならないかを選択するために使用されます。 snmpTargetAddrTMaskのインスタンスの値は、常に長さがゼロまたはsnmpTargetAddrTAddressの対応するインスタンスと同じであるオクテットストリングでなければなりません。
Note that the snmpTargetAddrTMask object is only used where explicitly stated. In particular, it is not used when generating notifications (i.e., when generating notifications, entries in the snmpTargetAddrTable only specify individual addresses). If use of the snmpTargetAddrTMask object is not mentioned in text describing matching addresses in the snmpTargetAddrTable, then its value MUST be ignored.
明示的に示した場合snmpTargetAddrTMaskオブジェクトのみが使用されていることに注意してください。通知を生成するとき、特に、それが（通知を生成するとき、すなわち、snmpTargetAddrTableのエントリのみが個別のアドレスを指定する）は使用されません。 snmpTargetAddrTMaskオブジェクトの使用はsnmpTargetAddrTableの一致するアドレスを説明するテキストに記載されていない場合、その値は無視されなければなりません。
When checking whether a transport address matches an entry in the snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-length OCTET STRING, the mask value is ignored, and the value of snmpTargetAddrTAddress must exactly match a transport address. Otherwise, each bit of each octet in the snmpTargetAddrTMask value corresponds to the same bit of the same octet in the snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding bits in the snmpTargetAddrTAddress value must match the bits in a transport address. If all such bits match, the transport address is matched by that snmpTargetAddrTable entry. Otherwise, the transport address is not matched.
トランスポートアドレスがsnmpTargetAddrTableのエントリと一致するかどうかをチェックするときsnmpTargetAddrTMaskの値が長さゼロオクテット文字列である場合、マスク値は無視され、snmpTargetAddrTAddressの値が正確にトランスポートアドレスと一致しなければなりません。そうでなければ、snmpTargetAddrTMask値の各オクテットの各ビットはsnmpTargetAddrTAddress値の同じオクテットの同一のビットに対応します。 snmpTargetAddrTMask値（1に等しく、すなわち、ビット）に設定されるビットは、snmpTargetAddrTAddress値の対応するビットは、トランスポート・アドレスのビットと一致しなければなりません。このようなすべてのビットが一致した場合、トランスポートアドレスはそののsnmpTargetAddrTableのエントリにマッチしています。それ以外の場合は、トランスポート・アドレスが一致しません。
The maximum message size value, snmpTargetAddrMMS, is used to determine the maximum message size acceptable to another SNMP entity when the value cannot be determined from the protocol.
最大メッセージサイズ値、snmpTargetAddrMMSは、値がプロトコルから決定することができないときに、別のSNMPエンティティに許容される最大メッセージサイズを決定するために使用されます。
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IpAddress, MODULE-IDENTITY, OBJECT-TYPE, Integer32, snmpModules FROM SNMPv2-SMI RowStatus, StorageType FROM SNMPv2-TC SnmpAdminString, SnmpEngineID FROM SNMP-FRAMEWORK-MIB SnmpTagValue, snmpTargetAddrEntry FROM SNMP-TARGET-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
輸入IPアドレス、MODULE-IDENTITY、OBJECT-TYPE、構文Integer32、SNMP-TARGET-MIB MODULE-COMPLIANCE、オブジェクト・グループからSNMP-FRAMEWORK-MIB SnmpTagValue、エントリFROM SNMPv2の-TCれるSnmpAdminString、のsnmpEngineID FROM SNMPv2の-SMIのRowStatus、StorageType FROM snmpModules SNMPv2の-CONF FROM;
snmpCommunityMIB MODULE-IDENTITY LAST-UPDATED "200308060000Z" -- 06 Aug 2003, midnight ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com In msg body: subscribe snmpv3
snmpCommunityMIBのMODULE-IDENTITY LAST-UPDATED "200308060000Z" - 2003年8月6日、深夜組織 "のSNMPv3ワーキンググループ" CONTACT-INFO「WG-メール：snmpv3@lists.tislabs.comは購読：majordomo@lists.tislabs.comをMSGボディで：SNMPv3のサブスクライブ
Co-Chair: Russ Mundy
SPARTA, Inc
Postal: 7075 Samuel Morse Drive
Columbia, MD 21045
USA
EMail: mundy@tislabs.com
Phone: +1 410-872-1515
Co-Chair: David Harrington Enterasys Networks Postal: 35 Industrial Way P. O. Box 5005 Rochester, New Hampshire 03866-5005 USA EMail: dbh@enterasys.com Phone: +1 603-337-2614
共同議長：デヴィッド・ハリントンのEnterasys Networksの郵便：35インダストリアルウェイP. O.ボックス5005ロチェスター、ニューハンプシャー州03866から5005 USAメール：dbh@enterasys.com電話：+1 603-337-2614
Co-editor: Rob Frye Vibrant Solutions
共同編集者：ロブ・フライ鮮やかなソリューション
Postal: 2711 Prosperity Ave Fairfax, Virginia 22031 USA E-mail: rfrye@vibrant-1.com Phone: +1-703-270-2000
郵便：2711繁栄アベニューフェアファックス、バージニア州22031 USA Eメール：rfrye@vibrant-1.com電話：+ 1-703-270-2000
Co-editor: David B. Levi Nortel Networks Postal: 3505 Kesterwood Drive Knoxville, Tennessee 37918 E-mail: dlevi@nortelnetworks.com Phone: +1 865 686 0432
共同編集者：デビッド・B・レビNortel Networksの郵便：3505 Kesterwoodドライブノックスヴィル、テネシー州37918 Eメール：dlevi@nortelnetworks.com電話：+1 865 686 0432
Co-editor: Shawn A. Routhier Wind River Systems, Inc. Postal: 500 Wind River Way Alameda, CA 94501 E-mail: sar@epilogue.com Phone: +1 510 749 2095
共同編集者：ショーンA. Routhierウインドリバーシステムズ社郵便：500ウインドリバーウェイアラメダ、CA 94501 Eメール：sar@epilogue.com電話：+1 510 749 2095
Co-editor: Bert Wijnen Lucent Technologies Postal: Schagen 33 3461 GL Linschoten Netherlands Email: bwijnen@lucent.com Phone: +31-348-407-775 "
共同編集者：バートWijnenルーセント・テクノロジーズ郵便：ショームバーグ33 3461 GL Linschotenオランダ電子メール：bwijnen@lucent.com電話：+ 31-348-407-775 "
DESCRIPTION "This MIB module defines objects to help support coexistence between SNMPv1, SNMPv2c, and SNMPv3.
DESCRIPTION「このMIBモジュールは、SNMPv1、SNMPv2c、およびSNMPv3の間の共存を支援するためのオブジェクトを定義します。
Copyright (C) The Internet Society (2003) This
version of this MIB module is part of RFC 3584;
see the RFC itself for full legal notices."
REVISION "200308060000Z" -- 06 Aug 2003 DESCRIPTION "Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation.
REVISION "200308060000Z" - 2003年8月6日DESCRIPTIONは「LAST-UPDATED、CONTACT-INFOを更新し、改訂条項およびMIBモジュールのMODULE-IDENTITYの呼び出しの説明節に著作権表示を追加しました。
Updated the description of snmpCommunityTransportTag
to make it consistent with the rest of the document.
Updated the description of `snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown.
0の値は、最大メッセージサイズが不明であることを意味することを明確にするために、 `snmpTargetAddrMMS」の記述を更新。
Changed the name of 'snmpCommunityGroup' to snmpCommunityTableGroup to avoid a name conflict with the SNMPv2-MIB.
SNMPv2の-MIBとの名前の競合を避けるために、snmpCommunityTableGroupに「snmpCommunityGroup」の名前を変更しました。
Updated DESCRIPTION of snmpCommunityName.
snmpCommunityNameの説明を更新。
Updated DESCRIPTION of snmpTrapCommunity.
snmpTrapCommunityの説明を更新。
Added snmpCommunityMIBFullCompliance.
snmpCommunityMIBFullComplianceが追加されました。
This version published as RFC 3584."
このバージョンでは、「RFC 3584で規定として公開します
REVISION "200003060000Z" -- 6 Mar 2000 DESCRIPTION "This version published as RFC 2576."
REVISION "200003060000Z" - 2000年3月6日DESCRIPTION "RFC 2576として発行され、このバージョン"
::= { snmpModules 18 }
-- Administrative assignments ************************************
- 行政割り当て************************************
snmpCommunityMIBObjects
OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBConformance
OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
-- -- The snmpCommunityTable contains a database of community -- strings. This table provides mappings between community -- strings, and the parameters required for View-based Access -- Control. --
- - 文字列 - snmpCommunityTableは、コミュニティのデータベースが含まれています。文字列、およびビューベースアクセスに必要なパラメータ - - コントロールこの表には、コミュニティ間のマッピングを提供します。 -
snmpCommunityTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of community strings configured in the SNMP
engine's Local Configuration Datastore (LCD)."
::= { snmpCommunityMIBObjects 1 }
snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESS not-accessible STATUS current
snmpCommunityEntryのOBJECT-TYPE SYNTAX SnmpCommunityEntry MAX-ACCESSステータス現在の
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
snmpCommunityIndex OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The unique index value of a row in this table."
::= { snmpCommunityEntry 1 }
snmpCommunityName OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The community string for which a row in this table
represents a configuration. There is no SIZE constraint
specified for this object because RFC 1157 does not
impose any explicit limitation on the length of community
strings (their size is constrained indirectly by the
SNMP message size)."
::= { snmpCommunityEntry 2 }
snmpCommunitySecurityName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A human readable string representing the corresponding
value of snmpCommunityName in a Security Model
independent format."
::= { snmpCommunityEntry 3 }
snmpCommunityContextEngineID OBJECT-TYPE
snmpCommunityContextEngineIDのOBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The contextEngineID indicating the location of the
context in which management information is accessed
when using the community string specified by the
corresponding instance of snmpCommunityName.
The default value is the snmpEngineID of the entity in
which this object is instantiated."
::= { snmpCommunityEntry 4 }
snmpCommunityContextName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The context in which management information is accessed
when using the community string specified by the
corresponding instance of snmpCommunityName."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 5 }
snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies a set of transport endpoints which are used in two ways: - to specify the transport endpoints from which an SNMP entity will accept management requests, and - to specify the transport endpoints to which a notification may be sent using the community string matching the corresponding instance of snmpCommunityName. In either case, if the value of this object has zero-length, transport endpoints are not checked when either authenticating messages containing this community string, nor when generating notifications.
snmpCommunityTransportTagのOBJECT-TYPE SYNTAX SnmpTagValue MAX-ACCESSはリード作成しますステータス現在の説明は「このオブジェクトは2つの方法で使用されているトランスポートエンドポイントのセットを指定します： - SNMPエンティティは管理要求を受け入れるからトランスポートエンドポイントを指定し、する - にします通知はsnmpCommunityNameの対応するインスタンスと一致するコミュニティストリングを使用して送信することができるに搬送エンドポイントを指定する。このオブジェクトの値はゼロ長を有する場合、いずれの場合においても、輸送エンドポイントがチェックされていないこのコミュニティ文字列を含むメッセージを認証するときのいずれか、また、通知を生成するとき。
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
If a management request containing a community string that matches the corresponding instance of snmpCommunityName is received on a transport endpoint other than the transport endpoints identified by this object the request is deemed unauthentic.
snmpCommunityNameの対応するインスタンスと一致するコミュニティ文字列を含む管理要求がこのオブジェクト要求によって識別輸送終点以外のトランスポートエンドポイントで受信された場合に不正であると考えられます。
When a notification is to be sent using an entry in
this table, if the destination transport endpoint of
the notification does not match one of the transport
endpoints selected by this object, the notification
is not sent."
DEFVAL { ''H } -- the empty string
::= { snmpCommunityEntry 6 }
snmpCommunityStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row in the
snmpCommunityTable. Conceptual rows having the value
'permanent' need not allow write-access to any
columnar object in the row."
::= { snmpCommunityEntry 7 }
snmpCommunityStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this conceptual row in the snmpCommunityTable.
snmpCommunityStatusのOBJECT-TYPE構文RowStatus MAX-ACCESSリード作成ステータス現在の説明「snmpCommunityTableにおけるこの概念的な列のステータス。
An entry in this table is not qualified for activation
until instances of all corresponding columns have been
initialized, either through default values, or through
Set operations. The snmpCommunityName and
snmpCommunitySecurityName objects must be explicitly set.
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }
-- -- The snmpTargetAddrExtTable --
- - snmpTargetAddrExtTable -
snmpTargetAddrExtTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
SnmpTargetAddrExtEntry OF snmpTargetAddrExtTable OBJECT-TYPE構文配列
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of mask and maximum message size (mms) values
associated with the snmpTargetAddrTable.
The snmpTargetAddrExtTable augments the
snmpTargetAddrTable with a transport address mask value
and a maximum message size value. The transport address
mask allows entries in the snmpTargetAddrTable to define
a set of addresses instead of just a single address.
The maximum message size value allows the maximum
message size of another SNMP entity to be configured for
use in SNMPv1 (and SNMPv2c) transactions, where the
message format does not specify a maximum message size."
::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
}
snmpTargetAddrTMask OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..255)) MAX-ACCESS read-create STATUS current DESCRIPTION "The mask value associated with an entry in the snmpTargetAddrTable. The value of this object must have the same length as the corresponding instance of snmpTargetAddrTAddress, or must have length 0. An attempt to set it to any other value will result in an inconsistentValue error.
snmpTargetAddrTMask OBJECT-TYPE構文オクテットSTRING（SIZE（0 255））MAX-ACCESSリード作成ステータス現在の説明「snmpTargetAddrTableのエントリに関連付けられたマスク値。このオブジェクトの値は、対応する同じ長さを有していなければなりませんsnmpTargetAddrTAddressのインスタンス、または長さが0以外の値に設定しようとする試みはinconsistentValueエラーをもたらす必要があります。
The value of this object allows an entry in the
snmpTargetAddrTable to specify multiple addresses.
The mask value is used to select which bits of
a transport address must match bits of the corresponding
instance of snmpTargetAddrTAddress, in order for the transport address to match a particular entry in the
snmpTargetAddrTable. Bits which are 1 in the mask
value indicate bits in the transport address which
must match bits in the snmpTargetAddrTAddress value.
Bits which are 0 in the mask indicate bits in the
transport address which need not match. If the
length of the mask is 0, the mask should be treated
as if all its bits were 1 and its length were equal
to the length of the corresponding value of
snmpTargetAddrTable.
This object may not be modified while the value of the
corresponding instance of snmpTargetAddrRowStatus is
active(1). An attempt to set this object in this case
will result in an inconsistentValue error."
DEFVAL { ''H }
::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (0|484..2147483647)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
in the snmpTargetAddrTable. Note that a value of 0 means
that the maximum message size is unknown."
DEFVAL { 484 }
::= { snmpTargetAddrExtEntry 2 }
-- -- The snmpTrapAddress and snmpTrapCommunity objects are included -- in notifications that are forwarded by a proxy, which were -- originally received as SNMPv1 Trap messages. --
- - snmpTrapAddressとsnmpTrapCommunityオブジェクトが含まれている - たプロキシによって転送された通知に - 元々SNMPv1トラップメッセージとして受け取りました。 -
snmpTrapAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the agent-addr field of a Trap PDU which
is forwarded by a proxy forwarder application using
an SNMP version other than SNMPv1. The value of this
object SHOULD contain the value of the agent-addr field
from the original Trap PDU as generated by an SNMPv1
agent."
::= { snmpCommunityMIBObjects 3 }
snmpTrapCommunity OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The value of the community string field of an SNMPv1
message containing a Trap PDU which is forwarded by a
a proxy forwarder application using an SNMP version
other than SNMPv1. The value of this object SHOULD
contain the value of the community string field from
the original SNMPv1 message containing a Trap PDU as
generated by an SNMPv1 agent. There is no SIZE
constraint specified for this object because RFC 1157
does not impose any explicit limitation on the length
of community strings (their size is constrained
indirectly by the SNMP message size)."
::= { snmpCommunityMIBObjects 4 }
-- Conformance Information **************************************
- 適合情報**************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
-- Compliance statements
- コンプライアンスステートメント
snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB."
snmpCommunityMIBCompliance MODULE-COMPLIANCEステータス現在の説明 "SNMP-COMMUNITY-MIBを実装するSNMPエンジンのための準拠宣言。"
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
OBJECT snmpCommunityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityName MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT snmpCommunityContextEngineID MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECTは、MIN-ACCESS読み取り専用説明は "書く、アクセスは必要でない。" snmpCommunityContextEngineID
OBJECT snmpCommunityContextName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT snmpCommunityTransportTag MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT snmpCommunityStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStorageType MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
OBJECT snmpCommunityStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStatus MIN-ACCESS読み取り専用説明 "書き込みアクセスが必要とされていません。"
::= { snmpCommunityMIBCompliances 1 }
snmpProxyTrapForwardCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
contain a proxy forwarding application which is
capable of forwarding SNMPv1 traps using SNMPv2c
or SNMPv3."
MODULE -- this module
MANDATORY-GROUPS { snmpProxyTrapForwardGroup }
::= { snmpCommunityMIBCompliances 2 }
snmpCommunityMIBFullCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP-COMMUNITY-MIB with full read-create access."
snmpCommunityMIBFullCompliance MODULE-COMPLIANCEステータス現在の説明「完全なリード作成アクセスしてSNMP-COMMUNITY-MIBを実装するSNMPエンジンのための準拠宣言。」
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
::= { snmpCommunityMIBCompliances 3 }
snmpCommunityTableGroup OBJECT-GROUP
OBJECTS {
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType, snmpCommunityStatus,
snmpTargetAddrTMask,
snmpTargetAddrMMS
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 }
snmpProxyTrapForwardGroup OBJECT-GROUP
OBJECTS {
snmpTrapAddress,
snmpTrapCommunity
}
STATUS current
DESCRIPTION
"Objects which are used by proxy forwarding applications
when translating traps between SNMP versions. These are
used to preserve SNMPv1-specific information when
translating to SNMPv2c or SNMPv3."
::= { snmpCommunityMIBGroups 3 }
END
終わり
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
This document is the result of the efforts of the SNMPv3 Working Group. The design of the SNMP-COMMUNITY-MIB incorporates work done by the authors of SNMPv2*:
この文書では、SNMPv3の作業部会の努力の結果です。 SNMP-COMMUNITY-MIBのデザインは、SNMPv2の*の著者によってなされた仕事が組み込まれています。
Jeff Case (SNMP Research, Inc.) David Harrington (Enterasys Networks) David Levi (Nortel Networks) Brian O'Keefe (Hewlett Packard) Jon Saperia (IronBridge Networks, Inc.) Steve Waldbusser (International Network Services)
ジェフケース（SNMPリサーチ社）デヴィッド・ハリントン（エンテラシス・ネットワーク）デビッド・レビ（ノーテルネットワーク）ブライアン・オキーフ（ヒューレット・パッカード）ジョンSaperia（アイアンブリッジネットワークス社）スティーブWaldbusser（国際ネットワークサービス）
Although SNMPv1 and SNMPv2 do not provide any security, allowing community names to be mapped into securityName/contextName provides the ability to use view-based access control to limit the access of unsecured SNMPv1 and SNMPv2 operations. In fact, it is important for network administrators to make use of this capability in order to avoid unauthorized access to MIB data that would otherwise be secure.
SNMPv1とSNMPv2のはどのようなセキュリティを提供していませんが、コミュニティ名はセキュリティ名/のcontextName内にマッピングできるようにすることは、無担保SNMPv1とSNMPv2の操作のアクセスを制限するビューベースのアクセス制御を使用する能力を提供します。実際には、ネットワーク管理者は、そうでない場合は、セキュアだろうMIBデータへの不正アクセスを防止するために、この機能を活用することは重要です。
When a proxy implementation translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security. For example, an SNMPv3 message received using authentication and privacy which is subsequently forwarded using SNMPv1 will lose the security benefits of using authentication and privacy (also known as confidentiality). Careful configuration of proxies is required to address such situations. One approach to deal with such situations might be to use an encrypted tunnel.
プロキシ実装がSNMPv1の（またはSNMPv2cの）とSNMPv3の間でメッセージを変換するとき、セキュリティの損失があってもよいです。たとえば、SNMPv3のメッセージを認証し、その後、認証およびプライバシー（も機密として知られている）を使用してのセキュリティ上の利点を失うことになるのSNMPv1を使用して転送され、プライバシーを使用して受信しました。プロキシの慎重な設定は、このような状況に対処するために必要とされます。このような状況に対処するための一つのアプローチは、暗号化されたトンネルを使用するかもしれません。
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:
読み書きおよび/またはリード作成のMAX-ACCESS句でこのMIBモジュールで定義された管理オブジェクトの数があります。そのようなオブジェクトは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響を与える可能性があります。これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です：
- The snmpCommunityTable allows creation and deletion of community strings, which is potentially a serious security hole. Access to this table should be greatly restricted, preferably by only allowing write access using SNMPv3 VACM and USM, with authentication and privacy.
- snmpCommunityTableは、潜在的に深刻なセキュリティホールである、コミュニティストリングの作成と削除することができます。このテーブルへのアクセスは非常に好ましいだけで認証とプライバシーで、SNMPv3のVACMとUSMを使用して書き込みアクセスを可能にすることにより、制限する必要があります。
- The snmpTargetAddrExtTable contains write-able objects which may also be considered sensitive, and so access to it should be restricted as well.
- snmpTargetAddrExtTableも敏感と考えることができる、そしてそれへのアクセスが同様に制限されるべき書き込み可能オブジェクトが含まれています。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュールで読み取り可能なオブジェクトの一部（すなわち、アクセス可能ではない以外MAX-ACCESS持つオブジェクト）は、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。 GETおよび/またはこれらのオブジェクトへのアクセスを通知し、おそらくSNMPを通してネットワークの上にそれらを送信する場合でも、これらのオブジェクトの値を暗号化するためにも、制御することが重要です。これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です：
- The snmpCommunityTable has the potential to expose community strings which provide access to more information than that which is available using the usual 'public' community string. For this reason, a security administrator may wish to limit accessibility to objects in the snmpCommunityTable, and in particular, to make it inaccessible when using the 'public' community string.
- snmpCommunityTableは、通常の「パブリック」コミュニティストリングを使用して利用可能であるものよりもより多くの情報へのアクセスを提供するコミュニティストリングを公開する可能性を秘めています。このため、セキュリティ管理者は、snmpCommunityTable内のオブジェクトへのアクセスを制限し、特に、「国民のコミュニティストリングを使用しているとき、それはアクセスできないようしたいことがあります。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3の前のSNMPバージョンは十分なセキュリティを含んでいませんでした。ネットワーク自体が（IPSecを使用することにより、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）この内のオブジェクトが存在しませんMIBモジュール。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
実装がSNMPv3フレームワークで提供するようにセキュリティ機能を考えることが推奨される（認証とプライバシーのために）SNMPv3の暗号化メカニズムの完全なサポートを含む、（[RFC3410]セクション8を参照）。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はお勧めしません。代わりに、SNMPv3を展開すると、暗号化セキュリティを有効にすることをお勧めします。このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が適切にのみプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/オペレータ責任実際にGETまたはSET（変化への正当な権利を有することです/）/削除、それらを作成します。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
"TCP / IPベースのインターネットのための経営情報の構造と識別" [RFC1155]ローズ、M.、およびK. McCloghrie、STD 16、RFC 1155、1990月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[RFC1157]ケース、J.、ヒョードル、M.、Schoffstall、M.とC.デーヴィン、 "簡易ネットワーク管理プロトコル（SNMP）"、STD 15、RFC 1157、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212]ローズ、M.、およびK. McCloghrie、編、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[RFC1303] McCloghrie, K. and M. Rose, "A Convention for Describing SNMP-based Agents", RFC 1303, February 1992.
[RFC1303] McCloghrie、K.とM.ローズ、 "SNMPベースのエージェントの記述のための条約"、RFC 1303、1992年2月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、RFC 2578 "管理情報バージョン2（SMIv2）の構造"、STD 58、1999年4月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、 "SMIv2のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、PresuhnとR.とB. Wijnen、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3412] 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.
[RFC3412]ケース、J.、ハリントン、D.、PresuhnとR.とB. Wijnen、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、STD 62、RFC 3412、2002年12月。
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413]レビ、D.、マイヤー、P.とB.スチュワート、 "簡易ネットワーク管理プロトコル（SNMP）アプリケーション"、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3414, December 2002.
[RFC3414]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMP）のバージョン3のために"、STD 62、RFC 3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、STD 62、RFC 3415、2002年12月。
[RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R.、エド。、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv2の）のためのプロトコル操作のバージョン2"。
[RFC3417] Presuhn, R., Ed., "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、エド。、STD 62、RFC 3417、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のためのマッピングを輸送します"。
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for Version 2 of the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R.、エド。、 "簡易ネットワーク管理プロトコル（SNMP）のバージョン2のための管理情報ベース（MIB）"、STD 62、RFC 3418、2002年12月。
[ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987).
[ASN1]情報処理システム - オープンシステムインターコネクション - 抽象構文記法1（ASN.1）、国際標準化機構の仕様。国際標準8824、（12月、1987）。
[RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework", RFC 1908, January 1996.
[RFC1908]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、 "バージョン1およびインターネット標準ネットワーク管理フレームワークのバージョン2の間の共存"、RFC 1908、1996年1月。
[RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1 within a bilingual SNMP agent", RFC 2089, January 1997.
[RFC2089]レビ、D.、およびB. Wijnenの、 "バイリンガルSNMPエージェント内のSNMPv1にマッピングSNMPv2の"、RFC 2089、1997年1月。
[RFC2576] 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.
[RFC2576]フライ、R.、レヴィ、D.、Routhier、S.およびB. Wijnenの、 "バージョン1、バージョン2、およびインターネット標準ネットワーク管理フレームワークのバージョン3の間の共存"、RFC 2576、2000年3月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.とB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
Appendix A. Change Log
付録A.変更ログ
A.1. Changes From
A.1。からの変更点
Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576.
以下のセクション番号は、いくつかのセクション番号は、RFC 2576以降に変更されたRFC 2576から古いセクション番号を参照してください。
- Added text to abstract about conversion of MIBs from SMIv1 to SMIv2.
- でSMIv1からSMIv2のへのMIBの変換について抽象的にテキストを追加しました。
- Added note at end of section 1.3 that all discussion of SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3.
- SNMPv2のPDUタイプとプロトコル操作の全ての議論はSNMPv2cのおよびSNMPv3の両方に適用され、1.3節の末尾にメモを追加しました。
- Added text at end of section 1.4 to clarify that there is no such thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2 PDU types and protocol operations.
- SNMPv3のはただのSNMPv2 PDUタイプとプロトコル動作を使用して「MIBデータへのSNMPv3アクセス」のようなものが存在しないことを明確にするためにセクション1.4の最後にテキストを追加しました。
- Moved section 1.4 to the beginning of section 4.
- セクション4の先頭にセクション1.4を移動しました。
- Changed "MUST" to "SHOULD" in item (3) of the first list in Section 2.1.1 to since unconstrained INTEGER is not actually illegal in SMIv2.
- 変更を「SHOULD」（3）号に拘束されない整数実際SMIv2の違法ではないために、セクション2.1.1に最初のリストの「MUST」。
- Changed "SHOULD" to "MUST" in item (13) of the first list in Section 2.1.1 to clarify that collecting related objects into groups is required when translating a MIB module from SMIv1 to SMIv2.
- 変更でSMIv1からSMIv2のにMIBモジュールを変換するとき、セクション2.1.1における最初のリストのアイテム（13）のグループに関連するオブジェクトを収集が必要であることを明確にする「MUST」から「べきです」。
- Re-organized bullets in section 2.1.1 to improve clarity.
- 再編成明瞭度を改善するためのセクション2.1.1で箇条書き。
- Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3 since those updates are indeed required when translating a capabilities statement from the language defined by RFC 1303 into SMIv2.
- SMIv2のにRFC 1303で定義された言語からの機能文を翻訳する際に、2.3節の項目（1）及び（2）にこれらの更新が実際に必要とされる「MUST」に「すべきである」以降に変更。
- In the second bullet of the last part of Section 3 listing the SNMPv2 notification parameters, clarified that the snmpTrapOID parameter refers to the value portion (not the name portion) of the second variable-binding, and changed the wording in the text under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the snmpTrapOID value" to emphasize this point.
- SNMPv2の通知パラメータをリストする第3の最後の部分の第二弾では、snmpTrapOIDパラメータが第二の可変結合の値部分（いない名の部分）を指すことが明らかと弾丸の下のテキストで表現を変更（1）「snmpTrapOID」から第3.2項の「snmpTrapOID値」にこの点を強調します。
- In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-bindings do not include sysUpTime.0 an snmpTrapOID.0.
- 弾丸（6）セクション3.2のSNMPv2変数バインディングがsysUpTime.0 snmpTrapOID.0を含まないことを強調しました。
- In Section 4.2 clarified that the 'Upstream Version' refers to the version used between the command generator or notification receiver and the proxy, and the 'Downstream Version' refers to the version used between the proxy and the command responder or notification originator. RFC 2576 neglected to mention the notification receiver and notification originator.
- セクション4.2で「上流バージョン」コマンド生成または通知の受信機とプロキシの間で使用されるバージョンを意味することが明らかと「下流版」プロキシとコマンド応答又は通知元の間で使用されるバージョンを意味します。 RFC 2576は、通知受信と通知発信元を言及するのを怠っ。
- In Section 4.1.2 added text noting that SNMPv1 access to MIB data SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and re-worded final paragraph to note that the sub-sections that follow are concerned solely with command responders that use SNMPv2 access to MIB data while processing an SNMPv1 request.
- 4.1.2で追加されたテキストは、続くサブセクションでは、もっぱらのSNMPv2アクセスを使用して、コマンド応答と懸念していることに注意することはSNMPv2cのか、SNMPv3のメッセージを処理するときにMIBデータへのSNMPv1アクセスは使用すべきではないことを指摘し、再言葉で表現最後の段落MIBデータへのSNMPv1要求の処理中に。
- Re-worded first bullet, section 4.2.1, to make it more readable.
- それは、より読みやすくするために再文言最初の箇条書き、セクション4.2.1、。
- In Section 4.2.1 clarified that the error-index field must be set to zero in a translated GetResponse-PDU with an error-status of 'tooBig' and made explicit the rationale for retrying a GetBulkRequest-PDU only once.
- セクション4.2.1でエラーインデックスフィールドが「がtooBig」のエラーステータスと翻訳のGetResponse-PDUにゼロに設定され、一度だけ再試行GetBulkRequest-PDUのための理論的根拠を明示しなければならないことを明らかにしました。
- Added text to the Deployment Hint in Section 4.2.2 to clarify that different principals should be used for SNMPv1 requests and SNMPv2/v3c requests if for SNMPv1 requests a principal for which Counter64 objects are not-in-view is used.
- のSNMPv1がCounter64のオブジェクトがないインビューが使用されている対応する主体を要求するための場合、別のプリンシパルがSNMPv1の要求とSNMPv2 / V3C要求に使用されるべきであることを明確にするために、セクション4.2.2に展開ヒントにテキストを追加しました。
- In Section 5.2.1 clarified that the securityName value and the scopedPDU's contextSnmpEngineID and contextName values come from the selected entry in the snmpCommunityTable. Also clarified how maxSizeResponseScopedPDU is determined and that securityStateReference must contain the community string of the original request.
- セクション5.2.1でのsecurityName値とされたscopedPDUのcontextSnmpEngineIDとのcontextName値はsnmpCommunityTableで選択したエントリから来ることを明らかにしました。またmaxSizeResponseScopedPDUが決定され、そのsecurityStateReferenceは、元の要求のコミュニティ文字列が含まれている必要がありますどのように明らかにしました。
- Added Section 5.2.4 on Proxy Forwarding Of Requests.
- 要求のプロキシ転送に5.2.4項を追加しました。
- In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored whenever its use is not explicitly called for.
- セクション5.3でsnmpTargetAddrTMaskは、その使用が明示的に呼び出されていない時はいつでも無視されることを明らかにしました。
- Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and added a copyright notice to the DESCRIPTION clause of the MIB module's MODULE-IDENTITY invocation.
- LAST-UPDATED、CONTACT-INFO、およびREVISION句を更新し、MIBモジュールのMODULE-IDENTITY呼び出しの説明節に著作権表示を追加しました。
- Added text to DESCRIPTION of snmpCommunityName and snmpTrapCommunity to clarify why the object has no size restriction.
- snmpCommunityNameとsnmpTrapCommunityの説明を追加したテキストオブジェクトはサイズ制限がありません理由を明確にします。
- Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document.
- 文書の残りの部分と、それは一貫性を保つためにSNMPコミュニティ交通タグの記述を更新しました。
- Updated the description of 'snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown.
- 0の値は、最大メッセージサイズが不明であることを意味することを明確にするために「snmpTargetAddrMMS」の説明を更新しました。
- Changed the name of 'snmpCommunityGroup' to 'snmpCommunityTableGroup' in order to resolve a name conflict with the SNMPv2-MIB.
- SNMPv2の-MIBとの名前の競合を解決するために「snmpCommunityTableGroup」から「snmpCommunityGroup」の名前を変更しました。
- Added compliance statement to SNMP-COMMUNITY-MIB for full read-create compliance.
- フルリード作成し、コンプライアンスのためのSNMP-COMMUNITY-MIBに準拠宣言を追加しました。
- Divided references into Normative References and Informative Reference and updated them to point to current documents.
- 引用規格及び参考文献に参照を分割し、現在のドキュメントを指すように、それらを更新しました。
- Inserted current year into all copyright notices.
- すべての著作権表示に現在の年挿入。
- Corrected various typographical and grammatical errors.
- 様々な誤字や文法の誤りを修正しました。
A.2. Changes Between and
A.2。間の変更
- Editorial changes to comply with current RFC requirements.
- 現在のRFC要件に準拠するために編集上の変更。
- Added/updated copyright statements.
- /更新著作権のステートメントを追加しました。
- Added Intellectual Property section.
- 追加された知的財産セクション。
- Replaced old introduction with complete new introduction/overview.
- 完全に新しい紹介/概要と古い導入を取り替えました。
- Added content for the Security Considerations Section.
- セキュリティの考慮セクションを追加しましたコンテンツ。
- Updated References to current documents.
- 現在のドキュメントへの参照を更新しました。
- Updated text to use current SNMP terminology.
- 現在のSNMPの用語を使用するように更新されるテキスト。
- Added coexistence for/with SNMPv3.
- 追加しました共存/のためのSNMPv3を持ちます。
- Added description for SNMPv1 and SNMPv2c Message Processing Models and SNMPv1 and SNMPv2c Community-based Security Models.
- SNMPv1およびSNMPv2cのメッセージ処理モデルとのSNMPv1およびSNMPv2cコミュニティベースのセキュリティモデルを追加しました説明。
- Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings can be mapped into the SNMP Version Independent parameters which can then be used for access control using the standard SNMPv3 View-based Access Control Model and the snmpVacmMIB.
- SNMPv1とSNMPv2のコミュニティストリングは、その後、標準のSNMPv3ビューベースアクセス制御モデルとsnmpVacmMIBを用いたアクセス制御のために使用することができるSNMPのバージョンに依存しないパラメータにマッピングすることができるように追加されたsnmpCommunityMIB。
- Added two MIB objects such that when an SNMPv1 notification (trap) must be converted into an SNMPv2 notification we add those two objects in order to preserve information about the address and community of the originating SNMPv1 agent.
- そのようなSNMPv1の通知（トラップ）は、我々は、発信SNMPv1エージェントのアドレスとコミュニティに関する情報を保存するために、これら2つのオブジェクトを追加するSNMPv2通知に変換しなければならないとき、二つのMIBオブジェクトを追加しました。
- Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine.
- 多言語SNMPエンジン内のSNMPv1マッピングにRFC 2089のSNMPv2から（拡張）を含んでいました。
- Use keywords from RFC 2119 to describe requirements for compliance.
- RFC 2119から使用のキーワードは、コンプライアンスの要件を説明します。
- Changed/added some rules for converting a MIB module from SMIv1 to SMIv2.
- 変更/ SMIv2のにでSMIv1からMIBモジュールを変換するためのいくつかのルールを追加しました。
- Extended and improved the description of Proxy Forwarder behaviour when multiple SNMP versions are involved.
- 拡張され、複数のSNMPバージョンが含まれる場合、プロキシフォワーダ動作の説明を改善しました。
Editors' Addresses
エディタのアドレス
Rob Frye Vibrant Solutions 2711 Prosperity Ave Fairfax, Virginia 22031 U.S.A.
ロブ・フライ鮮やかなソリューション2711繁栄アベニューフェアファックス、バージニア州22031 U.S.A.
Phone: +1 703 270 2000 EMail: rfrye@vibrant-1.com
電話：+1 703 270 2000 Eメール：rfrye@vibrant-1.com
David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A.
デビッド・B・レビNortel Networksの3505 Kesterwoodドライブノックスビル、TN 37918 U.S.A.
Phone: +1 865 686 0432 EMail: dlevi@nortelnetworks.com
電話：+1 865 686 0432 Eメール：dlevi@nortelnetworks.com
Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 U.S.A.
ショーンA. Routhierウインドリバーシステムズ社500ウインドリバーウェイアラメダ、CA 94501 U.S.A.
Phone: + 1 510 749 2095 EMail: sar@epilogue.com
電話：+ 1 510 749 2095 Eメール：sar@epilogue.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
バートWijnenルーセント・テクノロジーショームバーグ33 3461 GLオランダLinschoten
Phone: +31 348 407 775 EMail: bwijnen@lucent.com
電話：+31 348 407 775 Eメール：bwijnen@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。