[要約] RFC 3584は、インターネット標準のネットワーク管理フレームワークのバージョン1、バージョン2、バージョン3の共存に関するガイドラインです。このRFCの目的は、異なるバージョンのフレームワークを効果的に統合し、ネットワーク管理の一貫性と互換性を確保することです。
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
インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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）のバージョン3、インターネット標準ネットワーク管理フレームワーク（SNMPV2）のバージョン2、および元のインターネット標準ネットワーク管理フレームワーク（SNMPV1）。このドキュメントでは、MIBモジュールをSMIV1形式からSMIV2形式に変換する方法についても説明します。このドキュメントは、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間の共存を説明することです。）、および元のインターネット標準ネットワーク管理フレームワーク（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.
- 多言語ネットワークでSNMPのさまざまなバージョンをサポートするエンティティ間の共存へのアプローチについては、セクション4に記録されています。このセクションでは、多言語実装でのプロトコル操作の処理と、代理実装の動作について説明します。
- 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]に適応させるメカニズムを提供するSNMPV1メッセージ処理モデルとコミュニティベースのセキュリティモデルは、セクション5に記載されています（このセクションでは、SNMPV2Cメッセージ処理モデルとコミュニティについても説明します。 - ベースのセキュリティモデル）。
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、RFC 1157 [RFC1157]は、管理されたオブジェクトへのネットワークアクセスに使用されるプロトコルであるSimple Network Management Protocol（SNMPV1）を定義します。
- 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、RFC 1155 [RFC1155]は、管理情報の構造（SMIV1）を定義します。
- STD 16, RFC 1212 [RFC1212] which defines a more concise description mechanism, which is wholly consistent with the SMIv1.
- STD 16、RFC 1212 [RFC1212]は、SMIV1と完全に一致する、より簡潔な説明メカニズムを定義します。
- RFC 1215 [RFC1215] which defines a convention for defining Traps for use with the SMIv1.
- SMIV1で使用するトラップを定義するための規則を定義するRFC 1215 [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].
- STD 58、RFC 2578は、管理情報の構造（SMIV2）[RFC2578]のバージョン2を定義しています。
- STD 58, RFC 2579 which defines common MIB "Textual Conventions" [RFC2579].
- STD 58、RFC 2579は、一般的なMIB「テキストコンベンション」[RFC2579]を定義します。
- STD 58, RFC 2580 which defines Conformance Statements and requirements for defining agent and manager capabilities [RFC2580].
- STD 58、RFC 2580は、エージェントとマネージャーの機能を定義するための適合ステートメントと要件を定義します[RFC2580]。
- STD 62, RFC 3416 which defines the Protocol Operations used in processing [RFC3416].
- STD 62、RFC 3416は、処理に使用されるプロトコル操作[RFC3416]を定義します。
- 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].
- STD 62、RFC 3418は、SNMPエンティティのいくつかの基本的な共通機能を監視および制御するための基本的な管理情報ベースを定義しています[RFC3418]。
Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580).
このドキュメント全体で使用されるSMIV2は、上記の最初の3つのドキュメント（RFCS 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].
- STD 62、RFC 3411は、SNMP管理フレームワークを記述するためのアーキテクチャを定義します[RFC3411]。
- STD 62, RFC 3412 which defines Message Processing and Dispatching [RFC3412].
- STD 62、RFC 3412は、メッセージ処理とディスパッチを定義します[RFC3412]。
- STD 62, RFC 3413 which defines various SNMP Applications [RFC3413].
- さまざまなSNMPアプリケーションを定義するSTD 62、RFC 3413 [RFC3413]。
- STD 62, RFC 3414 which defines the User-based Security Model (USM), providing for both Authenticated and Private (encrypted) SNMP messages [RFC3414].
- STD 62、RFC 3414は、ユーザーベースのセキュリティモデル（USM）を定義し、認証されたプライベート（暗号化）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].
- STD 62、RFC 3415は、ビューベースのアクセス制御モデル（VACM）を定義し、ユーザーごとに異なるMIBオブジェクトへのアクセスを制限する機能を提供します[RFC3415]。
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は、RFCS 3416から3418のSNMPV2定義と、上記の2578から2580のSMIV2定義も使用しています。SNMPV2 PDUタイプとプロトコル操作を指すこのドキュメント全体のテキストは、SNMPV2CとSNMPV3の両方に適用されることに注意してください。
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モジュール、コンプライアンスステートメント、および機能ステートメントの3つの領域を検討します。
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 PDUSを使用するプロトコルバージョンで引き続き使用される場合があります。ただし、SMIV1 MIBモジュールがSMIV2に準拠するためには、次の変更を加えなければなりません。
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) インポートステートメントは、RFC1155-SMIおよびRFC-1212ではなく、SNMPV2-SMIを参照する必要があります。
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any IMPORTs statement.
(2) モジュールアイデンティティマクロは、インポートステートメントの直後に呼び出される必要があります。
(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) Counterの構文句句の任意のオブジェクトの場合、オブジェクトはその構文節の値を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) 構文節値のゲージを持つオブジェクトの場合、オブジェクトは、その構文節の値を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) すべてのオブジェクトについて、アクセス条項は最大アクセス句に置き換える必要があります。Max-Access句の値は、オブジェクトの最大アクセスレベルとして「プロトコル」を他の値にしない限り、アクセス条項の値と同じでなければなりません。特に、プロトコルセット操作によってインスタンスを明示的に作成できるオブジェクトタイプには、「読み取り」の最大アクセス条項があります。アクセス条項の値が「書き込み専用」の場合、最大アクセス句の値は「読み取り」でなければならず、説明条項は、このオブジェクトを読み取ると実装固有の結果が得られることに注意するものとします。SMIV1では、アクセス条項は最小限の必要なアクセスを指定し、SMIV2では最大アクセス条項は最大許可アクセスを指定していることに注意してください。これは、アクセス条項を最大アクセス句に変換するときに考慮する必要があります。
(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) すべてのオブジェクトの場合、ステータス節の値が「必須」または「オプション」の場合、そのようなオブジェクトの現在の使用に応じて、値を「電流」、「非推奨」、または「時代遅れ」に置き換える必要があります。
(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) インデックス句がない概念の行に対応するオブジェクトの場合、オブジェクトには、インデックス句または定義された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.
(9) 任意のインデックス句に、NetworkAddressの構文を持つオブジェクトへの参照が含まれている場合、構文がNetworkAddressであるオブジェクトの直前のこのインデックス句に新しいオブジェクトを作成し、配置する必要があります。この新しいオブジェクトには、整数の構文が必要であり、アクセス不可能でなければならず、その値は常に1でなければなりません。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の構文を持つオブジェクトの場合、構文はiPaddressに変更する必要があります。新しいMIBドキュメントでのNetworkAddressの使用は強く落胆していることに注意してください（実際、NetworkAddressを定義しないSMIV2を使用して新しいMIBドキュメントを作成する必要があります）。
(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識別子を定義するために、一連の新しい管理割り当て（オブジェクト識別子）を定義する必要があります。
(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には、すべてのオブジェクトタイプが少なくとも1つのオブジェクトグループのメンバーになる必要があることに注意してください。
(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）概念的行にすぐに従属するかのようにインスタンスされている非著名なオブジェクトの場合、そのオブジェクトのステータス節の値は「時代遅れ」に変更する必要があります。
(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）概念テーブルにすぐに従属しない概念的行オブジェクトの場合、そのオブジェクトのステータス節（およびすべての下位オブジェクト）の値を「時代遅れ」に変更する必要があります。
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) 対応する整数には範囲制限がない整数値の構文節を持つオブジェクトの場合（つまり、整数には、その値とその値に対する下限と上限の割り当ての定義されたセットもありません。）、オブジェクトには、構文節の値が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) 対応するオクテット文字列にサイズの制限がない（つまり、オクテット文字列には、その長さの下部と上限の割り当てがない）を持たない、文字列値の構文句を持つオブジェクトの場合、オブジェクトを定義する必要があります。
(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) ある種のユニットでの測定を表すオブジェクトの場合、そのオブジェクトの定義に単位句を追加する必要があります。
(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句を使用する必要があります拡張機能である概念的行に対応します。
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に準拠するように変更された場合、トラップタイプのマクロの各発生は、通知型マクロの対応する呼び出しに変更する必要があります。、および代わりに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) 適切な値で、ステータス条項を追加する必要があります。通常、値は「現在」でなければなりませんが、必要に応じて「非推奨」または「時代遅れ」が使用される場合があります。
(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) 通知型マクロの呼び出しの値は、整数ではなくオブジェクト識別子であり、それに応じて変更する必要があります。具体的には、エンタープライズ句の値が「SNMP」ではない場合、呼び出しの値は2つのサブ識別子で拡張されたエンタープライズ句の値となります。トラップタイプの呼び出しの。Enterprise句の値が「SNMP」の場合、通知型マクロの呼び出しの値は、このドキュメントのセクション3.1で説明されているのと同じ方法でマッピングされるものとします。
(6) A DESCRIPTION clause MUST be added, if not already present.
(6) まだ存在していない場合は、説明条項を追加する必要があります。
(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つ以上の通知グループを定義する必要があり、関連する通知をそれらのグループに収集する必要があります。SMIV2には、すべての通知タイプが少なくとも1つの通知グループのメンバーであることが必要であることに注意してください。
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.
「標準トラック」である情報モジュールの場合、モジュールコンプライアンスマクロと関連するオブジェクトグループおよび/または通知グループマクロの対応する呼び出しは、情報モジュール（またはコンパニオン情報モジュール）に含める必要があります。コンプライアンスに関連する情報モジュール内の解説テキストを削除する必要があります。通常、この編集は、情報モジュールがレビューを受けるときに発生する可能性があります。
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ドキュメント（たとえば、EnterpriseMIB）にはモジュールコンプライアンスステートメントが必要ではないことに注意してください。。
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]は、モジュールコンフォーマンスマクロを使用して、1つ以上のMIBモジュールに関するエージェントの機能を記述します。
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) Macro Nameエージェントキャピタリティは、モジュールコンフォーマンスの代わりに使用する必要があります。
(2) The STATUS clause MUST be added, with a value of 'current'.
(2) 「現在」の値でステータス条項を追加する必要があります。
(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) Creation-Requires節のすべての発生は、必要に応じて省略するか、セマンティクスが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モジュールで定義されたオブジェクト識別子サブツリーへの参照に遭遇すると、すべての葉はすべて葉ですサブツリーに従属し、必須のステータス条項値を持つオブジェクトは、含まれているとみなされます。（この方法は、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.
- プロキシが、通知パラメーターの1つの形式を必要とする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).
- 一般的なトラップパラメーター（整数）。
- A specific-trap parameter (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パラメーター（タイムティック）。これは、SNMPV2-TRAP-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パラメーター（オブジェクト識別子）。これは、SNMPV2-TRAP-PDUまたはInformRequest-PDUの2番目の変数バインディングに表示され、その変数バインディングの値部分に等しくなります（名前と値の両方がオブジェクト識別子であるため、名前部分ではありません）。
- 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-TRAP-PDUまたはInformRequest-PDUの最初の2つの可変バインディングを除くすべてを指します。
The following procedure describes how to translate SNMPv1 notification parameters into SNMPv2 notification parameters:
次の手順では、SNMPV1通知パラメーターをSNMPV2通知パラメーターに翻訳する方法について説明します。
(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.
(2) SNMPV1ジェネリックトラップパラメーターが「EnterprisSpicific（6）」の場合、SNMPV2 SNMPTRAPOIDパラメーターは、SNMPV1エンタープライズパラメーターと2つの追加のサブアイデンティア、「0」、およびSNMPV1特異的TRAPパラメーターの連結となります。
(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]:
(3) Snmpv1 generic-trapパラメーターが「Enterprisespific（6）」でない場合、snmpv2 snmptrapoidパラメーターは、RFC 3418 [RFC3418]のセクション2で定義されているように対応するトラップとするものとします。
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変数バインディングでなければなりません。さらに、受信したトラップを転送するために翻訳がプロキシによって実行されている場合、これら3つの追加の可変バインディングがSNMPV1変数バインディングにまだ存在していない場合、3つの追加の可変バインディングが追加されます。最初の追加変数バインディングの名前部分には、snmptrapaddress.0が含まれ、値にはsnmpv1 agent-addrパラメーターが含まれます。2番目の追加変数バインディングの名前部分には、snmptrapcommunity.0が含まれ、値には、SNMPV1 TRAP-PDUを含む受信したSNMPV1メッセージからのコミュニティストリングフィールドの値を含めるものとします。3番目の追加変数バインディングの名前部分には、snmptrapenterprise.0 [rfc3418]が含まれ、値はsnmpv1エンタープライズパラメーターでなければなりません。
The following procedure describes how to translate SNMPv2 notification parameters into SNMPv1 notification parameters:
次の手順では、SNMPV2通知パラメーターをSNMPV1通知パラメーターに翻訳する方法について説明します。
(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].
- SNMPV2 SNMPTRAPOIDパラメーターがRFC 3418 [RFC3418]で定義されている標準トラップの1つである場合、SNMPV2 Enterpriseパラメーターは、名前がSNMPTRAPENTERPRISE。可変バインディングが存在します。それが存在しない場合、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:
- SNMPV2 SNMPTRAPOIDパラメーターがRFC 3418 [RFC3418]で定義されている標準トラップの1つではない場合、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
- snmptrapoid値の次の次のサブアイデンティエがゼロの場合、Snmpv1エンタープライズは、最後の2つのサブ識別子が除去されたSnmpv2 snmptrapoid値であり、それ以外の場合は除去されます。
- 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:
(3) SNMPV2 SNMPTRAPOIDパラメーターがRFC 3418 [RFC3418]で定義されている標準トラップの1つである場合、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.
(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.
(4) SNMPV2 SNMPTRAPOIDパラメーターがRFC 3418 [RFC3418]で定義されている標準トラップの1つである場合、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を含む可変バインディングは含まれていないことに注意してください）。ただし、SNMPV2変数バインディングにタイプがカウンター64であるオブジェクトが含まれている場合、SNMPV1通知パラメーターへの翻訳は実行できないことに注意してください。この場合、通知は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).
SNMPV1 MIBデータへのアクセスは、SNMPV1エラーステータス値を生成し、例外コードを生成することもCounter64データ型も使用することはなく、通知を生成するためにSNMPV1形式のパラメーターを提供する場合があります。また、MIBデータへのSNMPV1アクセスは、実際には読み取りエラーが生成されないことに注意してください（読み取りエラーが予想される状況では、NOSUCHNAMEエラーは常に発生します）。
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.
SNMPV2 MIBデータへのアクセスは、SNMPV2エラーステータス値を生成し、例外コードを生成し、Counter64データ型を使用し、通知を生成するためのSNMPV2形式のパラメーターを提供する場合があります。MIBデータへのSNMPV2アクセスは、readonly、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データへのすべてのアクセスをMIBデータへのSNMPV2アクセスとして実装し、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タイプとプロトコル操作を使用しているため、このドキュメントでは「SNMPV3アクセス」については「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に変更するだけで行われ、非再配置と最大修復値を無視し、エラーステータスとエラーインデックスをゼロに設定します。
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:
コマンドレスポンダーは、MIBデータへのSNMPV1とSNMPV2アクセスの両方を処理できる必要があります。これに対処するには、3つの側面があります。コマンドレスポンダーは次のことをしなければなりません。
- Deal correctly with SNMPv2 access to MIB data that returns a Counter64 value while processing an SNMPv1 message,
- SNMPV1メッセージを処理しながらCounter64値を返す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.
- MAP SNMPV2エラーコードは、SNMPV1メッセージを処理するときにSNMPV2データへのMIBデータへのアクセスからSNMPV1エラーコードに返されました。
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.
SNMPV1エラーコードは、プロキシ転送の場合を除き、SNMPV2CまたはSNMPV3メッセージを処理する場合、変更なしでは使用しないでください。また、SNMPV2CまたはSNMPV3メッセージを処理する場合、SNMPV1 MIBデータへのアクセスは使用しないでください。プロキシ転送の場合、後方互換性の場合、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と互換性のない1つの新しい構文を定義します。この構文は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メッセージバージョンを使用して受信したリクエストへの応答で、Counter64値を含む変数バインディングを返すことはできないことです。
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:
多言語コマンドレスポンダーは、SNMPV1メッセージを処理するときに、タイプがカウンター64であるオブジェクトインスタンスが暗黙的にビューから除外されるというアプローチを取るものとします。それで：
- 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.
- snmpv1 getRequest-PDUを受け取ったときに、名前フィールドが型counter64のオブジェクトインスタンスを指している変数バインディングを含む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の構文を含むすべてのオブジェクトインスタンスをスキップし、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が増加するものとします。
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リクエストを受信した場合、コマンドレスポンダーは、SNMPV2アクセスを使用してMIBデータへの例外値を返した変数バインディングを確認し、これらの例外値を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.
- getNextre -equestの場合、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.
SNMPV2アクセスによってMIBデータへのアクセスによって生成されたNosuchobjectまたはNosuchinstance例外は、要求されたオブジェクトインスタンスを返すことができないことを示しています。この条件のsnmpv1エラーコードはnosuchnameであるため、応答PDUのエラーステータスフィールドはnosuchnameに設定するものとします。また、ERROR-Indexフィールドは、例外が発生した変数バインディングのインデックスに設定されます（複数の場合、使用される実装決定です）、および元のバインディングリストは元のバインディングリストです。応答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に設定するものとします。また、ERROR-Indexフィールドは、例外が発生した変数バインディングのインデックスに設定されます（複数の場合、使用される実装決定です）、および元のバインディングリストは元のバインディングリストです。応答PDUでリクエストを返します。
When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data.
SNMPV1 GetRequestを処理する場合、SNMPV2アクセスをMIBデータに使用する場合は、次の手順に従う必要があります。
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".
- エラーステータスは、セクション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の変数バインディングリストは、元のリクエストで受信された変数バインディングリストとまったく同じように作成するものとします。
(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:
(2) エラーステータスがnoerrorの場合、変数バインディングは、snmpv2例外（nosuchobjectまたはnosuchinstance）またはsnmpv1（counter64）に不明なsnmpv2構文をチェックするものとします。そのような可変バインディングがある場合、それらの可変バインディングの1つが選択されるものとします（選択した実装の選択肢です）。
- 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,
- エラーステータスはノーエラーに設定されます、
- 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 getNextre -equestを処理する場合、MIBデータへのSNMPV2アクセスがリクエストの処理の一部として使用される場合、次の手順に従う必要があります。MIBデータへの繰り返しアクセスがある場合があり、リクエスト内の各オブジェクトに辞書的に辞書的に従う最初のオブジェクトを見つけようとします。これは実装固有です。これらの手順には、SNMPV2アクセスをMIBデータに使用する場合に返されるデータに対してのみ従います。MIBデータへのSNMPV1アクセスを使用して返されたデータは、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) Counter64のSNMPV2構文を含む可変バインディングは、視界にないと見なされ、MIBデータは、Counter64以外の値が返されるか、エラーまたは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) 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,
- エラーステータスはノーエラーに設定されます、
- 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を処理する場合、SNMPV2アクセスをMIBデータに使用する場合は、次の手順に従う必要があります。
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ターゲット-MIBおよびSNMP-Notification-MIBから取得したパラメーターを使用して、通知を生成するために使用されるSNMPバージョンがSNMPV1である場合、使用されるPDUタイプは常にTrappduになります。snmpnotifyTypeの値はtrap（1）またはinform（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ターゲット-MIBとSNMP-Notification-MIBの検査から）。特に、[RFC3413]、セクション3.3、弾丸（3）で指定されたアクセスチェックを実行するために、SNMPV1トラップを生成する場合、通知オリジネーターは、セクション3.1で説明されているようにSNMPTRAPOID.0の値を生成する必要がある場合があります。（2）および（3）このドキュメントの（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バージョン、および受信したPDUを転送するために使用されるSNMPバージョンに依存します。次のセクションでは、これらの翻訳について説明します。以下に説明するすべての場合において、プロキシは、このドキュメントのセクション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に設定されているかのように行動し、PDUのタグをGetNextreate-Extest-に設定するものとします。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.
- エラーステータスフィールドに「Toobig」の値があるGetResponse-PDUが受信され、メッセージが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.
- エラーステータスフィールドに「Toobig」の値があるGetResponse-PDUが受信され、メッセージがSNMPV2CまたはSNMPV3メッセージバージョンを使用して転送され、プロキシが受け取った元のリクエストはGetBulkRequest-PDU、プロキシでした。フォワーダーは、最初の可変バインディングを除くすべてのものを除いて、転送された要求（GetNextre-Equest-PDUと変更されていただろう）を再送信するものとします。プロキシフォワーダーは、そのような要求を1回だけ再送信するものとします。結果のGetResponse-PDUに「Toobig」の値を持つエラーステータスフィールドも含まれている場合、プロキシフォワーダーは変数バインディングフィールドの内容を削除し、エラーステータスフィールドを「ノーエラー」に変更し、確実にします。応答を転送する前に、エラーインデックスフィールドが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.
- TRAP-PDUが受信され、SNMPV2CまたはSNMPV3メッセージバージョンを使用して転送される場合、プロキシはセクション3で説明されている翻訳ルールを適用し、通知をSNMPV2-TRAP-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エージェントがTRAP-PDUを含むメッセージを生成すると、SNMPV1以外のSNMPバージョンを使用して1つまたは複数のプロキシ転送業者によって転送されると、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が、タイプCounter64の可変バインディングを含むか、SNMPV2例外コードを含むGetRequest-PDU（以前にプロキシによって生成された）に応じて受信され、SNMPV1メッセージバージョンを使用してメッセージが転送される場合、プロキシは、NOSUCHNAME ERROR-STATUS値を含む元のSNMPV1リクエストからのリクエストIDと可変バインディングで構成される代替応答PDUを生成する必要があります。例外コード。
- 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.
- SNMPV2例外コードを含む可変バインディングを含むgetNextrequest-PDU（以前にプロキシによって生成された）に応じてgetResponse-PDUが受信され、メッセージがSNMPV1メッセージバージョンを使用して転送される場合、プロキシは生成する必要があります。NOSUCHNAME ERROR-STATUS値を含む元のSNMPV1要求からのリクエストIDおよび可変バインディングで構成される代替応答PDU、および例外コードを含む変数バインディングの位置を示すエラーインデックス値を含む。
- 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).
- getnextre-equest-pdu（以前にプロキシで生成された）に応じてgetResponse-PDUが受信された場合、型カウンター64の可変バインディングを含む場合、プロキシは次の変更を加えてgetNextre-equest-PDU全体を再供給する必要があります。Counter64タイプを含む受信したGetResponseの可変バインディングの場合、プロキシは、以前にセントを使用したGetNextre-Equestの対応するオブジェクト名のこれらの変数バインディングのオブジェクト名を置き換えます。プロキシは、Counter64オブジェクトが返されるまでこのプロセスを繰り返す必要があります。実装は、カウンター64オブジェクトをスキップするこのプロセスを最適化しようとする場合があることに注意してください。このような最適化に対する1つのアプローチは、65535未満の場合は、65535の場合は65535の場合は65535の場合は、Varbindsのオブジェクト名の最後のサブ識別子を置き換えることです。このアプローチは、同じCounter64オブジェクトの複数のインスタンスをスキップし、一部の壊れたエージェントの実装との互換性を維持する必要があります（サブ識別子には16ビット整数のみを使用します）。
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要求のプロセスは高価になる可能性があります。プロキシを展開するとき、これは、プロキシが転送するターゲットエージェントを、タイプカウンター64のオブジェクトが実際にこれらと通信するときに使用しているプリンシパルの視野ではないように、ターゲットエージェントを構成することで回避できます。エージェント。ただし、このような構成を使用する場合、型カウンター64のオブジェクトが適切に返されるように、受信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.
- 間違った数値のSNMPV2エラーステータス値、間違ったエンコード、間違った型、間違ったlength、一貫性のない数値、非アクセス、noccess、noccess、nocreation、nocreation、矛盾、resource unavabable、commitunaved、undofaided、またはauthorizationを使用して前方に使用して前向きに使用する場合、getResponse-pduを受信した場合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-TRAP-PDUが受信され、SNMPV1メッセージバージョンを使用して転送される場合、プロキシはセクション3で説明されている翻訳ルールを適用し、通知をTRAP-PDUとして転送するものとします。受信したSNMPV2-TRAP-PDUにCounter64データタイプが存在するために翻訳が失敗した場合、TRAPは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メッセージバージョンを使用してのみ転送できます。SNMPV2CまたはSNMPV3を使用して転送する必要があることを示す他の構成情報がある場合、InformRequest-PDUは引き続き転送される場合があります。
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:
SNMPV1（およびSNMPV2C）をSNMPアーキテクチャに適応させるために、次のメッセージ処理（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メッセージ処理モデルは同一であるため、このドキュメントでは独立して説明されていません。2つのモデル間の違いは、必要に応じて説明されています。
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コミュニティベースのセキュリティモデルはほぼ同一であるため、独立して議論されません。これら2つのモデルの違いも必要に応じて説明されています。
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-Community-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値は0です（snmpv2cの値は1）。
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）メッセージを受信するエンティティのアイテム（3）は、さまざまなパラメーターが「目的の認証スキーム」に渡されることを述べています。この場合の望ましい認証スキームは、SNMPV1コミュニティベースのセキュリティモデルです。これは、ProcessIncomingMsg ASIを使用して呼び出されます。このASIに渡されたパラメーターは次のとおりです。
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- MessageProcessingModel。これは0（またはSNMPV2Cの場合は1）になります。
- 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.
- Community Stringとメッセージのソースおよび宛先輸送ドメインとアドレスで構成されるSecurityParameters。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- SecurityModelは1（またはSNMPV2Cの場合は2）になります。
- The securityLevel, which will be noAuthNoPriv.
- SecurityLevel、それはnoauthnoprivになります。
- 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のエントリの1つと一致する必要があります。SNMPTARGETADDRTMASKオブジェクトは、TransportDomainとTransportAddressがSNMPTARGETADDRTABLEのエントリと一致するかどうかを確認する際にセクション5.3で説明されているように使用されます。
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の値となります。
- 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つの値、ContextSnmPengineID（SNMPCommunityTableの選択したエントリからのSNMPCommunityContextEngineIDの値になる）で構成されていることに注意してください。PDU。最初の2つはメッセージに実際に表示されないため、これらは個別の値である必要があります。
- 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.
- MaxSizerEsponsEsCopedPDUは、上記のMaxMessagesizeの最小値と、SNMPTARGETADDRTABLEの選択した行のSNMPTARGETADDRMMSの値を使用して導出されます。そのようなエントリが選択されていない場合、この値は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:
ProcessPDU ASIを使用して、適切なSNMPアプリケーションが（ContextEngineIDの値とPDUのリクエストタイプに応じて）呼び出されます。このASIに渡されたパラメーターは次のとおりです。
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- MessageProcessingModel。これは0（またはSNMPV2Cの場合は1）になります。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- SecurityModelは1（またはSNMPV2Cの場合は2）になります。
- The securityName, which was returned from the call to processIncomingMsg.
- callsincomingmsgへの呼び出しから返されたsecurityName。
- The securityLevel, which is noAuthNoPriv.
- noauthnoprivです。
- The contextEngineID, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- ContextEngineID。これは、Calls from ProcessIncomingMsgからscopedpduの一部として返されました。
- The contextName, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- ContextNameは、scopedpduの一部として呼び出しからprocessincomingmsgへと返されました。
- The pduVersion, which should indicate an SNMPv1 version PDU (if the message version was SNMPv2c, this would be an SNMPv2 version PDU).
- PDuversionは、SNMPV1バージョンPDUを示す必要があります（メッセージバージョンがSNMPV2Cの場合、これはSNMPV2バージョンPDUになります）。
- The PDU, which was returned as part of the ScopedPDU from the call to processIncomingMsg.
- PDUは、scopedpduの一部として呼び出しからprocessincomingmsgへと返されました。
- The maxSizeResponseScopedPDU which was returned from the call to processIncomingMsg.
- maxsizeresponsescopedpduは、CallからProcessIncomingMsgに返されました。
- The stateReference which was returned from the call to processIncomingMsg.
- ProcessIncomingMsgへの呼び出しから返された統計。
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ターゲット-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.
- コンテキスト名は、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のエントリの1つと一致する必要があります。
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.
- コンテキスト名は、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.
そのようなエントリが見つからない場合、プロキシ転送アプリケーションは、RFC 3413 [RFC3413]、セクション3.5.1.1、アイテム（2）に記載されている手順に従う必要があります。この手順では、snmpproxydropsカウンター[RFC3418]が増加し、RepontResponsepdu Abstract Serviceインターフェイスを使用してディスパッチャーを呼び出すことにより応答-PDUが生成されることを示しています。
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-Community-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を使用すると、SNMPTARGETGETADDRTABLEで選択されたエントリが複数のアドレスを指定できます（エントリごとに単一のアドレスではなく）。これは通常、単一のアドレスではなく、SNMPTARGETGETADDRTABLEでサブネットを指定するために使用されます。マスク値は、トランスポートアドレスが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;
iPaddress、Module-Identity、Object-Type、Integer32、Snmpv2-Smi Rowstatusのsnmpmodules、snmpv2-tc snmpadminstringのstoragetype、snmp-framework-mib snmptagvalueのsnmpengineidのsnmpengineid、snmpteraddrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentrentdrentrentrentdrentdrentrentのsnmpengineidSnmpv2-confから;
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モジュールIDULE IDINTITY最終的には「200308060000Z " - 2003年8月6日、「SNMPV3ワーキンググループ」WG-EMAIL：snmpv3@lists.tislabs.com添付：majordomo@lists.tislabs.com：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
共同議長：Russ Mundy Sparta、Inc Postal：7075 Samuel Morse Drive Columbia、MD 21045 USAメール：mundy@tislabs.com電話：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
共同議長：David Harrington Enterasys Networks Postal：35 Industrial Way P. O. Box 5005 Rochester、New Hampshire 03866-5005 USAメール：dbh@enterasys.com電話：1 603-337-2614
Co-editor: Rob Frye Vibrant Solutions
共同編集者：Rob Frye Vibrant Solutions
Postal: 2711 Prosperity Ave Fairfax, Virginia 22031 USA E-mail: rfrye@vibrant-1.com Phone: +1-703-270-2000
郵便：2711 Prosperity Ave Fairfax、Virginia 22031 USA E-mail：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
共同編集者：David B. Levi Nortel Networks Postal：3505 Kesterwood Drive Knoxville、Tennessee 37918電子メール：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
共同編集者：Shawn A. Routhier Wind River Systems、Inc。Postal：500 Wind River Way Alameda、CA 94501 E-mail：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 "
共同編集者：Bert Wijnen Lucent Technologies Postal：Schagen 33 3461 GL Linschoten Otherlandsメール：bwijnen@lucent.com電話：31-348-407-775 "
DESCRIPTION "This MIB module defines objects to help support coexistence between SNMPv1, SNMPv2c, and SNMPv3.
説明 "この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."
著作権（c）The Internet Society（2003）このMIBモジュールのこのバージョンは、RFC 3584の一部です。完全な法的通知については、RFC自体を参照してください。」
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.
リビジョン「200308060000Z」 - 2003年8月6日説明「最後にアップデートされた連絡先、およびリビジョン条項が更新され、MIBモジュールのモジュール同意の呼び出しの説明条項に著作権通知を追加しました。
Updated the description of snmpCommunityTransportTag to make it consistent with the rest of the document.
SNMPCommunityTransporttagの説明を更新して、ドキュメントの残りの部分と一致するようにしました。
Updated the description of `snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown.
「snmptargetaddrmms」の説明を更新して、0の値が最大メッセージサイズが不明であることを意味することを明確にします。
Changed the name of 'snmpCommunityGroup' to snmpCommunityTableGroup to avoid a name conflict with the SNMPv2-MIB.
「SNMPCommunityGroup」の名前をSNMPCommunityTableGroupに変更して、SNMPV2-MIBとの競合を避けました。
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."
リビジョン「200003060000Z」 - 2000年3月6日説明「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 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
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.
構文snmpengineid max-access read-createステータス現在の説明 "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 sntax snmptagvalue max-access read-createステータス現在の説明 "このオブジェクトは、2つの方法で使用される一連のトランスポートエンドポイントを指定します。SNMPCommunityNameの対応するインスタンスに一致するコミュニティ文字列を使用して通知を送信できるトランスポートエンドポイントを指定します。どちらの場合も、このオブジェクトの値が長さがゼロの場合、このコミュニティ文字列を含むメッセージを認証する場合のトランスポートエンドポイントがチェックされない場合、通知を生成する場合。
The transports identified by this object are specified in the snmpTargetAddrTable. Entries in that table whose snmpTargetAddrTagList contains this tag value are identified.
このオブジェクトによって識別されるトランスポートは、SNMPTARGETADDRTABLEで指定されています。SNMPTARGETADDRTAGLISTがこのタグ値を含むそのテーブルのエントリが識別されます。
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 syntax rowstatus max-access read-createステータス現在の説明 "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.
この表のエントリは、デフォルト値または設定操作を介して、対応するすべての列のインスタンスが初期化されるまで、アクティベーションの対象となります。snmpcommunityNameおよびsnmpcommunitysecurityNameオブジェクトを明示的に設定する必要があります。
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }
-- -- The snmpTargetAddrExtTable --
--- snmptargetaddrextable-
snmpTargetAddrExtTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of mask and maximum message size (mms) values associated with the snmpTargetAddrTable.
snmptargetaddrextableオブジェクトタイプのsnmptargetaddrextentry max-access of snmptargetaddrtableに関連するマスクと最大メッセージサイズ（mms）値の値（mms）値
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.
snmptargetaddrtmak object-type syntax octet string（size（0..255））max-access read-createステータス現在の説明 "snmptargetaddrtableのエントリに関連付けられたマスク値。このオブジェクトの値は、対応するものと同じ長さでなければなりませんsnmptargetaddrtaddressのインスタンス、または長さ0のインスタンス。他の値に設定しようとすると、一貫性のない値エラーが発生します。
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.
このオブジェクトの値により、snmptargetaddrtableのエントリが複数のアドレスを指定できます。マスク値は、トランスポートアドレスがSNMPTARGETADDRTABLEの特定のエントリを一致させるために、輸送アドレスのどのビットがSNMPTARGETADDRTADDRESSの対応するインスタンスのビットと一致する必要があるかを選択するために使用されます。マスク値の1であるビットは、輸送アドレスのビットを示しており、SNMPTARGETADDRTADDRESS値のビットに一致する必要があります。マスク内の0であるビットは、一致する必要がない輸送アドレスのビットを示しています。マスクの長さが0の場合、マスクはすべてのビットが1であり、その長さが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 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モジュールコンプライアンスステータス現在の説明「SNMP-Community-Mibを実装するSNMPエンジンのコンプライアンスステートメント。」
MODULE -- this module MANDATORY-GROUPS { snmpCommunityTableGroup }
モジュール - このモジュールの必須グループ{snmpcommunityTableGroup}
OBJECT snmpCommunityName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトSNMPCommunityName MIN-ACCESS READ-ONLY説明「書き込みアクセスは不要です。」
OBJECT snmpCommunitySecurityName MIN-ACCESS read-only DESCRIPTION "Write access is not required."
Object SNMPCommunitySecurityName Min-Access Readのみの説明「書き込みアクセスは不要です。」
OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトSNMPCommunityTransportTag Min-Access読み取り専用説明「書き込みアクセスは不要です。」
OBJECT snmpCommunityStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクト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モジュールコンプライアンスステータス現在の説明「完全な読み取りアクセスを備えた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 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）
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はセキュリティを提供しませんが、コミュニティ名をSecurityName/ContextNameにマッピングできるようにします。実際、ネットワーク管理者は、そうでなければ安全な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の間でメッセージを翻訳すると、セキュリティの損失がある可能性があります。たとえば、SNMPV1を使用して転送される認証とプライバシーを使用して受信したSNMPV3メッセージは、認証とプライバシー（機密性とも呼ばれます）を使用するセキュリティメリットを失います。このような状況に対処するには、プロキシの慎重な構成が必要です。このような状況に対処するための1つのアプローチは、暗号化されたトンネルを使用することです。
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:
このMIBモジュールには、読み取りワイトおよび/またはread-Createの最大アクセス句を備えた管理オブジェクトが多数あります。このようなオブジェクトは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしの非セキュア環境でのセット操作のサポートは、ネットワーク操作に悪影響を与える可能性があります。これらはテーブルとオブジェクトであり、その感度/脆弱性です。
- 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モジュールの読み取り可能なオブジェクトのいくつか（つまり、アクセスできないこと以外に最大アクセスを備えたオブジェクト）は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのオブジェクトへのアクセスを取得および/または通知することさえ制御し、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を使用して）安全である場合でも、それでもセキュアネットワーク上の誰がアクセス/セット/セット（読み取り/変更/作成/削除/削除）を制御することはできません。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エンティティが、実際に取得または設定する正当な権利を持つプリンシパル（ユーザー）にのみオブジェクトにアクセスできるように適切に構成されていることを保証するのは、顧客/オペレーターの責任です（変更を変更します（変更）/作成/削除）それら。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, May 1990.
[RFC1155] Rose、M。およびK. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M.およびC. Davin、「Simple Network Management Protocol（SNMP）」、STD 15、RFC 1157、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212] Rose、M。and K. McCloghrie、eds。、「Scise MIB Definitions」、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215] Rose、M。、「SNMPで使用するためのトラップを定義するための条約」、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. Rose、「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] Case、J.、McCloghrie、K.、Rose、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、RFC 2578、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.、Perkins、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.、Perkins、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] Harrington、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] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「Simple Network Management Protocol（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] Levi、D.、Meyer、P。and B. Stewart、「Simple Network Management Protocol（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] Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMP）のバージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnen、B.、B.、Presuhn、R。、およびK. McCloghrie、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、2002年12月、RFC 3415、RFC 3415。
[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.、ed。、「Simple Network Management Protocol（SNMPV2）のプロトコル操作のバージョン2」、STD 62、RFC 3416、2002年12月。
[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.、ed。、「Simple Network Management Protocol（SNMPV2）のバージョン2の輸送マッピング」、STD 62、RFC 3417、2002年12月。
[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.、ed。、「Simple Network Management Protocol（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（1987年12月）。
[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] Case、J.、McCloghrie、K.、Rose、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] Levi、D。およびB. Wijnen、「バイリンガルSNMPエージェント内のSNMPV2をSNMPV1にマッピングする」、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] Frye、R.、Levi、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] Case、J.、Mundy、R.、Partain、D。およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576.
以下のセクション番号RFC 2576の古いセクション番号を参照してください。RFC2576以降、セクション番号が変更されています。
- Added text to abstract about conversion of MIBs from SMIv1 to SMIv2.
- SMIV1からSMIV2へのMIBSの変換に関する要約にテキストを追加しました。
- Added note at end of section 1.3 that all discussion of SNMPv2 PDU types and protocol operations applies to both SNMPv2c and SNMPv3.
- セクション1.3の最後に、SNMPV2 PDUタイプとプロトコル操作のすべての議論がSNMPV2CとSNMPV3の両方に適用されることに注意しました。
- 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タイプとプロトコル操作を使用しているだけなので、セクション1.4の最後にテキストを追加して「SNMPV3アクセス」などのものがないことを明確にします。
- Moved section 1.4 to the beginning of section 4.
- セクション1.4をセクション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.
- セクション2.1.1の最初のリストの項目（3）に「必須」が「必須」に変更されました。
- 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.
- セクション2.1.1の最初のリストの項目（13）の「必須」に「必要」が変更されました。MIBモジュールをSMIV1からSMIV2に翻訳するときに、関連するオブジェクトをグループに収集する必要があることを明確にします。
- 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.
- セクション2.3の項目（1）および（2）の「必須」に「必須」に変更されました。これは、RFC 1303で定義された言語からの機能ステートメントをSMIV2に翻訳する場合に実際に必要であるためです。
- 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の最後の部分の2番目の弾丸で、SNMPTRAPOIDパラメーターは2番目の変数バインディングの値部分（名前部分ではない）を指し、箇条書きの下のテキストの文言を変更したことを明らかにしました（1）セクション3.2の「snmptrapoid」から「snmptrapoid値」まで、この点を強調します。
- In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-bindings do not include sysUpTime.0 an snmpTrapOID.0.
- セクション3.2の弾丸（6）では、SNMPV2可変バインディングにはsysuptime.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に、SNMPV2CまたはSNMPV3メッセージを処理し、最終段落を書き直して、以下のサブセクションがSNMPV2アクセスを使用するコマンドレスポンダーのみに関係していることに注意して、MIBデータへのSNMPV1アクセスを使用しないでください。SNMPV1要求の処理中のMIBデータ。
- 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では、翻訳されたgetResponse-PDUで「トゥービグ」のエラーステータスでエラーインデックスフィールドをゼロに設定する必要があることを明らかにし、getBulkRequest-PDUを1回だけ再試行する理由を明示しました。
- 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.
- セクション4.2.2の展開ヒントにテキストを追加して、SNMPV1要求に異なるプリンシパルを使用する必要があることを明確にし、SNMPV1がcounter64オブジェクトが使用されていないプリンシパルを要求する場合、SNMPV2/V3C要求に使用する必要があります。
- 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.
- 最後に更新された、連絡先INFO、およびリビジョン条項を更新し、MIBモジュールのモジュール同一性の呼び出しの説明条項に著作権通知を追加しました。
- 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.
- SNMPCommunityTransporttagの説明を更新して、ドキュメントの残りの部分と一致するようにしました。
- Updated the description of 'snmpTargetAddrMMS' to clarify that a value of 0 means that the maximum message size is unknown.
- 「snmptargetaddrmms」の説明を更新して、0の値が最大メッセージサイズが不明であることを意味することを明確にします。
- Changed the name of 'snmpCommunityGroup' to 'snmpCommunityTableGroup' in order to resolve a name conflict with the SNMPv2-MIB.
- snmpv2-mibとの競合を解決するために、「snmpcommunitygroup」の名前を「snmpcommunitytablegroup」に変更しました。
- 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.
- さまざまな誤植および文法的エラーを修正しました。
- 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メッセージ処理モデルと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.
- SNMPCommunityMibを追加して、SNMPV1およびSNMPV2コミュニティ文字列をSNMPバージョンの独立パラメーターにマッピングできるようにし、標準のSNMPV3ビューベースのアクセス制御モデルとSNMPVACMMIBを使用してアクセス制御に使用できます。
- 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通知（TRAP）をSNMPV2通知に変換する必要がある場合、2つのMIBオブジェクトが追加され、これらの2つのオブジェクトを追加して、発信元のSNMPV1エージェントのアドレスとコミュニティに関する情報を保持します。
- Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping within a multi-lingual SNMP Engine.
- RFC 2089からMulti-Lingual SNMPエンジン内のSNMPV1マッピングに含まれる（および拡張）。
- 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.
- MIBモジュールをSMIV1からSMIV2に変換するためのいくつかのルールを変更/追加しました。
- 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.
Rob Frye Vibrant Solutions 2711 Prosperity Ave Fairfax、Virginia 22031 U.S.A.
Phone: +1 703 270 2000
EMail: rfrye@vibrant-1.com
David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A.
David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville、TN 37918 U.S.A.
Phone: +1 865 686 0432
EMail: dlevi@nortelnetworks.com
Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 U.S.A.
Shawn A. Routhier Wind River Systems、Inc。500 Wind River Way Alameda、CA 94501 U.S.A.
Phone: + 1 510 749 2095
EMail: sar@epilogue.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschotenオランダ
Phone: +31 348 407 775
EMail: bwijnen@lucent.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。