RFC3584 日本語訳
3584 Coexistence between Version 1, Version 2, and Version 3 of theInternet-standard Network Management Framework. R. Frye, D. Levi, S.Routhier, B. Wijnen. August 2003. (Format: TXT=115222 bytes) (Obsoletes RFC2576) (Also BCP0074) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.フライ要求をネットワークでつないでください: 3584の敏感なソリューションBCP: 74 D.レビは以下を時代遅れにします。 2576 ノーテルはカテゴリをネットワークでつなぎます: 最も良い現在の練習の水系Inc.B.WijnenルーセントテクノロジーズS.Routhier風の2003年8月
Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework
インターネット標準ネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存
Status of this Memo
このMemoの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントの目的はインターネット標準Network Management Framework、(SNMPv3)、インターネット標準Network Management Frameworkのバージョン2(SNMPv2)、および元のインターネット標準Network Management Framework(SNMPv1)のバージョン3の間の共存について説明することです。 また、このドキュメントはSMIv1形式からSMIv2形式までMIBモジュールを変換する方法を説明します。 このドキュメントはRFC2576を時代遅れにします。
Frye, et al. Best Current Practice [Page 1] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[1ページ]RFC3584Coexistence
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
1. 概要. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 SNMPv1. . . . . . . . . . . . . . . . . . . . . . . . 4 1.2。 SNMPv2. . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 SNMPv3. . . . . . . . . . . . . . . . . . . . . . . . 5 2。 SMIと経営情報マッピング。 . . . . . . . . . . 5 2.1. MIBモジュール。 . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. オブジェクト定義. . . . . . . . . . . . . . 6 2.1.2。 罠と通知定義. . . . . . 8 2.2。 承諾声明。 . . . . . . . . . . . . . . . . 9 2.3. 能力声明。 . . . . . . . . . . . . . . . 9 3. 通知パラメタを翻訳します。 . . . . . . . . . . . . 10 3.1. SNMPv2通知パラメタ. . . . . . . . . . . . 11 3.2にSNMPv1通知パラメタを翻訳します。 SNMPv1通知パラメタ. . . . . . . . . . . . 12 4にSNMPv2通知パラメタを翻訳します。 多言語ネットワーク. . . . 14 4.1における共存へのアプローチ。 SNMPv1とSNMPv2はデータ. . . . . . . . . 14 4.2にMIBにアクセスします。 多言語実装。 . . . . . . . . . . . . 15 4.2.1. ジェネレータを命令してください。 . . . . . . . . . . . . . . 15 4.2.2. 応答者を命令してください。 . . . . . . . . . . . . . . 16 4.2.2.1. 取り扱Counter64. . . . . . . . . 16 4.2.2い.2。 SNMPv2例外を写像します。 . . . . . 17 4.2.2.2.1. noSuchObjectとnoSuchInstanceを写像します。 . . . 18 4.2.2.2.2. endOfMibViewを写像します。 . . 18 4.2.2.3. .4にSNMPv1 GetReques. . . 18 4.2.2を処理します。 SNMPv1 GetNextRequestを処理します。 19 4.2.2.5. SNMPv1 SetRequestを処理します。 . . 20 4.2.3. 通知創始者。 . . . . . . . . . . . 21 4.2.4. 通知受信機…………21 4.3。 プロキシ実装。 . . . . . . . . . . . . . . . . 22 4.3.1. 川下のバージョンよりすばらしい上流のバージョン。 . . . . . . . . . . . . . . . . . . . 22 4.3.2. 川下のバージョンより少ない上流のバージョン。 23 4.4. エラー状況マッピング。 . . . . . . . . . . . . . . . . 25 5. メッセージ処理はモデル化されます、そして、セキュリティはモデル化されます。 . . . . . . . 26 5.1. マッピング. . . . . . . . . . . . . . . . . . . . . . . 26 5.2。 SNMPv1MPモデルとSNMPv1地域密着型の機密保護モデル. . . . . . . . . . . . . . . . . . . . 26 5.2.1。 入って来る要求. . . . . . . . 27 5.2.2を処理します。 外向的な応答を生成します。 . . . . . . . 29 5.2.3. 送信する通知を生成します。 . . . . . 29 5.2.4. 要求. . . . . . . . . 30 5.3のプロキシ推進。 SNMP共同体MIBモジュール。 . . . . . . . . . . . . 30 6. 知的所有権声明。 . . . . . . . . . . . . . . 42 7. 承認。 . . . . . . . . . . . . . . . . . . . . . . 43
Frye, et al. Best Current Practice [Page 2] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[2ページ]RFC3584Coexistence
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
8. セキュリティ問題。 . . . . . . . . . . . . . . . . . . 43 9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . 44 9.1。 引用規格. . . . . . . . . . . . . . . . . 44 9.2。 有益な参照. . . . . . . . . . . . . . . . 46付録A.はログを変えます。 . . . . . . . . . . . . . . . . . . . . 47 A.1。 RFC2576.47A.2からの変化。 RFC1908とRFC2576.49人のエディタのアドレス. . . . . . . . . . . . . . . . . . . . . . . 50の間で完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 51を変えます。
1. Overview
1. 概要
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).
このドキュメントの目的は(SNMPv3)(インターネット標準Network Management Frameworkのバージョン2)がSNMPバージョン2フレームワーク(SNMPv2)を呼んだSNMPバージョン3フレームワークと呼ばれたインターネット標準Network Management Frameworkのバージョン3と元のインターネット標準Network Management Framework(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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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 Message Processing ModelとベースのCommunity Security Model(ベースのView Access Control Model(VACM)[20]にSNMPv1を適合させるのにメカニズムを提供する)はセクション5で記録されます(また、このセクションはSNMPv2c Message Processing ModelとベースのCommunity Security Modelを扱います)。
Frye, et al. Best Current Practice [Page 3] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[3ページ]RFC3584Coexistence
1.1. SNMPv1
1.1. SNMPv1
SNMPv1 is defined by these documents:
SNMPv1はこれらのドキュメントによって定義されます:
- STD 15, RFC 1157 [RFC1157] which defines the Simple Network
Management Protocol (SNMPv1), the protocol used for network access
to managed objects.
- STD15、Simple Network Managementプロトコル(SNMPv1)(管理オブジェクトへのネットワークアクセスに使用されるプロトコル)を定義するRFC1157[RFC1157]。
- STD 16, RFC 1155 [RFC1155] which defines the Structure of
Management Information (SMIv1), the mechanisms used for describing
and naming objects for the purpose of management.
- STD16、Management情報(SMIv1)のStructureを定義するRFC1155[RFC1155]、メカニズムは説明と命名に管理の目的のためのオブジェクトを使用しました。
- STD 16, RFC 1212 [RFC1212] which defines a more concise
description mechanism, which is wholly consistent with the SMIv1.
- STD16、完全にSMIv1と一致したより簡潔な記述メカニズムを定義するRFC1212[RFC1212]。
- RFC 1215 [RFC1215] which defines a convention for defining Traps
for use with the SMIv1.
- SMIv1との使用のためにTrapsを定義するためにコンベンションを定義するRFC1215[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'という期間が使用されていることに注意してください。 一般に、今期はRFC1155、RFC1212、およびRFC1215に提示された情報を示します。
1.2. SNMPv2
1.2. SNMPv2
SNMPv2 is defined by these documents:
SNMPv2はこれらのドキュメントによって定義されます:
- STD 58, RFC 2578 which defines Version 2 of the Structure of
Management Information (SMIv2) [RFC2578].
- STD58、Management情報(SMIv2)[RFC2578]のStructureのバージョン2を定義するRFC2578。
- STD 58, RFC 2579 which defines common MIB "Textual Conventions"
[RFC2579].
- STD58、一般的なMIB「原文のコンベンション」[RFC2579]を定義するRFC2579。
- STD 58, RFC 2580 which defines Conformance Statements and
requirements for defining agent and manager capabilities
[RFC2580].
- エージェントとマネージャ能力[RFC2580]を定義するためのSTD58、Conformance Statementsを定義するRFC2580、および要件。
- STD 62, RFC 3416 which defines the Protocol Operations used in
processing [RFC3416].
- STD62、プロトコルOperationsを定義するRFC3416が処理に[RFC3416]を使用しました。
- STD 62, RFC 3417 which defines the Transport Mappings used "on the
wire" [RFC3417].
- STD62、Transport Mappingsを定義するRFC3417が「ワイヤ」[RFC3417]を使用しました。
- STD 62, RFC 3418 which defines the basic Management Information
Base for monitoring and controlling some basic common functions of
SNMP entities [RFC3418].
- STD62(SNMP実体[RFC3418]のいくつかの基本的な一般的な関数をモニターして、制御するための基本的なManagement Information基地を定義するRFC3418)。
Note that SMIv2 as used throughout this document refers to the first three documents listed above (RFCs 2578, 2579, and 2580).
このドキュメント中で使用されるSMIv2が(RFCs2578、2579、および2580)より上でリストアップされた最初の3通のドキュメントを示すことに注意してください。
Frye, et al. Best Current Practice [Page 4] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[4ページ]RFC3584Coexistence
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.
- RFC1901[RFC1901]は、地域密着型のメッセージラッパーの中でSNMPv2 PDUsを使用するためのExperimental定義です。 これはこのドキュメント中でSNMPv2cに言及されます。
1.3. SNMPv3
1.3. SNMPv3
SNMPv3 is defined by these documents:
SNMPv3はこれらのドキュメントによって定義されます:
- STD 62, RFC 3411 which defines an Architecture for Describing SNMP
Management Frameworks [RFC3411].
- STD62、Describing SNMP Management Frameworks[RFC3411]のためにArchitectureを定義するRFC3411。
- STD 62, RFC 3412 which defines Message Processing and Dispatching
[RFC3412].
- STD62、Message Processingを定義するRFC3412、およびDispatching[RFC3412]。
- STD 62, RFC 3413 which defines various SNMP Applications
[RFC3413].
- STD62、様々なSNMP Applications[RFC3413]を定義するRFC3413。
- STD 62, RFC 3414 which defines the User-based Security Model
(USM), providing for both Authenticated and Private (encrypted)
SNMP messages [RFC3414].
- STD62、Authenticatedと兵士の(暗号化される)のSNMPメッセージ[RFC3414]の両方に備えて、UserベースのSecurity Model(USM)を定義する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].
- STD62、1ユーザあたり1個のベース[RFC3415]でアクセスを異なったMIBオブジェクトに制限する能力を提供して、ViewベースのAccess Control Model(VACM)を定義する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は上で説明された3418を通したRFCs3416のSNMPv2定義と2580を通した2578年のSMIv2定義を使用します。 SNMPv2 PDUタイプとプロトコル操作について言及するこのドキュメント中のテキストがSNMPv2cとSNMPv3の両方に適用されることに注意してください。
2. SMI and Management Information Mappings
2. SMIと経営情報マッピング
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アプローチがMIBモジュールを定義するために既存の習慣を主に成文化することに注意するかもしれません、SMIv1の広範囲の経験に基づいて。
The following sections consider the three areas: MIB modules, compliance statements, and capabilities statements.
以下のセクションは3つの領域を考えます: MIBモジュール、承諾声明、および能力声明。
Frye, et al. Best Current Practice [Page 5] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[5ページ]RFC3584Coexistence
2.1. MIB Modules
2.1. MIBモジュール
MIB modules defined using the SMIv1 may continue to be used with protocol versions which use SNMPv2 PDUs. However, for SMIv1 MIB modules to conform to the SMIv2, the following changes SHALL be made:
SMIv1を使用することで定義されたMIBモジュールは、SNMPv2 PDUsを使用するプロトコルバージョンと共に使用され続けるかもしれません。 しかしながら、SMIv1 MIBモジュールがSMIv2、以下の変化SHALLに従うには、作られてください:
2.1.1. Object Definitions
2.1.1. オブジェクト定義
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モジュールの変換はそこに含まれたオブジェクトの不賛成を必要としません。 オブジェクトの定義が本当に本来の目的に不十分であるなら、オブジェクトSHALLが推奨しないか時代遅れにされていて、さもなければ、不賛成は必要ではありません。
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of
RFC1155-SMI and RFC-1212.
(1) IMPORTS声明はRFC1155-SMIの代わりに参照SNMPv2-SMIとRFC-1212がそうしなければなりません。
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any
IMPORTs statement.
(2) どんなIMPORTs声明直後MODULE-IDENTITYマクロを呼び出さなければなりません。
(3) For any object with a SYNTAX clause value of Counter, the object
MUST have the value of its SYNTAX clause changed to Counter32.
(3) CounterのSYNTAX節価値があるどんなオブジェクトに関しても、オブジェクトで、SYNTAX節の値はCounter32に変わらなければなりません。
(4) For any object with a SYNTAX clause value of Gauge, the object
MUST have the value of its SYNTAX clause changed to Gauge32, or
Unsigned32 where appropriate.
(4) GaugeのSYNTAX節価値があるどんなオブジェクトに関しても、オブジェクトで、SYNTAX節の値は適切であるところでGauge32、またはUnsigned32に変わらなければなりません。
(5) For all objects, the ACCESS clause MUST be replaced by a MAX-
ACCESS clause. The value of the MAX-ACCESS clause SHALL be the
same as that of the ACCESS clause unless some other value makes
"protocol sense" as the maximal level of access for the object.
In particular, object types for which instances can be
explicitly created by a protocol set operation, SHALL have a
MAX-ACCESS clause of "read-create". If the value of the ACCESS
clause is "write-only", then the value of the MAX-ACCESS clause
MUST be "read-write", and the DESCRIPTION clause SHALL note that
reading this object will result in implementation-specific
results. Note that in SMIv1, the ACCESS clause specifies the
minimal required access, while in SMIv2, the MAX-ACCESS clause
specifies the maximum allowed access. This should be considered
when converting an ACCESS clause to a MAX-ACCESS clause.
(5) すべてのオブジェクトに関して、ACCESS節をマックスACCESS節に取り替えなければなりません。 値、マックス-ACCESS節SHALLでは、ある他の値の造がオブジェクトのための最大限度のアクセスのレベルとして「感覚について議定書の中で述べない」なら、ACCESS節のものと同じにしてください。 特に、オブジェクトは、どれについて、プロトコルセット操作で明らかにインスタンスを作成できて、SHALLにはマックス-ACCESS節があるようにタイプされるか。「読書して作成します」。 ACCESS節の値がそうである、「書く、-単に、」、次に、マックス-ACCESS節の値は「-読まれて、書いてください」ということでなければなりません、そして、記述節SHALLはこのオブジェクトを読むと実装特有の結果がもたらされることに注意します。 SMIv1では、ACCESS節が最小量の必要なアクセスを指定することに注意してください、マックス-ACCESS節はSMIv2でアクセサリーが許容された最大を指定しますが マックス-ACCESS節にACCESS節を変換するとき、これは考えられるべきです。
(6) For all objects, if the value of the STATUS clause is
"mandatory" or "optional", the value MUST be replaced with
"current", "deprecated", or "obsolete" depending on the current
usage of such objects.
(6) そのようなオブジェクトの現在の使用法によって、STATUS節の値が「義務的である」か「任意である」なら、値は、すべてのオブジェクトに関して、「電流」に取り替えられる、「推奨しない」か、または「時代遅れでなければなりません」。
Frye, et al. Best Current Practice [Page 6] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[6ページ]RFC3584Coexistence
(7) For any object not containing a DESCRIPTION clause, the object
MUST have a DESCRIPTION clause defined.
(7) 記述節を含まないどんなオブジェクトに関しても、オブジェクトには、定義された記述節がなければなりません。
(8) For any object corresponding to a conceptual row which does not
have an INDEX clause, the object MUST have either an INDEX
clause or an AUGMENTS clause defined.
(8) INDEX節を持っていない概念的な行に対応するどんなオブジェクトに関しても、オブジェクトは節が定義したINDEX節かAUGMENTSのどちらかを持たなければなりません。
(9) If any INDEX clause contains a reference to an object with a
syntax of NetworkAddress, then a new object MUST be created and
placed in this INDEX clause immediately preceding the object
whose syntax is NetworkAddress. This new object MUST have a
syntax of INTEGER, it MUST be not-accessible, and its value MUST
always be 1. The effect of this, and the preceding bullet, is
to allow one to convert a MIB module in SMIv1 format to one in
SMIv2 format, and then use it with the SNMPv1 protocol with no
impact to existing SNMPv1 agents and managers.
(9) 何かINDEX節がNetworkAddressの構文でオブジェクトの参照を含んでいるなら、すぐに構文がNetworkAddressであるオブジェクトに先行するこのINDEX節に、新しいオブジェクトを作成されて、置かなければなりません。 この新しいオブジェクトには、INTEGERの構文がなければなりません、そして、それはアクセスしやすいはずがありません、そして、いつも値は1でなければなりません。 この効果、および前の弾丸は、SMIv1形式におけるMIBモジュールをSMIv2形式における1つに変換して、次に、SNMPv1プロトコルと共に影響なしで既存のSNMPv1エージェントとマネージャにそれを使用するために1つを許容することになっています。
(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のSYNTAX、SYNTAX MUSTと共に反対してください。IpAddressに変えます。 新しいMIBドキュメントにおけるNetworkAddressの使用が強くお勧めできないことに注意してください(事実上、新しいMIBドキュメントはSMIv2を使用することで書かれているべきです)。SMIv2はNetworkAddressを定義しません。
(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) サブ識別子の収集として言い表されるOBJECT IDENTIFIER値があるDEFVAL節を含むどんなオブジェクトに関しても、ただ一つのASN.1識別子に参照をつけるために値を変えなければなりません。 これは、ただ一つのASN.1識別子を定義するために、一連の新しい管理課題(OBJECT IDENTIFIERS)を定義するのを必要とするかもしれません。
(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) 定義されて、関係づけられたOBJECT-GROUPS MUSTが適切なグループに集めなければならないのを反対させる1つ以上。 SMIv2が、すべてのOBJECT-TYPEsが少なくとも1OBJECT-GROUPのメンバーであることを必要とすることに注意してください。
(13) For any non-columnar object that is instanced as if it were
immediately subordinate to a conceptual row, the value of the
STATUS clause of that object MUST be changed to "obsolete".
(13) どんな非円柱状のオブジェクトに関しても、まるでそれがすぐに概念的な行(そのオブジェクトの節が「時代遅れにする」ために変わらなければならないSTATUSの値)に下位であるかのようにそれは例証されます。
(14) For any conceptual row object that is not immediately
subordinate to a conceptual table, the value of the STATUS
clause of that object (and all subordinate objects) MUST be
changed to "obsolete".
(14) どんな概念的な行オブジェクトに関しても、それはすぐに、概念的なテーブル(そのオブジェクト(そして、すべての下位オブジェクト)の節が「時代遅れにする」ために変わらなければならないSTATUSの値)に下位ではありません。
Frye, et al. Best Current Practice [Page 7] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[7ページ]RFC3584Coexistence
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モジュールが早く一代でレビューを受けて、概念的な行の作成と削除を許す概念的なテーブルを含んでいるなら、それらのテーブルに関連するオブジェクトを、推奨しなく、新しいアプローチを使用することで定義されたオブジェクトに取り替えるかもしれません。 RFC2578[RFC2578]のセクション7でSMIv2に基づくアプローチは見つけることができます、そして、RowStatusとStorageType TEXTUAL-CONVENTIONsはRFC2579[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.
そして、対応するINTEGERが範囲制限を持っていない整数で評価されたSYNTAX節でのどんなオブジェクトのための(2)、も(すなわち、INTEGERには定義されたセットの名前付の数の列挙も課題も、より低くない、値に関する上限)、オブジェクトSHOULDはSYNTAX節の値をInteger32に変わらせるか、または適切な範囲を指定させます。
(3) For any object with a string-valued SYNTAX clause, in which the
corresponding OCTET STRING does not have a size restriction
(i.e., the OCTET STRING has no assignment of lower- and upper-
bounds on its length), the bounds for the size of the object
SHOULD be defined.
(3) 何かストリングで評価されたSYNTAX節があるオブジェクトのために、サイズ制限(すなわち、OCTET STRINGには、長さにおける下側の、そして、上側の領域の課題が全くない)、オブジェクトSHOULDのサイズのための領域は定義されましたか?そこでは、対応するOCTET STRINGはそうしません。
(4) All textual conventions informally defined in the MIB module
SHOULD be redefined using the TEXTUAL-CONVENTION macro. Such a
change would not necessitate deprecating objects previously
defined using an informal textual convention.
(4) すべての原文のコンベンションが再定義された使用がTEXTUAL-CONVENTIONマクロであったならMIBモジュールでSHOULDを非公式に定義しました。 そのような変化は、以前に非公式の原文のコンベンションを使用することで定義されたオブジェクトを非難するのを必要としないでしょう。
(5) For any object which represents a measurement in some kind of
units, a UNITS clause SHOULD be added to the definition of that
object.
(5) ある種のユニットにおける測定、UNITS節SHOULDを表すあらゆるオブジェクトに関して、そのオブジェクトの定義に加えられてください。
(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節がSHOULDであるということであるあらゆる概念的な行には、拡大である概念的な行に対応するオブジェクトのためのINDEX節に代わって、使用されてください。
2.1.2. Trap and Notification Definitions
2.1.2. 罠と通知定義
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:
SMIv2に従うためにMIBモジュールを変えるなら、TRAP-TYPEマクロの各発生はNOTIFICATION-TYPEマクロの対応する実施に変わらなければなりません:
Frye, et al. Best Current Practice [Page 8] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[8ページ]RFC3584Coexistence
(1) The IMPORTS statement MUST NOT reference RFC-1215 [RFC1215], and
MUST reference SNMPv2-SMI instead.
(1) IMPORTS声明は、RFC-1215[RFC1215]に参照をつけてはいけなくて、代わりにSNMPv2-SMIに参照をつけなければなりません。
(2) The ENTERPRISE clause MUST be removed.
(2) エンタープライズ節を取り除かなければなりません。
(3) The VARIABLES clause MUST be renamed to the OBJECTS clause.
(3) VARIABLES節をOBJECTS節に改名しなければなりません。
(4) A STATUS clause MUST be added, with an appropriate value.
Normally the value should be 'current', although 'deprecated' or
'obsolete' may be used as needed.
(4) 適切な値でSTATUS節を加えなければなりません。 通常、値は'現在であり'、'推奨しない'か'時代遅れです'が、必要に応じて使用されるかもしれないということであるはずです。
(5) The value of an invocation of the NOTIFICATION-TYPE macro is an
OBJECT IDENTIFIER, not an INTEGER, and MUST be changed
accordingly. Specifically, if the value of the ENTERPRISE
clause is not 'snmp' then the value of the invocation SHALL be
the value of the ENTERPRISE clause extended with two sub-
identifiers, the first of which has the value 0, and the second
has the value of the invocation of the TRAP-TYPE. If the value
of the ENTERPRISE clause is 'snmp', then the value of the
invocation of the NOTIFICATION-TYPE macro SHALL be mapped in the
same manner as described in section 3.1 in this document.
(5) NOTIFICATION-TYPEマクロの実施の値をINTEGERではなく、OBJECT IDENTIFIERであり、それに従って、変えなければなりません。 明確に、エンタープライズ節の値であるなら、そして、'snmp'は節がそれの1番目には値0がある2つのサブ識別子で広げて、2番目が持っているエンタープライズの値がTRAP-TYPEの実施の値であったなら実施のSHALLの値ではありませんか? 'snmp'、次に、写像しているコネがセクション3.1で本書では説明される同じ方法であったならエンタープライズ節の値がNOTIFICATION-TYPEマクロSHALLの実施の値であるなら。
(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) 1NOTIFICATION-GROUPsを定義しなければなりません、そして、関連する通知をそれらのグループに集めなければなりません。 SMIv2が、すべてのNOTIFICATION-TYPEsが少なくとも1NOTIFICATION-GROUPのメンバーであることを必要とすることに注意してください。
2.2. Compliance Statements
2.2. 承諾声明
For those information modules which are "standards track", a corresponding invocation of the MODULE-COMPLIANCE macro and related OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within the information module (or in a companion information module), and any commentary text in the information module which relates to compliance SHOULD be removed. Typically this editing can occur when the information module undergoes review.
情報モジュール(または仲間情報モジュールで)の中に「標準化過程」、MODULE-COMPLIANCEマクロと関連するOBJECT-GROUP、そして/または、NOTIFICATION-GROUPマクロの対応する実施を含まなければならないということであるそれらの情報モジュール、および関係する情報モジュールによるあらゆる論評テキストには、承諾SHOULDに移されてください。 情報モジュールがレビューを受けるとき、通常、この編集は起こることができます。
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.
MODULE-COMPLIANCE声明は標準化過程(例えば、企業MIB)の上にないMIBドキュメントに必要でないことに注意してください、そのようなMIBドキュメントのためにMODULE-COMPLIANCE声明を定義するのがいくつかの事情で役に立つかもしれませんが。
2.3. Capabilities Statements
2.3. 能力声明
RFC 1303 [RFC1303] uses the MODULE-CONFORMANCE macro to describe an agent's capabilities with respect to one or more MIB modules.
RFC1303[RFC1303]は、1つ以上のMIBモジュールに関してエージェントの能力について説明するのにMODULE-CONFORMANCEマクロを使用します。
Frye, et al. Best Current Practice [Page 9] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[9ページ]RFC3584Coexistence
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) マクロはエージェント-CAPABILITIES MUSTを命名します。MODULE-CONFORMANCEの代わりに、使用されます。
(2) The STATUS clause MUST be added, with a value of 'current'.
(2) '電流'の値でSTATUS節を加えなければなりません。
(3) All occurrences of the CREATION-REQUIRES clause MUST either be
omitted if appropriate, or be changed such that the semantics
are consistent with RFC 2580 [RFC2580].
(3) CREATION-REQUIRES節のすべての発生を適切であるなら省略しなければならないか、または変えなければならないので、意味論はRFC2580[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モジュールで定義されたオブジェクトグループはエージェント-CAPABILITIESマクロの実施のINCLUDES節によって参照をつけられるかもしれません: SMIv1 MIBモジュールで定義されたOBJECT IDENTIFIER下位木の参照に遭遇すると、下位木に下位であり、義務的のSTATUS節価値を持っているすべての葉のオブジェクトがINCLUDEdであると考えられます。(SMIv1 MIBの異なった改正が同じ下位木の下で異なったセットの義務的なオブジェクトを持っているとき、このメソッドがあいまいであることに注意してください; そのような場合、唯一のソリューションは明白にオブジェクトグループを定義するのにSMIv2を使用することでMIBを書き直すことです。)
3. Translating Notification Parameters
3. 通知パラメタを翻訳します。
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.
- 実体がいつ特定の形式の通知パラメタ、および実体の構成の1セットを生成するかが通知に通知パラメタのためにもう片方の形式を必要とする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メッセージバージョンを使用することで通知を転送しなければなりません。
Frye, et al. Best Current Practice [Page 10] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[10ページ]RFC3584Coexistence
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).
- 企業パラメタ(OBJECT IDENTIFIER)。
- An agent-addr parameter (NetworkAddress).
- エージェント-addrパラメタ(NetworkAddress)。
- A generic-trap parameter (INTEGER).
- ジェネリック罠パラメタ(INTEGER)。
- A specific-trap parameter (INTEGER).
- 特定の罠パラメタ(INTEGER)。
- A time-stamp parameter (TimeTicks).
- タイムスタンプパラメタ(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パラメタ(TimeTicks)。 これはSNMPv2罠PDUかInformRequest-PDUにおける最初の変項束縛に現れます。
- An snmpTrapOID parameter (OBJECT IDENTIFIER). This appears in the
second variable-binding in an SNMPv2-Trap-PDU or InformRequest-
PDU, and is equal to the value portion of that variable-binding
(not the name portion, as both the name and value are OBJECT
IDENTIFIERs).
- snmpTrapOIDパラメタ(OBJECT IDENTIFIER)。 これは、SNMPv2罠PDUかInformRequest- PDUにおける2番目の変項束縛に現れて、その変項束縛の値の部分と等しいです(名前部分でない、両方として、名前と値はOBJECT IDENTIFIERsです)。
- A list of variable-bindings (VarBindList). This refers to all but
the first two variable-bindings in an SNMPv2-Trap-PDU or
InformRequest-PDU.
- 変項束縛(VarBindList)のリスト。 これはSNMPv2罠PDUかInformRequest-PDUの最初の2つの変項束縛以外のすべてを示します。
3.1. Translating SNMPv1 Notification Parameters to SNMPv2 Notification
Parameters
3.1. SNMPv1通知パラメタをSNMPv2通知パラメタに翻訳します。
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パラメタSHALL、直接SNMPv1タイムスタンプパラメタから、取ってください。
Frye, et al. Best Current Practice [Page 11] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[11ページ]RFC3584Coexistence
(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企業パラメタと2つのものの連結が追加サブ識別子であったなら、SNMPv1ジェネリック罠パラメタは'enterpriseSpecific(6)'、SNMPv2 snmpTrapOIDパラメタSHALLであるかどうか、'0'、およびSNMPv1特定の罠パラメタ。
(3) If the SNMPv1 generic-trap parameter is not
'enterpriseSpecific(6)', the SNMPv2 snmpTrapOID parameter SHALL
be the corresponding trap as defined in section 2 of RFC 3418
[RFC3418]:
(3) SNMPv1ジェネリック罠パラメタであるなら、RFC3418のセクション2で定義される対応する罠が[RFC3418]であったなら、'enterpriseSpecific(6)'、SNMPv2 snmpTrapOIDパラメタはSHALLではありません:
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)
ジェネリック罠パラメタsnmpTrapOID.0============ ============= 0 1.3.6.1.6.3.1.1.5.1(コールドスタート)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(結合)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変項束縛SHALL、SNMPv1の可変結合になってください。 さらに、プロキシが容認された罠を進めるために翻訳を実行していると、3つの追加変項束縛を追加するでしょう、これらの3つの追加変項束縛がSNMPv1の可変結合で既に存在していないなら。 最初の追加変項束縛SHALLの名前一部がsnmpTrapAddress.0を含んでいます、そして、値のSHALLはSNMPv1エージェント-addrパラメタを含んでいます。 2番目の追加変項束縛SHALLの名前一部がsnmpTrapCommunity.0を含んでいます、そして、値のSHALLはSNMPv1 Trap-PDUを含んだ受信されたSNMPv1メッセージからの共同体文字列欄の値を含んでいます。 3番目の追加変項束縛SHALLの名前一部がsnmpTrapEnterprise.0[RFC3418]、および値のSHALLを含んでいます。SNMPv1企業パラメタになってください。
3.2. Translating SNMPv2 Notification Parameters to SNMPv1 Notification
Parameters
3.2. SNMPv2通知パラメタを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企業パラメタSHALL、以下の通り断固としてください:
- 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
- SNMPv2 snmpTrapOIDパラメタが1であるなら、RFC3418[RFC3418]、次に、SNMPv1企業パラメタSHALLで定義される標準の罠では、名前があるSNMPv2変項束縛における、変項束縛の値に設定されてください。
Frye, et al. Best Current Practice [Page 12] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[12ページ]RFC3584Coexistence
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].
snmpTrapEnterprise.0はその変項束縛であるなら存在しています。 そうしないなら、存在してください、SNMPv1企業パラメタSHALL。RFC3418[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パラメタが1でないなら、RFC3418[RFC3418]、次に、SNMPv1企業パラメタSHALLで定義される標準の罠では、以下の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企業はSNMPv2 snmpTrapOIDが最後の2つのサブ識別子が取り除かれている値であったなら別の方法でSHALLですか?
- 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が最後のサブ識別子が取り除かれている値であったならSHALLですか?
(2) The SNMPv1 agent-addr parameter SHALL be determined based on the
situation in which the translation occurs.
(2) SNMPv1エージェント-addrパラメタは翻訳が現れる状況を基礎づけましたSHALLが決心している。
- 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はIPへのセットが通知創始者が住んでいるSNMP実体のアドレスであったならパラメタSHALLをエージェントと同じくらいaddrします。 ある他の輸送、SNMPv1エージェント-addrパラメタSHALLの上に送るために、通知がそうなら設定されてください。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パラメタSHALLである変項束縛を含んでいるなら。 さもなければ、SNMPv1は0.0へのセットが.0であったならパラメタSHALLをエージェントと同じくらいaddrします。.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パラメタが1であるなら、RFC3418[RFC3418]、SNMPv1ジェネリック罠パラメタSHALLで定義される標準の罠では、以下の通り設定されてください:
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
snmpTrapOID.0パラメタジェネリック罠=============================== ============ 1.3.6.1.6.3.1.1.5.1 (コールドスタート)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(結合)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
Frye, et al. Best Current Practice [Page 13] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[13ページ]RFC3584Coexistence
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
さもなければ、SNMPv1はパラメタSHALLをジェネリックで捕らえます。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パラメタが1であるなら、RFC3418[RFC3418]、SNMPv1特定の罠パラメタSHALLで定義される標準の罠では、ゼロに設定されてください。 さもなければ、SNMPv1は最終へのセットがSNMPv2 snmpTrapOIDパラメタに関するサブ識別子であったならパラメタSHALLを詳細で捕らえます。
(5) The SNMPv1 time-stamp parameter SHALL be taken directly from the
SNMPv2 sysUpTime parameter.
(5) SNMPv1はパラメタSHALLを時押し込みます。直接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変項束縛SHALL、SNMPv2の可変結合(そして、SNMPv2変項束縛が変項束縛を含んでいないというsysUpTime.0、snmpTrapOID.0を含むメモ)になってください。 しかしながら、SNMPv2の可変結合が何かタイプがCounter64であるオブジェクトを含んでいるなら、SNMPv1通知パラメタへの翻訳を実行できないことに注意してください。 この場合、SNMPv1パケットで通知をコード化できません(通知は、セクション4.2.3を見て、SNMPv1を使用させるので、4.3を区分できません)。
4. Approaches to Coexistence in a Multi-lingual Network
4. 多言語ネットワークにおける共存へのアプローチ
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つの局所的に安全なネットワークの間の不安定なリンクの上にコミュニケーションを保証することの役に立ちます。
4.1. SNMPv1 and SNMPv2 Access to MIB Data
4.1. SNMPv1とMIBデータへのSNMPv2アクセス
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 DataへのSNMPv1 Access'と'MIB DataへのSNMPv2 Access'について言及します。 これらの用語は実際にMIBオブジェクトのインスタンスにアクセスして、実際に通知の世代を開始するSNMPエージェントの部分について言及します。 MIBデータへのアクセスの2つのタイプの違いは以下の通りです。
- Error-status values generated.
- 値が生成したエラー状況。
Frye, et al. Best Current Practice [Page 14] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[14ページ]RFC3584Coexistence
- Generation of exception codes.
- 例外コードの世代。
- Use of the Counter64 data type.
- Counter64データ型の使用。
- The format of parameters provided when a notification is
generated.
- 通知が発生しているとき、パラメタの形式は提供されました。
SNMPv1 access to MIB data may generate SNMPv1 error-status values, will never generate exception codes nor use the Counter64 data type, and will provide SNMPv1 format parameters for generating notifications. Note also that SNMPv1 access to MIB data will actually never generate a readOnly error (a noSuchName error would always occur in the situation where one would expect a readOnly error).
MIBデータへのSNMPv1アクセスは、SNMPv1エラー状況が値であると生成するかもしれなくて、例外がコードであると生成して、Counter64データ型を決して使用しないで、通知を生成するための形式パラメタをSNMPv1に供給するでしょう。 また、MIBデータへのSNMPv1アクセスが、実際にreadOnlyが誤りであると決して生成しないことに注意してください(noSuchName誤りはものがreadOnly誤りを予想する状況でいつも発生するでしょう)。
SNMPv2 access to MIB data may generate SNMPv2 error-status values, may generate exception codes, may use the Counter64 data type, and will provide SNMPv2 format parameters for generating notifications. Note that SNMPv2 access to MIB data will never generate readOnly, noSuchName, or badValue errors.
MIBデータへのSNMPv2アクセスは、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.
SNMPv2がデータにMIBにアクセスするとき、特定の多言語実装が、MIBデータへのすべてのアクセスを実装するのを選ぶかもしれないことに注意してください、そして、SNMPv1ベースのトランザクションのためにここに説明された翻訳を実行してください。
Further, note that there is no mention of 'SNMPv3 access to MIB data' in this document, as SNMPv3 uses SNMPv2 PDU types and protocol operations.
さらに、'MIBデータへのSNMPv3アクセス'の言及が全く本書ではないことに注意してください、SNMPv3がSNMPv2 PDUタイプとプロトコル操作を使用するとき。
4.2. Multi-lingual implementations
4.2. 多言語実装
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メッセージバージョンだけをサポートする実体と共存して、伝えるバージョンであるとサポートする実体を許容します。
4.2.1. Command Generator
4.2.1. コマンドジェネレータ
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
メッセージバージョンとしてSNMPv1を選定するとき、さらに、コマンドジェネレータはGetBulk要求をGetNext要求に'格下げしなければなりません'。
Frye, et al. Best Current Practice [Page 15] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[15ページ]RFC3584Coexistence
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.
送信する要求。 単に操作タイプをGetNextに変えることによって、これをします、どんな非リピータと最大反復値も無視して、エラー状況と誤りインデックスをゼロに設定して。
4.2.2. Command Responder
4.2.2. コマンド応答者
A command responder must be able to deal with both SNMPv1 and SNMPv2 access to MIB data. There are three aspects to dealing with this. A command responder must:
コマンド応答者はSNMPv1とSNMPv2アクセスのMIBデータへの両方に対処できなければなりません。 これに対処することへの3つの局面があります。 コマンド応答者はそうしなければなりません:
- Deal correctly with SNMPv2 access to MIB data that returns a
Counter64 value while processing an SNMPv1 message,
- 正しくSNMPv1メッセージを処理している間に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つの例外値の1つを返すMIBデータへのSNMPv2アクセスに対処してください。
- Map SNMPv2 error codes returned from SNMPv2 access to MIB data
into SNMPv1 error codes when processing an SNMPv1 message.
- SNMPv1メッセージを処理するとき、地図SNMPv2エラーコードはMIBデータへのSNMPv2アクセスから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.
プロキシ推進に関するケースを除いて、SNMPv2cかSNMPv3メッセージを処理するときにはSNMPv1エラーコードSHOULD NOTが少しも変化なしで使用されることに注意してください。 また、SNMPv1はデータSHOULD NOTにMIBにアクセスします。SNMPv2cかSNMPv3メッセージを処理するときには、使用されてください。 後方にように互換性を進めるプロキシの場合では、SNMPv1エラーコードは進められたSNMPv2cかSNMPv3メッセージにおける少しも変化なしで使用されるかもしれません。
The following sections describe the behaviour of a command responder application which supports multiple SNMP message versions, and which uses SNMPv2 access to MIB data when processing an SNMPv1 message.
以下のセクションは複数のSNMPメッセージがバージョンであるとサポートして、SNMPv1メッセージを処理するときMIBデータへのSNMPv2アクセスを使用するコマンド応答者アプリケーションのふるまいについて説明します。
4.2.2.1. Handling Counter64
4.2.2.1. 取り扱いCounter64
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]は1つのSMIv1と両立しない新しい構文を定義します。 この構文はCounter64です。 SMIv2によって定義された他のすべての構文がSMIv1と互換性があります。
The impact on multi-lingual command responders is that they MUST NOT ever return a variable binding containing a Counter64 value in a response to a request that was received using the SNMPv1 message version.
多言語コマンド応答者の上の影響は彼らがSNMPv1メッセージバージョンを使用することで受け取られた要求への応答における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メッセージを処理するとき、視点から除かれて、多言語コマンド応答者SHALLはタイプがCounter64であるオブジェクトインスタンスがそれとなくそうであるアプローチを取ります。 そのように:
- 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-
- 名前欄がタイプCounter64、GetResponsePDU SHALLのオブジェクトインスタンスを示す変項束縛を含むSNMPv1 GetRequest-PDUを受け取り次第、返してください、誤りで
Frye, et al. Best Current Practice [Page 16] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[16ページ]RFC3584Coexistence
status of noSuchName and the error-index set to the variable
binding that caused this error.
それを縛る変数へのnoSuchNameの状態と誤りインデックスセットはこの誤りを引き起こしました。
- On an SNMPv1 GetNextRequest-PDU, any object instance which
contains a syntax of Counter64 SHALL be skipped, and the next
accessible object instance that does not have the syntax of
Counter64 SHALL be retrieved. If no such object instance exists,
then an error-status of noSuchName SHALL be returned, and the
error-index SHALL be set to the variable binding that caused this
error.
- SNMPv1 GetNextRequest-PDU、Counter64 SHALLの構文を含むどんなオブジェクトインスタンスのスキップされていてCounter64 SHALLの構文を検索しない次のアクセスしやすいオブジェクトインスタンスになってください。 何かそのようなオブジェクトインスタンスが存在していないなら、noSuchName SHALLのエラー状況は、返して誤りで索引をつけるSHALLです。この誤りを引き起こした変項束縛に設定されてください。
- 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.
- どんなSNMPv1も、どれがCounter64値がある変項束縛を含むかが、不適格であるよう要求するので、以上の規則は申し込まれません。 含んでいるでしょう、その誤りが検出されるなら、応答SHALL NOTを返して、したがって、不適格な変項束縛のコピーを含んでください。 代わりに、捨てられてカウンタsnmpInASNParseErrs SHALLになってくださいPDU SHALLを怒らせて、増加されていて。
4.2.2.2. Mapping SNMPv2 Exceptions
4.2.2.2. SNMPv2例外を写像します。
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 Response PDUが誤りがいつ発生するかという可能で、同等であるのと同じくらい多くの経営情報を返すことができる例外と呼ばれる特徴を提供します。 しかしながら、SNMPv1が例外をサポートしないので、SNMPv1 Response PDUは少しの経営情報も返すことができないで、エラー状況と誤りインデックス値を返すことができるだけです。
When an SNMPv1 request is received, a command responder MUST check any variable bindings returned using SNMPv2 access to MIB data for exception values, and convert these exception values into SNMPv1 error codes.
SNMPv1要求が受信されているとき、コマンド応答者は、例外値がないかどうかMIBデータへのSNMPv2アクセスを使用することで返されたどんな変項束縛もチェックして、これらの例外値をSNMPv1エラーコードに変換しなければなりません。
The type of exception that can be returned when accessing MIB data and the action taken depends on the type of SNMP request.
MIBデータにアクセスするとき返すことができる例外のタイプと取られた行動はSNMP要求のタイプに頼っています。
- For a GetRequest, a noSuchObject or noSuchInstance exception may
be returned.
- GetRequestに関しては、noSuchObjectかnoSuchInstance例外を返すかもしれません。
- For a GetNextRequest, an endOfMibView exception may be returned.
- GetNextRequestに関しては、endOfMibView例外は返されるかもしれません。
- No exceptions will be returned for a SetRequest, and a
GetBulkRequest should only be received in an SNMPv2c or SNMPv3
message, so these request types may be ignored when mapping
exceptions.
- SetRequestのために例外を全く返さないで、SNMPv2cかSNMPv3メッセージにGetBulkRequestを受け取るだけであるべきであるので、これらは、例外を写像するとき、タイプが無視されるかもしれないよう要求します。
Note that when a response contains multiple exceptions, it is an implementation choice as to which variable binding the error-index should reference.
応答が複数の例外を含むとき、誤りインデックスはどの変項束縛に参照がそうするべきであるかとしてそれが実装選択であることに注意してください。
Frye, et al. Best Current Practice [Page 17] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[17ページ]RFC3584Coexistence
4.2.2.2.1. Mapping noSuchObject and noSuchInstance
4.2.2.2.1. noSuchObjectとnoSuchInstanceを写像します。
A noSuchObject or noSuchInstance exception generated by an SNMPv2 access to MIB data indicates that the requested object instance can not be returned. The SNMPv1 error code for this condition is noSuchName, and so the error-status field of the response PDU SHALL be set to noSuchName. Also, the error-index field SHALL be set to the index of the variable binding for which an exception occurred (if there is more than one then it is an implementation decision as to which is used), and the variable binding list from the original request SHALL be returned with the response PDU.
MIBデータへのSNMPv2アクセスで生成されたnoSuchObjectかnoSuchInstance例外が、要求されたオブジェクトインスタンスを返すことができないのを示します。 この状態のためのSNMPv1エラーコードはnoSuchNameであり、そうは応答PDU SHALLのエラー状況分野です。noSuchNameに設定されます。 誤りインデックス部もSHALL、例外が起こった変項束縛のインデックスに設定してください。そうすれば(1つ以上があれば、それはどれがあるかに関して使用される実装決定です)、オリジナルからの変項束縛リストは、SHALLが応答PDUと共に返されるよう要求します。
4.2.2.2.2. Mapping endOfMibView
4.2.2.2.2. endOfMibViewを写像します。
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 SHALLのそうをもたらします。noSuchNameに設定されます。 誤りインデックス部もSHALL、例外が起こった変項束縛のインデックスに設定してください。そうすれば(1つ以上があれば、それはどれがあるかに関して使用される実装決定です)、オリジナルからの変項束縛リストは、SHALLが応答PDUと共に返されるよう要求します。
4.2.2.3. Processing An SNMPv1 GetRequest
4.2.2.3. SNMPv1 GetRequestを処理します。
When processing an SNMPv1 GetRequest, the following procedures MUST be followed when using an SNMPv2 access to MIB data.
SNMPv1 GetRequestを処理するとき、MIBデータへのSNMPv2アクセスを使用するとき、以下の手順に従わなければなりません。
When such an access to MIB data returns response data using SNMPv2 syntax and error-status values, then:
そして、MIBデータへのそのようなアクセスがいつ、SNMPv2構文を使用することで応答データを返すか、そして、エラー状況は以下を評価します。
(1) If the error-status is anything other than noError,
(1) エラー状況であるなら、noErrorを除いて、何でもあります。
- The error status SHALL be translated to an SNMPv1 error-
status using the table in section 4.4, "Error Status
Mappings".
- エラー状況SHALL、SNMPv1誤りセクション4.4でテーブルを使用する状態、「エラー状況マッピング」に翻訳されてください。
- The error-index SHALL be set to the position (in the
original request) of the variable binding that caused the
error-status.
- 変項束縛の位置(オリジナルの要求における)へのセットがエラー状況が引き起こされたそれであったならSHALLに誤りで索引をつけてください。
- 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 SHALLのリストを縛る変数を受け取りました。
Frye, et al. Best Current Practice [Page 18] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[18ページ]RFC3584Coexistence
(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です、変項束縛SHALL。どんなSNMPv2例外(noSuchObjectかnoSuchInstance)かSNMPv1において、未知であることのSNMPv2構文(Counter64)がないかどうかチェックされてください。 そして、どんなそのような変項束縛もあります、1、それらの変項束縛SHALLでは、選択されてください、(それはどれがあるかに関して選択された実装選択です):
- The error-status SHALL be set to noSuchName,
- エラー状況SHALL、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
- そして選択された変数の位置(オリジナルの要求の変項束縛リストの)へのセットは拘束力があったならSHALLに誤りで索引をつけてください。
- 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 SHALLのリストを縛る変数を受け取りました。
(3) If there are no such variable bindings, then:
(3) 次に、何かそのような変項束縛がなければ:
- The error-status SHALL be set to noError,
- エラー状況SHALL、noErrorに設定されてください。
- The error-index SHALL be set to zero, and
- そして誤りインデックスSHALL、ゼロに設定されてください。
- The variable binding list of the response SHALL be composed
from the data as it is returned by the access to MIB data.
- それはデータから落ち着いていますが、応答SHALLの変項束縛リストはそうです。
4.2.2.4. Processing An SNMPv1 GetNextRequest
4.2.2.4. SNMPv1 GetNextRequestを処理します。
When processing an SNMPv1 GetNextRequest, the following procedures MUST be followed when SNMPv2 access to MIB data is used as part of processing the request. There may be repetitive accesses to MIB data to try to find the first object which lexicographically follows each of the objects in the request. This is implementation specific. These procedures are followed only for data returned when using SNMPv2 access to MIB data. Data returned using SNMPv1 access to MIB data may be treated in the normal manner for an SNMPv1 request.
SNMPv1 GetNextRequestを処理するとき、MIBデータへのSNMPv2アクセスが要求を処理する一部として使用されるとき、以下の手順に従わなければなりません。 要求で辞書編集にそれぞれのオブジェクトに続く最初のオブジェクトを見つけようとするMIBデータへの反復性のアクセスがあるかもしれません。 これは実装特有です。 これらの手順はMIBデータへのSNMPv2アクセスを使用するとき返されたデータのためだけに従われています。 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) エラー状況SHALL、セクション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)、変項束縛の位置(オリジナルの要求における)へのセットがエラー状況が引き起こされたそれであったならSHALLに誤りで索引をつけてください。
Frye, et al. Best Current Practice [Page 19] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[19ページ]RFC3584Coexistence
(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 SHALLのリストを縛る変数を受け取りました。
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以外の値を返すか、または誤りかendOfMibView例外が発生するまで視点にはないように考えられるのとMIBデータがSHALLであったならCounter64 SHALLのSNMPv2構文を含むどんな変項束縛。
(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を含んでいます(1つ以上があれば、それはどれがあるかに関して選ばれた実装決定です):
- The error-status SHALL be set to noSuchName,
- エラー状況SHALL、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例外であったならSHALLに誤りで索引をつけてください。
- 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 SHALLのリストを縛る変数を受け取りました。
(3) If there are no such variable bindings, then:
(3) 次に、何かそのような変項束縛がなければ:
- The error-status SHALL be set to noError,
- エラー状況SHALL、noErrorに設定されてください。
- The error-index SHALL be set to zero, and
- そして誤りインデックスSHALL、ゼロに設定されてください。
- The variable binding list of the response SHALL be composed
from the data as it is returned by the access to MIB data.
- それはデータから落ち着いていますが、応答SHALLの変項束縛リストはそうです。
4.2.2.5. Processing An SNMPv1 SetRequest
4.2.2.5. SNMPv1 SetRequestを処理します。
When processing an SNMPv1 SetRequest, the following procedures MUST be followed when using SNMPv2 access to MIB data.
SNMPv1 SetRequestを処理するとき、MIBデータへのSNMPv2アクセスを使用するとき、以下の手順に従わなければなりません。
When such MIB access returns response data using SNMPv2 syntax and error-status values, and the error-status is anything other than noError, then:
そのようなMIBアクセスがその時SNMPv2構文とエラー状況値、およびエラー状況を使用することで応答データを返すとき、noErrorを除いて、何でもあります:
- The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.4, "Error Status Mappings".
- エラー状況SHALL、セクション4.4、「エラー状況マッピング」でテーブルを使用することでSNMPv1エラー状況に翻訳されてください。
Frye, et al. Best Current Practice [Page 20] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[20ページ]RFC3584Coexistence
- The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status.
- 変項束縛の位置(オリジナルの要求における)へのセットがエラー状況が引き起こされたそれであったならSHALLに誤りで索引をつけてください。
- 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 SHALLのリストを縛る変数を受け取りました。
4.2.3. Notification Originator
4.2.3. 通知創始者
A notification originator must be able to translate between SNMPv1 notification parameters and SNMPv2 notification parameters in order to send a notification using a particular SNMP message version. If a notification is generated using SNMPv1 notification parameters, and configuration information specifies that notifications be sent using SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2 notification parameters. Likewise, if a notification is generated using SNMPv2 notification parameters, and configuration information specifies that notifications be sent using SNMPv1, the notification parameters must be translated to SNMPv1 notification parameters. In this case, if the notification cannot be translated (due to the presence of a Counter64 type), it will not be sent using SNMPv1.
通知創始者は、特定のSNMPメッセージバージョンを使用することで通知書を送るためにSNMPv1通知パラメタとSNMPv2通知パラメタの間で翻訳できなければなりません。 SNMPv1通知パラメタを使用するのが通知に生成されて、設定情報が、通知はSNMPv2cかSNMPv3を使用させられると指定するなら、SNMPv2通知パラメタに通知パラメタを翻訳しなければなりません。 同様に、SNMPv2通知パラメタを使用するのが通知に生成されて、設定情報が、通知はSNMPv1を使用させられると指定するなら、SNMPv1通知パラメタに通知パラメタを翻訳しなければなりません。 この場合、通知を翻訳できないと(Counter64タイプの存在のため)、それはSNMPv1を使用させられないでしょう。
When a notification originator generates a notification, using parameters obtained from the SNMP-TARGET-MIB and SNMP-NOTIFICATION- MIB, if the SNMP version used to generate the notification is SNMPv1, the PDU type used will always be a TrapPDU, regardless of whether the value of snmpNotifyType is trap(1) or inform(2).
SNMP-TARGET-MIBとSNMP-NOTIFICATION- MIBから得られたパラメタを使用して、通知創始者が通知を生成すると、通知を生成するのに使用されるSNMPバージョンがSNMPv1であるなら、タイプが使用したPDUはsnmpNotifyTypeの値が罠(1)であるかどうかにかかわらずいつもTrapPDUであるか(2)を知らせるでしょう。
Note also that access control and notification filtering are performed in the usual manner for notifications, regardless of the SNMP message version to be used when sending a notification. The parameters for performing access control are found in the usual manner (i.e., from inspecting the SNMP-TARGET-MIB and SNMP- NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in order to perform the access check specified in [RFC3413], section 3.3, bullet (3), the notification originator may need to generate a value for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of this document. If the SNMPv1 notification parameters being used were previously translated from a set of SNMPv2 notification parameters, this value may already be known, in which case it need not be generated.
SNMPメッセージバージョンにかかわらずまた、そのアクセス制御と通知フィルタリングが常法で通知のために実行されることに注意して、通知書を送るとき、使用されてください。 アクセスコントロールを実行するためのパラメタは常法で(すなわち、SNMP-TARGET-MIBとSNMP- NOTIFICATION-MIBを点検するのから)見つけられます。 [RFC3413]で指定されたアクセスチェックを実行するためにSNMPv1 Trapを生成するときの特にセクション3.3、弾丸(3)、通知創始者はセクション3.1(このドキュメントの弾丸(2)と(3))で説明されるようにsnmpTrapOID.0のために値を生成する必要があるかもしれません。 使用されるSNMPv1通知パラメタが以前に1セットのSNMPv2通知パラメタから翻訳されたなら、この値は既に知られているかもしれません、その場合、それが生成される必要はありません。
4.2.4. Notification Receiver
4.2.4. 通知受信機
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
通知受信機のどんな特別な要件もありません。しかしながら、実装によって、通知がaに提供されるべきであるか否かに関係なく、それが、より高い平らなアプリケーションが要求するのを許容するために役に立つのがわかるかもしれません。
Frye, et al. Best Current Practice [Page 21] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[21ページ]RFC3584Coexistence
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通知パラメタを使用するより高い平らなアプリケーション。 そして、必要なセットのパラメタを使用することで通知を提示するのに必要であると、通知受信機は通知パラメタを翻訳するでしょう。
4.3. Proxy Implementations
4.3. プロキシ実装
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メッセージバージョンをサポートする実体のコミュニケーションを可能にするのに使用されるかもしれません。 これは、プロキシ混載業者のアプリケーションでPDUsに翻訳を実行することによって、達成されます。 これらの翻訳は、容認されたPDUを進めるのに使用されるためにPDUタイプ、パケットが容認されたPDUを含むSNMPバージョン、およびSNMPバージョンに頼っています。 以下のセクションはこれらの翻訳について説明します。 以下で説明されたもの以外のすべての場合では、このドキュメントのセクション5.3(共同体MIB)で定義されるサイズ規制を条件としてプロキシSHALLは変化なしで容認されたPDUを進めます。 以下のセクションで、'上流のバージョン'がコマンドジェネレータか通知受信機の間で使用されるバージョンとプロキシについて言及することに注意してください。そうすれば、'川下のバージョン'はプロキシとコマンド応答者か通知創始者の間で使用されるバージョンを呼びます、PDUタイプか方向にかかわらず。
4.3.1. Upstream Version Greater Than Downstream Version
4.3.1. 川下のバージョンよりすばらしい上流のバージョン
- 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.
- SNMPv1メッセージバージョンを使用することでGetBulkRequest-PDUを受け取られていて、進めなければならないなら、プロキシ混載業者SHALL条例はまるで非リピータと最大反復分野が両方であるかのように0にセットしました、そして、SHALLはPDUのタグをGetNextRequest-PDUに設定します。
- If a GetResponse-PDU is received whose error-status field has a
value of 'tooBig', and the message will be forwarded using the
SNMPv2c or SNMPv3 message version, and the original request
received by the proxy was not a GetBulkRequest-PDU, the proxy
forwarder SHALL remove the contents of the variable-bindings field
and ensure that the error-index field is set to 0 before
forwarding the response.
- GetResponse-PDUが受け取られているならだれのエラー状況分野に'tooBig'の値があるか、そして、SNMPv2cかSNMPv3メッセージバージョンを使用することでメッセージを転送して、プロキシによって受け取られたオリジナルの要求がGetBulkRequest-PDUでなく、プロキシ混載業者SHALLは、変項束縛分野のコンテンツを取り除いて、応答を進める前に誤りインデックス部が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-
- GetResponse-PDUが受け取られているなら、だれのエラー状況分野に、'tooBig'の値があるか、そして、SNMPv2cかSNMPv3メッセージバージョンを使用することでメッセージを転送するでしょう、そして、プロキシによって受け取られたオリジナルの要求がGetBulkRequest-PDUであった、プロキシ混載業者SHALLは最初の変項束縛以外のすべてを取り除いていて転送された要求(GetNextRequest-PDUになるように変更された)を再送します。 プロキシ混載業者SHALLはそのような要求にただ一つの時間を再送するだけです。 また、結果として起こるGetResponse-PDUが'tooBig'の値があるエラー状況分野を含んでいるなら、プロキシ混載業者SHALLは変数のコンテンツを取り除きます。
Frye, et al. Best Current Practice [Page 22] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[22ページ]RFC3584Coexistence
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.
誤りインデックス部が0つ以前応答を進めながら設定している結合分野、およびエラー状況が'noError'としてさばいて、確実にする変化。 オリジナルの要求がただ一つの変項束縛を含んだだけであるなら、プロキシが要求を再送しながらスキップして、単に変項束縛を移して、エラー状況を'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メッセージバージョンを使用することで進めるなら、プロキシSHALLはセクション3で説明された翻訳規則を適用します、そして、SHALLはSNMPv2罠PDUとして通知を転送します。
Note that when an SNMPv1 agent generates a message containing a
Trap-PDU which is subsequently forwarded by one or more proxy
forwarders using SNMP versions other than SNMPv1, the community
string and agent-addr fields from the original message generated
by the SNMPv1 agent will be preserved through the use of the
snmpTrapAddress and snmpTrapCommunity objects.
SNMPv1エージェントが次にSNMPv1以外のSNMPバージョンを使用することで1人以上のプロキシ混載業者によって進められるTrap-PDUを含むメッセージを生成するとき、オリジナルのメッセージからの分野がSNMPv1エージェントで生成した共同体ストリングとエージェント-addrがsnmpTrapAddressとsnmpTrapCommunityオブジェクトの使用で保存されることに注意してください。
4.3.2. Upstream Version Less Than Downstream Version
4.3.2. 川下のバージョンより少ない上流のバージョン
- 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.
- SNMPv1メッセージバージョンを使用することでタイプCounter64の可変結合を含むGetRequest-PDU(以前に、プロキシによって生成される)に対応してGetResponse-PDUを受け取るかどうか、またはどれがSNMPv2例外コード、およびメッセージを含んでいるか進めるでしょう; プロキシはオリジナルのSNMPv1からの要求イドから成るPDUと変項束縛が要求する代替の応答を生成しなければなりません、noSuchNameエラー状況価値を含んでいて、Counter64タイプか例外コードを含む変項束縛の位置を示す誤りインデックス値を含んでいて。
- If a GetResponse-PDU is received in response to a GetNextRequest-
PDU (previously generated by the proxy) which contains variable-
bindings that contain an SNMPv2 exception code, and the message
would be forwarded using the SNMPv1 message version, the proxy
MUST generate an alternate response PDU consisting of the
request-id and variable bindings from the original SNMPv1 request,
containing a noSuchName error-status value, and containing an
error-index value indicating the position of the variable-binding
containing the exception code.
- SNMPv2例外コードを含む可変結合を含むGetNextRequest- PDU(以前に、プロキシによって生成される)に対応してGetResponse-PDUを受け取って、SNMPv1メッセージバージョンを使用することでメッセージを転送するなら; プロキシはオリジナルのSNMPv1からの要求イドから成るPDUと変項束縛が要求する代替の応答を生成しなければなりません、noSuchNameエラー状況価値を含んでいて、例外コードを含む変項束縛の位置を示す誤りインデックス値を含んでいて。
Frye, et al. Best Current Practice [Page 23] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[23ページ]RFC3584Coexistence
- 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).
- タイプCounter64の可変結合を含むGetNextRequest- PDU(以前に、プロキシによって生成される)に対応してGetResponse-PDUを受け取るなら、プロキシは全体のGetNextRequest-PDUを再送しなければなりません、以下の変更で。 含まれたCounter64がタイプする容認されたGetResponseのどんな変項束縛のためにも、プロキシは以前に送られたGetNextRequestの対応するオブジェクト名のためのこれらの変項束縛のオブジェクト名を代入します。 プロキシはCounter64オブジェクトを全く返さないまでこのプロセスを繰り返さなければなりません。 実装が、スキップしているCounter64オブジェクトのこのプロセスを最適化するのを試みるかもしれないことに注意してください。 そのような最適化への1つのアプローチはそのサブ識別子が65535以上であるならそのサブ識別子が65535未満であるなら65535でCounter64タイプを含むvarbinds、または4294967295のオブジェクト名に関する最後のサブ識別子を置き換えるだろうことです。 このアプローチはいくつかの壊れているエージェント実装(サブ識別子に16ビットの整数を使用するだけである)との互換性を維持している間、同じCounter64オブジェクトの複数のインスタンスをスキップするべきです。
Deployment Hint: The process of repeated GetNext requests used by
a proxy when Counter64 types are returned can be expensive. When
deploying a proxy, this can be avoided by configuring the target
agents to which the proxy forwards requests in a manner such that
any objects of type Counter64 are in fact not-in-view for the
principal that the proxy is using when communicating with these
agents. However, when using such a configuration, one should be
careful to use a different principal for communicating with the
target agent when an incoming SNMPv2c or SNMPv3 request is
received, to ensure that objects of type Counter64 are properly
returned.
展開ヒント: Counter64タイプを返すときプロキシが使用した繰り返されたGetNext要求のプロセスは高価である場合があります。 プロキシを配布するとき、プロキシが方法による要求を転送する目標エージェントを構成することによってこれを避けることができるので、事実上、タイプCounter64のどんなオブジェクトもこれらのエージェントとコミュニケートするときプロキシが使用している主体のために視点ではありません。 しかしながら、そのような構成を使用するとき、入って来るSNMPv2cかSNMPv3要求がいつタイプCounter64のオブジェクトが適切に返されるのを保証するために受け取られるかを目標エージェントと伝えるのに異なった元本を使用するのに慎重であるはずです。
- If a GetResponse-PDU is received which contains an SNMPv2 error-
status value of wrongValue, wrongEncoding, wrongType, wrongLength,
inconsistentValue, noAccess, notWritable, noCreation,
inconsistentName, resourceUnavailable, commitFailed, undoFailed,
or authorizationError, and the message would be forwarded using
the SNMPv1 message version, the error-status value is modified
using the mappings in section 4.4.
- GetResponse-PDUが受け取られているなら、(SNMPv1メッセージバージョンを使用することでwrongValueか、wrongEncodingか、wrongTypeか、wrongLengthか、inconsistentValueか、noAccessか、notWritableか、noCreationか、inconsistentNameか、resourceUnavailableか、commitFailedか、undoFailedか、authorizationErrorと、メッセージの誤り状態値が送られるSNMPv2を含んでいます)エラー状況値は、セクション4.4でマッピングを使用することで変更されています。
- If an SNMPv2-Trap-PDU is received, and will be forwarded using the
SNMPv1 message version, the proxy SHALL apply the translation
rules described in section 3, and SHALL forward the notification
as a Trap-PDU. Note that if the translation fails due to the
existence of a Counter64 data-type in the received SNMPv2-Trap-
PDU, the trap cannot be forwarded using SNMPv1.
- SNMPv2罠PDUを受け取られていて、SNMPv1メッセージバージョンを使用することで進めるなら、プロキシSHALLはセクション3で説明された翻訳規則を適用します、そして、SHALLはTrap-PDUとして通知を転送します。 翻訳が容認されたSNMPv2罠-PDUのCounter64データ型の存在のため失敗するなら、SNMPv1を使用することで罠を進めることができないことに注意してください。
Frye, et al. Best Current Practice [Page 24] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[24ページ]RFC3584Coexistence
- 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メッセージバージョンSHALLを使用して、無視されてください。 SNMPv2cかSNMPv3メッセージバージョンを使用することでInformRequest-PDUを進めることができるだけです。 それがSNMPv2cかSNMPv3を使用することで進められるべきであるのを示す他の設定情報があれば、まだInformRequest-PDUを進めているかもしれません。
4.4. Error Status Mappings
4.4. エラー状況マッピング
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.
以下のテーブルは、エラー状況がSNMPv2エラー状況値、およびSNMPv2に関するマッピングにSNMPv1エラー状況値への誤り状態値を評価するのをSNMPv1に関するマッピングに示します。
SNMPv1 error-status SNMPv2 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
genErr genErr
SNMPv1エラー状況SNMPv2エラー状況=================== =================== 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
SNMPv2エラー状況SNMPv1エラー状況=================== =================== 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の値を増加しなければなりません。
Frye, et al. Best Current Practice [Page 25] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[25ページ]RFC3584Coexistence
5. Message Processing Models and Security Models
5. メッセージ処理モデルと機密保護モデル
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アーキテクチャに適合させるために、以下のMessage Processing(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 Message Processing ModelとSNMPv2c Message Processing Modelが同じであるので、本書では独自にこれらについて議論しません。 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 Community Security ModelとベースのSNMPv2c Community Security Modelについて議論しません。 また、これらの2つのモデルの違いは必要に応じて説明されます。
5.1. Mappings
5.1. マッピング
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)メッセージのProcessing ModelとSecurity ModelはSNMPv1(そして、SNMPv2c)メッセージで使用されるパラメタの間のマッピングを必要とします、そして、バージョンの独立しているパラメタはSNMPでアーキテクチャ[RFC3411]を使用しました。 写像しなければならないパラメタはSNMPv1(そして、SNMPv2c)共同体名、SNMP securityName、およびcontextEngineID/contextName組から成ります。 これらのマッピングを実行するために、本書では、MIBモジュール(SNMP- COMMUNITY-MIB)を提供します。 このMIBは両方の方向によるマッピングを提供します、そして、すなわち、共同体名はsecurityName、contextEngineIDに写像されるかもしれません、そして、contextName、またはsecurityName、contextEngineID、およびcontextNameの組み合わせが共同体名に写像されるかもしれません。
5.2. The SNMPv1 MP Model and SNMPv1 Community-based Security Model
5.2. SNMPv1MPモデルとSNMPv1地域密着型の機密保護モデル
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 Message Processing ModelはSNMPv1メッセージの処理を扱います。 一般に、メッセージの処理はRFC1157[RFC1157]で説明されるのと同じ方法で扱われます、以下のセクションで説明される違いと明確化で。 SNMPv1のためのSnmpMessageProcessingModel値は0(SNMPv2cのための値は1である)です。
Frye, et al. Best Current Practice [Page 26] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[26ページ]RFC3584Coexistence
5.2.1. Processing An Incoming Request
5.2.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:
RFC1157[RFC1157]では、セクション4.1(メッセージを受け取る実体のための項目(3))は、様々なパラメタが「必要な認証体系」に通過されると述べます。 この場合、必要な認証体系はベースのSNMPv1 Community Security Modelです。(そのSecurity ModelはprocessIncomingMsg ASIを使用すると呼ばれるでしょう)。 このASIに通過されたパラメタは以下の通りです。
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- messageProcessingModel。(その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。(そのmaxMessageSizeは受信実体が生成することができる(受信されたメッセージにはどんなそのような値もないので)メッセージの最大サイズであるべきです)。
- The securityParameters, which consist of the community string and
the message's source and destination transport domains and
addresses.
- メッセージのsecurityParameters、どれが共同体ストリングから成るか、そして、ソース、および目的地はドメインとアドレスを輸送します。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- securityModel。(そのsecurityModelは1歳(または、SNMPv2cのための2)でしょう)。
- The securityLevel, which will be noAuthNoPriv.
- securityLevel。(その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:
ベースのCommunity Security Modelは、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.
どんなそのようなエントリーも見つけることができないなら、認証失敗はRFC1157[RFC1157]で説明されるように起こります、そして、snmpInBadCommunityNamesカウンタは増加されています。
Frye, et al. Best Current Practice [Page 27] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[27ページ]RFC3584Coexistence
The parameters returned from the Community-Based Security Model are:
ベースのCommunity Security Modelから返されたパラメタは以下の通りです。
- The securityEngineID, which will always be the local value of
snmpEngineID.0.
- securityEngineID。(そのsecurityEngineIDはいつもsnmpEngineID.0の地方の値になるでしょう)。
- The securityName, which will be the value of
snmpCommunitySecurityName from the selected row in the
snmpCommunityTable.
- securityName。(そのsecurityNameは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の値になる)、contextName(snmpCommunityTableの選択されたエントリーからのsnmpCommunityContextNameの値になる)、および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と選択のsnmpTargetAddrMMSの値はsnmpTargetAddrTableで船をこぎます。(maxSizeResponseScopedPDUは、上のmaxMessageSizeの最小限を使用することで引き出されるでしょう)。 どんなそのようなエントリーも選択しなかったなら、maxMessageSizeだけからこの値を得るでしょう。
- The securityStateReference, which MUST contain the community
string from the original request.
- securityStateReference。(そのsecurityStateReferenceはオリジナルの要求からの共同体ストリングを含まなければなりません)。
The appropriate SNMP application will then be called (depending on the value of the contextEngineID and the request type in the PDU) using the processPdu ASI. The parameters passed to this ASI are:
そして、適切なSNMPアプリケーションはprocessPdu ASIを使用すると呼ばれるでしょう(contextEngineIDの値に依存して、要求はPDUをタイプします)。 このASIに通過されたパラメタは以下の通りです。
- The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
- messageProcessingModel。(そのmessageProcessingModelは0歳(または、SNMPv2cのための1)でしょう)。
- The securityModel, which will be 1 (or 2 for SNMPv2c).
- securityModel。(そのsecurityModelは1歳(または、SNMPv2cのための2)でしょう)。
- The securityName, which was returned from the call to
processIncomingMsg.
- securityName。(そのsecurityNameは呼び出しからprocessIncomingMsgまで返されました)。
- The securityLevel, which is noAuthNoPriv.
- securityLevel。(そのsecurityLevelはnoAuthNoPrivです)。
- The contextEngineID, which was returned as part of the ScopedPDU
from the call to processIncomingMsg.
- contextEngineID。(そのcontextEngineIDはScopedPDUの一部として呼び出しからprocessIncomingMsgまで返されました)。
- The contextName, which was returned as part of the ScopedPDU from
the call to processIncomingMsg.
- contextName。(その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。(そのpduVersionはSNMPv1バージョンPDU(メッセージバージョンがSNMPv2cであるなら、これはSNMPv2バージョンPDUである)を示すはずです)。
Frye, et al. Best Current Practice [Page 28] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[28ページ]RFC3584Coexistence
- The PDU, which was returned as part of the ScopedPDU from the call
to processIncomingMsg.
- PDU。(そのPDUはScopedPDUの一部として呼び出しからprocessIncomingMsgまで返されました)。
- The maxSizeResponseScopedPDU which was returned from the call to
processIncomingMsg.
- 呼び出しからprocessIncomingMsgまで返されたmaxSizeResponseScopedPDU。
- The stateReference which was returned from the call to
processIncomingMsg.
- 呼び出しからprocessIncomingMsgまで返されたstateReference。
The SNMP application should process the request as described previously in this document. Note that access control is applied by an SNMPv3 command responder application as usual. The parameters as passed to the processPdu ASI will be used in calls to the isAccessAllowed ASI.
SNMPアプリケーションは以前に本書では説明されるように要求を処理するべきです。 アクセスコントロールが通常通りのSNMPv3コマンド応答者アプリケーションで適用されることに注意してください。 processPdu ASIに通過されるパラメタは呼び出しにisAccessAllowed ASIに使用されるでしょう。
5.2.2. Generating An Outgoing Response
5.2.2. 外向的な応答を生成します。
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情報に存在していなければなりません。
5.2.3. Generating An Outgoing Notification
5.2.3. 送信する通知を生成します。
In a multi-lingual SNMP entity, the parameters used for generating notifications will be obtained by examining the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB. These parameters will be passed to the SNMPv1 Message Processing Model using the sendPdu ASI. The SNMPv1 Message Processing Model will attempt to locate an appropriate community string in the snmpCommunityTable based on the parameters passed to the sendPdu ASI. This is done by performing a search through the snmpCommunityTable in lexicographic order. The first entry for which the following matching criteria are satisfied will be selected:
多言語SNMP実体では、SNMP-TARGET-MIBとSNMP-NOTIFICATION-MIBを調べることによって、通知を生成するのに使用されるパラメタを得るでしょう。 これらのパラメタは、sendPdu ASIを使用することでSNMPv1 Message Processing Modelに通過されるでしょう。 SNMPv1 Message Processing Modelは、sendPdu ASIに通過されたパラメタに基づくsnmpCommunityTableで適切な共同体ストリングの場所を見つけるのを試みるでしょう。 辞書式順序でsnmpCommunityTableを通した検索を実行することによって、これをします。 以下の合っている評価基準が満たされている初記入は選択されるでしょう:
- The securityName must be equal to the snmpCommunitySecurityName
value.
- securityNameはsnmpCommunitySecurityName値と等しいに違いありません。
- The contextEngineID must be equal to the
snmpCommunityContextEngineID value.
- contextEngineIDはsnmpCommunityContextEngineID値と等しいに違いありません。
- The contextName must be equal to the snmpCommunityContextName
value.
- contextNameはsnmpCommunityContextName値と等しいに違いありません。
Frye, et al. Best Current Practice [Page 29] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[29ページ]RFC3584Coexistence
- 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コラムの値になるでしょう。
5.2.4. Proxy Forwarding Of Requests
5.2.4. 要求のプロキシ推進
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 Message Processing Modelを使用することで進めることであることのプロキシ推進アプリケーションでは、SNMP-PROXY-MIBとSNMP-TARGET-MIBを調べることによって、推進に使用されるパラメタを得るでしょう。 これらのパラメタは、sendPdu ASIを使用することでSNMPv1 Message Processing Modelに通過されるでしょう。 SNMPv1 Message Processing Modelは、sendPdu ASIに通過されたパラメタに基づくsnmpCommunityTableで適切な共同体ストリングの場所を見つけるのを試みるでしょう。 辞書式順序でsnmpCommunityTableを通した検索を実行することによって、これをします。 以下の合っている評価基準が満たされている初記入は選択されるでしょう:
- The securityName must be equal to the snmpCommunitySecurityName
value.
- securityNameはsnmpCommunitySecurityName値と等しいに違いありません。
- The contextEngineID must be equal to the
snmpCommunityContextEngineID value.
- contextEngineIDはsnmpCommunityContextEngineID値と等しいに違いありません。
- The contextName must be equal to the snmpCommunityContextName
value.
- contextNameはsnmpCommunityContextName値と等しいに違いありません。
If no such entry can be found, the proxy forwarding application should follow the procedure described in RFC 3413 [RFC3413], section 3.5.1.1, item (2). This procedure states that the snmpProxyDrops counter [RFC3418] is incremented, and that a Response-PDU is generated by calling the Dispatcher using the returnResponsePdu abstract service interface.
どれかそのようなエントリーがそうすることができないなら、見つけられてください、とプロキシ推進アプリケーションは続くべきです。手順はRFC3413[RFC3413]、セクション3.5.1で.1について説明しました、項目(2)。 この手順はsnmpProxyDropsカウンタ[RFC3418]が増加されていて、DispatcherをreturnResponsePduの抽象的なサービスインタフェースを使用すると呼ぶことによってResponse-PDUが生成されると述べます。
5.3. The SNMP Community MIB Module
5.3. SNMP共同体MIBモジュール
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
SNMP-COMMUNITY-MIBは共同体ストリングとバージョンから独立しているSNMPメッセージの間でパラメタを写像するためのオブジェクトを含んでいます。 さらに、このMIBは入って来る要求にソースアドレス合法化を実行して、送信する通知のためにあて先アドレスに基づく共同体ストリングを選択するのにメカニズムを提供します。 これらの2
Frye, et al. Best Current Practice [Page 30] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[30ページ]RFC3584Coexistence
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.
特徴は、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)で、snmpTargetAddrTableの選択されたエントリーは複数のアドレス(まさしく1エントリーあたり1つのただ一つのアドレスよりむしろ)を指定できます。 これは、まさしくただ一つのアドレスよりむしろsnmpTargetAddrTableでサブネットを指定するのに通常使用されるでしょう。 マスク値は輸送アドレスのどのビットがsnmpTargetAddrTAddressの対応するインスタンスのビットに合わなければならないかを選択するのに使用されます、輸送アドレスがsnmpTargetAddrTableで特定のエントリーに合うように。 いつもsnmpTargetAddrTMaskのインスタンスの値は長さがsnmpTargetAddrTAddressの対応するインスタンスのものとゼロか同じくらいであるOCTET STRINGでなければなりません。
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.
輸送アドレスがsnmpTargetAddrTMaskの値が無の長さのOCTET STRINGであるならsnmpTargetAddrTableでエントリーに合っているかどうかチェックするとき、マスク値は無視されます、そして、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実体に許容できる最大のメッセージサイズを決定するのに使用されます。
Frye, et al. Best Current Practice [Page 31] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[31ページ]RFC3584Coexistence
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
SNMP共同体MIB定義:、:= 始まってください。
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、モジュールアイデンティティ、オブジェクト・タイプ、Integer32、SNMPv2-SMI RowStatusからのsnmpModules、SNMPv2-Tc SnmpAdminStringからのStorageType、SNMPフレームワークMIB SnmpTagValueからのSnmpEngineID(SNMP目標MIBモジュールコンプライアンスからのsnmpTargetAddrEntry)はSNMPv2-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 MODULE-IDENTITY LAST-UPDATED"200308060000Z"--2003年8月6日、真夜中の組織「SNMPv3ワーキンググループ」コンタクトインフォメーションは「以下をWGメールします」。 snmpv3@lists.tislabs.com は申し込まれます: msgボディーの 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
共同議長: ラス・マンディ・スパルタと、Inc郵便: 7075年のサミュエルモースDrive MD21045コロンビア(米国)EMail: 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
共同議長: デヴィッドハリントンEnterasysがネットワークでつなぐ、郵便: 35の産業方法、私書箱5005ニューハンプシャー03866-5005ロチェスター(米国)はメールされます: dbh@enterasys.com 電話: +1 603-337-2614
Co-editor: Rob Frye
Vibrant Solutions
共同エディタ: ロブ・フライVibrantのソリューション
Frye, et al. Best Current Practice [Page 32] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[32ページ]RFC3584Coexistence
Postal: 2711 Prosperity Ave
Fairfax, Virginia 22031
USA
E-mail: rfrye@vibrant-1.com
Phone: +1-703-270-2000
郵便: 2711 繁栄Aveフェアファクス、ヴァージニア22031米国メール: rfrye@vibrant-1.com 電話: +1-703-270-2000
Co-editor: David B. Levi
Nortel Networks
Postal: 3505 Kesterwood Drive
Knoxville, Tennessee 37918
E-mail: dlevi@nortelnetworks.com
Phone: +1 865 686 0432
共同エディタ: デヴィッドB.レビノーテルがネットワークでつなぐ、郵便: ノクスビル、テネシー 37918がメールする3505年のKesterwoodドライブ: dlevi@nortelnetworks.com 電話: +1 865 686 0432
Co-editor: Shawn A. Routhier
Wind River Systems, Inc.
Postal: 500 Wind River Way
Alameda, CA 94501
E-mail: sar@epilogue.com
Phone: +1 510 749 2095
共同エディタ: ショーンA.Routhierは水系Inc.郵便で曲がりくねっています: 500の風の川の方法に、アラメダ、カリフォルニア 94501はメールされます: sar@epilogue.com 電話: +1 510 749 2095
Co-editor: Bert Wijnen
Lucent Technologies
Postal: Schagen 33
3461 GL Linschoten
Netherlands
Email: bwijnen@lucent.com
Phone: +31-348-407-775
"
共同エディタ: バートWijnenルーセントテクノロジーズ郵便: Schagen33 3461GLリンスホーテン・オランダはメールされます: 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) インターネット協会(2003)に版権を取らせてください。このMIBモジュールのこのバージョンはRFC3584の一部です。 「完全な法定の通知に関して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.
REVISION"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
'snmpTargetAddrMMS'の記述をアップデートします。
Frye, et al. Best Current Practice [Page 33] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[33ページ]RFC3584Coexistence
clarify that a value of 0 means that the maximum
message size is unknown.
はっきりさせてください。0の値は、最大のメッセージサイズが未知であることを意味します。
Changed the name of 'snmpCommunityGroup' to
snmpCommunityTableGroup to avoid a name conflict
with the SNMPv2-MIB.
SNMPv2-MIBとの名前衝突を避けるために、名前'snmpCommunityGroup'をsnmpCommunityTableGroupに変えました。
Updated DESCRIPTION of snmpCommunityName.
snmpCommunityNameの記述をアップデートしました。
Updated DESCRIPTION of snmpTrapCommunity.
snmpTrapCommunityの記述をアップデートしました。
Added snmpCommunityMIBFullCompliance.
snmpCommunityMIBFullComplianceを加えました。
This version published as RFC 3584."
「RFC3584として発行されたこのバージョン。」
REVISION "200003060000Z" -- 6 Mar 2000
DESCRIPTION "This version published as RFC 2576."
REVISION"200003060000Z"--「このバージョンはRFC2576として発行した」2000年3月6日の記述。
::= { snmpModules 18 }
::= snmpModules18
-- Administrative assignments ************************************
-- 管理課題************************************
snmpCommunityMIBObjects
OBJECT IDENTIFIER ::= { snmpCommunityMIB 1 }
snmpCommunityMIBObjectsオブジェクト識別子:、:= snmpCommunityMIB1
snmpCommunityMIBConformance
OBJECT IDENTIFIER ::= { snmpCommunityMIB 2 }
snmpCommunityMIBConformanceオブジェクト識別子:、:= snmpCommunityMIB2
-- -- 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は共同体--ストリングに関するデータベースを含んでいます。 パラメタがViewベースのAccessに必要です--このテーブルは共同体--ストリングの間にマッピングを供給します、そして、コントロール。 --
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 }
「共同体ストリングのテーブルはSNMPエンジンのLocal Configuration Datastore(LCD)で構成した」snmpCommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF SnmpCommunityEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= snmpCommunityMIBObjects1
snmpCommunityEntry OBJECT-TYPE
SYNTAX SnmpCommunityEntry
MAX-ACCESS not-accessible
STATUS current
snmpCommunityEntry OBJECT-TYPE SYNTAX SnmpCommunityEntryのマックス-ACCESSのアクセスしやすくないSTATUS海流
Frye, et al. Best Current Practice [Page 34] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[34ページ]RFC3584Coexistence
DESCRIPTION
"Information about a particular community string."
INDEX { IMPLIED snmpCommunityIndex }
::= { snmpCommunityTable 1 }
「特定の共同体に関する情報は結ぶ」記述。 暗示しているsnmpCommunityIndexに索引をつけてください:、:= snmpCommunityTable1
SnmpCommunityEntry ::= SEQUENCE {
snmpCommunityIndex SnmpAdminString,
snmpCommunityName OCTET STRING,
snmpCommunitySecurityName SnmpAdminString,
snmpCommunityContextEngineID SnmpEngineID,
snmpCommunityContextName SnmpAdminString,
snmpCommunityTransportTag SnmpTagValue,
snmpCommunityStorageType StorageType,
snmpCommunityStatus RowStatus
}
SnmpCommunityEntry:、:= 系列snmpCommunityIndex SnmpAdminString、snmpCommunityName八重奏ストリング、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 }
「これの行のユニークなインデックス値はテーブルの上に置く」snmpCommunityIndex OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .32))のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= snmpCommunityEntry1
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 }
snmpCommunityName OBJECT-TYPE SYNTAX OCTET STRINGマックス-ACCESSは「このテーブルのどのa行が構成を表すように、共同体は結ぶ」STATUSの現在の記述を読書して作成します。 「RFC1157が少しの明白な制限も共同体ストリングの長さに課さないので(それらのサイズは間接的にSNMPメッセージサイズによって抑制されます)このオブジェクトに指定されたSIZE規制が全くありません。」 ::= snmpCommunityEntry2
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 }
snmpCommunitySecurityName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .32))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「Security Modelの独立している形式のsnmpCommunityNameの換算値を表す人間の読み込み可能なストリング。」 ::= snmpCommunityEntry3
snmpCommunityContextEngineID OBJECT-TYPE
snmpCommunityContextEngineIDオブジェクト・タイプ
Frye, et al. Best Current Practice [Page 35] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[35ページ]RFC3584Coexistence
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.
SYNTAX SnmpEngineIDマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「共同体ストリングを使用するとき経営情報がアクセスされている文脈の位置を示すcontextEngineIDはsnmpCommunityNameの対応するインスタンスで指定しました」。
The default value is the snmpEngineID of the entity in
which this object is instantiated."
::= { snmpCommunityEntry 4 }
「デフォルト値はこのオブジェクトが例示される実体のsnmpEngineIDです。」 ::= snmpCommunityEntry4
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 }
snmpCommunityContextName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(0 .32))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「共同体ストリングを使用するとき経営情報がアクセスされている文脈はsnmpCommunityNameの対応するインスタンスで指定しました」。 DEFVAL、「H、--空は以下を結びます:、」= snmpCommunityEntry5
snmpCommunityTransportTag OBJECT-TYPE
SYNTAX SnmpTagValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object specifies a set of transport endpoints
which are used in two ways:
- to specify the transport endpoints from which an
SNMP entity will accept management requests, and
- to specify the transport endpoints to which a
notification may be sent using the community
string matching the corresponding instance of
snmpCommunityName.
In either case, if the value of this object has
zero-length, transport endpoints are not checked when
either authenticating messages containing this community
string, nor when generating notifications.
snmpCommunityTransportTag OBJECT-TYPE SYNTAX SnmpTagValueマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトは2つの方法で使用される1セットの輸送終点を指定します」。 - そして、SNMP実体が管理要求を受け入れる輸送終点を指定するために--snmpCommunityNameの対応するインスタンスに合っている共同体ストリングが通知を使用させられるかもしれない輸送終点を指定するために。 この共同体ストリングを含むメッセージを認証するとき、どちらの場合ではも、このオブジェクトの値にゼロ・レングスがあるなら、輸送終点はチェックされません、または、どんないつも通知を生成しないで。
The transports identified by this object are specified
in the snmpTargetAddrTable. Entries in that table
whose snmpTargetAddrTagList contains this tag value
are identified.
このオブジェクトによって特定された輸送はsnmpTargetAddrTableで指定されます。 snmpTargetAddrTagListがこのタグ値を含むそのテーブルのエントリーは特定されます。
If a management request containing a community string
経営者側が共同体が結ぶ含有を要求するなら
Frye, et al. Best Current Practice [Page 36] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[36ページ]RFC3584Coexistence
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の対応するインスタンスが受け取られる輸送終点以外の輸送終点が特定したそのマッチはこのオブジェクトによってunauthenticされます要求が考えられる。
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 }
「通知がこのテーブルでエントリーを使用させることであるときに、通知の目的地輸送終点がこのオブジェクトによって選択された輸送終点の1つに合っていないなら、通知を送りません。」 DEFVAL、「H、--空は以下を結びます:、」= snmpCommunityEntry6
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 }
snmpCommunityStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「これに、概念的なストレージタイプはsnmpCommunityTableでこぐ」STATUSの現在の記述を読書して作成します。 「'永久的'に値を持っている概念的な行は行でいずれにもアクセスを書いている円柱状のオブジェクトを許容する必要はありません。」 ::= snmpCommunityEntry7
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マックス-ACCESSは「これほど概念的の状態はsnmpCommunityTableでこぐ」STATUSの現在の記述を読書して作成します。
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.
すべての対応するコラムのインスタンスがデフォルト値を通して、または、Set操作を通して初期化されるまで、このテーブルのエントリーは起動に資格がありません。 snmpCommunityNameとsnmpCommunitySecurityNameオブジェクトは明らかに用意ができなければなりません。
There is no restriction on setting columns in this table
when the value of snmpCommunityStatus is active(1)."
::= { snmpCommunityEntry 8 }
「snmpCommunityStatusの値がアクティブな(1)であるときにこのテーブルにコラムをはめ込むときの制限が全くありません。」 ::= snmpCommunityEntry8
-- -- The snmpTargetAddrExtTable --
-- -- snmpTargetAddrExtTable--
snmpTargetAddrExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
SnmpTargetAddrExtEntryのsnmpTargetAddrExtTableオブジェクト・タイプ構文系列
Frye, et al. Best Current Practice [Page 37] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[37ページ]RFC3584Coexistence
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of mask and maximum message size (mms) values
associated with the snmpTargetAddrTable.
「マスクと最大のメッセージサイズ(mms)値のテーブルはsnmpTargetAddrTableに関連づけた」マックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
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 }
輸送アドレスマスク価値と最大のメッセージサイズ価値に従って、snmpTargetAddrExtTableはsnmpTargetAddrTableを増大させます。 輸送アドレスマスクで、snmpTargetAddrTableのエントリーはまさしくただ一つのアドレスの代わりに1セットのアドレスを定義できます。 「最大のメッセージサイズ価値は、別のSNMP実体の最大のメッセージサイズがSNMPv1(そして、SNMPv2c)トランザクションにおける使用のために構成されるのを許容します、メッセージ・フォーマットが最大のメッセージサイズを指定しないところで。」 ::= snmpCommunityMIBObjects2
snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrExtTable 1 }
「特定のマスクとmmsに関する情報は評価する」snmpTargetAddrExtEntry OBJECT-TYPE SYNTAX SnmpTargetAddrExtEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 snmpTargetAddrEntryを増大させます:、:= snmpTargetAddrExtTable1
SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
}
SnmpTargetAddrExtEntry:、:= 系列snmpTargetAddrTMask八重奏ストリング、snmpTargetAddrMMS Integer32
snmpTargetAddrTMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The mask value associated with an entry in the
snmpTargetAddrTable. The value of this object must
have the same length as the corresponding instance of
snmpTargetAddrTAddress, or must have length 0. An
attempt to set it to any other value will result in
an inconsistentValue error.
snmpTargetAddrTMask OBJECT-TYPE SYNTAX OCTET STRING(SIZE(0 .255))マックス-ACCESSは「マスク値はsnmpTargetAddrTableのエントリーに関連づけた」STATUSの現在の記述を読書して作成します。 このオブジェクトの値には、snmpTargetAddrTAddressの対応するインスタンスと同じ長さを持たなければならないか、または長さ0がなければなりません。 いかなる他の値にもそれを設定する試みはinconsistentValue誤りをもたらすでしょう。
The value of this object allows an entry in the
snmpTargetAddrTable to specify multiple addresses.
The mask value is used to select which bits of
a transport address must match bits of the corresponding
instance of snmpTargetAddrTAddress, in order for the
このオブジェクトの値で、snmpTargetAddrTableのエントリーは複数のアドレスを指定できます。 マスク値は、輸送アドレスのビットがsnmpTargetAddrTAddressの対応するインスタンスのビットに合わなければなりません、どれのためにオーダーで選択するのに使用されます。
Frye, et al. Best Current Practice [Page 38] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[38ページ]RFC3584Coexistence
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で特定のエントリーに合ってください。 マスク値において1であるビットはsnmpTargetAddrTAddress値でビットに合わなければならない輸送アドレスでビットを示します。 マスクの0であるビットは合う必要はない輸送アドレスでビットを示します。 マスクの長さが0であるなら、snmpTargetAddrTableの換算値の長さに同輩がいるなら、マスクはまるですべてのビットが1とその長さであるかのように扱われるでしょうに。
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 }
このオブジェクトはsnmpTargetAddrRowStatusの対応するインスタンスの値がアクティブな(1)である間、変更されないかもしれません。 「この場合このオブジェクトを設定する試みはinconsistentValue誤りをもたらすでしょう。」 DEFVAL、「H、:、:、」= snmpTargetAddrExtEntry1
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 }
snmpTargetAddrMMS OBJECT-TYPE SYNTAX Integer32、(0|484 .2147483647) マックス-ACCESSは「最大のメッセージサイズ価値はsnmpTargetAddrTableのエントリーに関連づけた」STATUSの現在の記述を読書して作成します。 「0の値が、最大のメッセージサイズが未知であることを意味することに注意してください。」 DEFVAL484:、:= snmpTargetAddrExtEntry2
-- -- The snmpTrapAddress and snmpTrapCommunity objects are included -- in notifications that are forwarded by a proxy, which were -- originally received as SNMPv1 Trap messages. --
-- -- snmpTrapAddressとsnmpTrapCommunityオブジェクトはプロキシによって進められて、そうする通知に元々SNMPv1 Trapメッセージとして受け取られていた状態で含まれています。 --
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 }
snmpTrapAddress OBJECT-TYPE SYNTAX IpAddressマックス-ACCESS、アクセスしやすい、通知、STATUSの現在の記述、「SNMPv1以外のSNMPバージョンを使用しながらプロキシ混載業者のアプリケーションで進められるTrap PDUのエージェント-addr分野の値。」 「SNMPv1エージェントによって生成されるようにこのオブジェクトSHOULDの値はオリジナルのTrap PDUからのエージェント-addr分野の値を含んでいます。」 ::= snmpCommunityMIBObjects3
Frye, et al. Best Current Practice [Page 39] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[39ページ]RFC3584Coexistence
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 }
snmpTrapCommunity OBJECT-TYPE SYNTAX OCTET STRINGマックス-ACCESS、アクセスしやすい、通知、「SNMPv1以外のSNMPバージョンを使用しながらaプロキシ混載業者のアプリケーションで進められるTrap PDUを含んでいて、SNMPv1の共同体文字列欄の値は通信させる」STATUSの現在の記述。 このオブジェクトSHOULDの値はSNMPv1エージェントによって生成されるようにTrap PDUを含むオリジナルのSNMPv1メッセージからの共同体文字列欄の値を含んでいます。 「RFC1157が少しの明白な制限も共同体ストリングの長さに課さないので(それらのサイズは間接的にSNMPメッセージサイズによって抑制されます)このオブジェクトに指定されたSIZE規制が全くありません。」 ::= snmpCommunityMIBObjects4
-- Conformance Information **************************************
-- 順応情報**************************************
snmpCommunityMIBCompliances OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 1 }
snmpCommunityMIBGroups OBJECT IDENTIFIER
::= { snmpCommunityMIBConformance 2 }
snmpCommunityMIBCompliancesオブジェクト識別子:、:= snmpCommunityMIBConformance1snmpCommunityMIBGroupsオブジェクト識別子:、:= snmpCommunityMIBConformance2
-- Compliance statements
-- 承諾声明
snmpCommunityMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB."
snmpCommunityMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「SNMP-COMMUNITY-MIBを実装するSNMPエンジンのための承諾声明。」
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
MODULE--このモジュールMANDATORY-GROUPSsnmpCommunityTableGroup
OBJECT snmpCommunityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityName MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT snmpCommunitySecurityName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunitySecurityName MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT snmpCommunityContextEngineID
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextEngineID MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
Frye, et al. Best Current Practice [Page 40] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[40ページ]RFC3584Coexistence
OBJECT snmpCommunityContextName
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityContextName MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT snmpCommunityTransportTag
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityTransportTag MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT snmpCommunityStorageType
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStorageType MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT snmpCommunityStatus
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT snmpCommunityStatus MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
::= { snmpCommunityMIBCompliances 1 }
::= snmpCommunityMIBCompliances1
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 }
「SNMPのための承諾声明はSNMPv2cかSNMPv3を使用することで罠をSNMPv1に送りながら、できるプロキシ推進アプリケーションを含むものに蒸気機関を備えている」snmpProxyTrapForwardCompliance MODULE-COMPLIANCE STATUSの現在の記述。 MODULE--このモジュールMANDATORY-GROUPS snmpProxyTrapForwardGroup:、:= snmpCommunityMIBCompliances2
snmpCommunityMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP engines which
implement the SNMP-COMMUNITY-MIB with full read-create
access."
snmpCommunityMIBFullCompliance MODULE-COMPLIANCE STATUSの現在の記述、「完全でSNMP-COMMUNITY-MIBを実装するSNMPエンジンのための承諾声明はアクセサリーを読書して作成します」。
MODULE -- this module
MANDATORY-GROUPS { snmpCommunityTableGroup }
::= { snmpCommunityMIBCompliances 3 }
MODULE--このモジュールMANDATORY-GROUPS snmpCommunityTableGroup:、:= snmpCommunityMIBCompliances3
snmpCommunityTableGroup OBJECT-GROUP
OBJECTS {
snmpCommunityName,
snmpCommunitySecurityName,
snmpCommunityContextEngineID,
snmpCommunityContextName,
snmpCommunityTransportTag,
snmpCommunityStorageType,
snmpCommunityTableGroupオブジェクト群対象、snmpCommunityName、snmpCommunitySecurityName、snmpCommunityContextEngineID、snmpCommunityContextName、snmpCommunityTransportTag、snmpCommunityStorageType
Frye, et al. Best Current Practice [Page 41] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[41ページ]RFC3584Coexistence
snmpCommunityStatus,
snmpTargetAddrTMask,
snmpTargetAddrMMS
}
STATUS current
DESCRIPTION
"A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 }
snmpCommunityStatus、snmpTargetAddrTMask、snmpTargetAddrMMS 「オブジェクトが共同体の構成に備える収集はSNMPv1(そして、SNMPv2c)用法のために結ぶ」STATUSの現在の記述。 ::= snmpCommunityMIBGroups1
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 }
snmpProxyTrapForwardGroup OBJECT-GROUP OBJECTS、snmpTrapAddress、snmpTrapCommunity、STATUSの現在の記述、「SNMPバージョンの間の罠を翻訳するとき、代理人を通してアプリケーションを転送するのにおいて使用されたオブジェクト。」 「これらはSNMPv2cかSNMPv3に翻訳するとき、SNMPv1-特殊情報を保存するのに使用されます。」 ::= snmpCommunityMIBGroups3
END
終わり
6. Intellectual Property Statement
6. 知的所有権声明
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はどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を扱ってください。
Frye, et al. Best Current Practice [Page 42] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[42ページ]RFC3584Coexistence
7. Acknowledgments
7. 承認
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)
ジェフCase(SNMP研究Inc.) デヴィッド・ハリントン(Enterasysネットワーク)・デヴィッド・レビ(ノーテルネットワーク)・ブライアン・オキーフ(ヒューレットパッカード)ジョンSaperia(IronBridgeはInc.をネットワークでつなぎます) スティーブWaldbusser(国際ネットワークサービス)
8. Security Considerations
8. セキュリティ問題
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に写像されるのを許容するのがunsecured SNMPv1とSNMPv2操作のアクセスを制限するのに視点ベースのアクセスコントロールを使用する能力を提供します。 事実上、ネットワーク管理者がこの能力を利用するのは、そうでなければ安全なMIBデータへの不正アクセスを避けるために重要です。
When a proxy implementation translates messages between SNMPv1 (or SNMPv2c) and SNMPv3, there may be a loss of security. For example, an SNMPv3 message received using authentication and privacy which is subsequently forwarded using SNMPv1 will lose the security benefits of using authentication and privacy (also known as confidentiality). Careful configuration of proxies is required to address such situations. One approach to deal with such situations might be to use an encrypted tunnel.
プロキシ実装がSNMPv1(または、SNMPv2c)とSNMPv3の間のメッセージを翻訳するとき、セキュリティの損失があるかもしれません。 例えば、認証を使用することで受け取られたSNMPv3メッセージと次にSNMPv1を使用することで進められるプライバシーは認証とプライバシー(また、秘密性として、知られている)を使用するセキュリティ利益を失うでしょう。 プロキシの慎重な構成が、そのような状況を扱うのに必要です。 そのような状況に対処する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:
aがあります。読書して書くことのマックス-ACCESS節でこのMIBモジュールで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
- The snmpCommunityTable allows creation and deletion of community
strings, which is potentially a serious security hole. Access to
this table should be greatly restricted, preferably by only
allowing write access using SNMPv3 VACM and USM, with
authentication and privacy.
- snmpCommunityTableは共同体ストリングの作成と削除を許します。(それは、潜在的に深刻なセキュリティーホールです)。 このテーブルへのアクセスは大いに制限されるべきであり、望ましくは、許容するだけによって、SNMPv3 VACMとUSMを使用することでアクセスを書いてください、認証とプライバシーで。
- The snmpTargetAddrExtTable contains write-able objects which may
also be considered sensitive, and so access to it should be
restricted as well.
- snmpTargetAddrExtTableがまた、敏感であると考えられるかもしれない書きできるオブジェクトを含んでいるので、また、それへのアクセスは制限されるべきです。
Frye, et al. Best Current Practice [Page 43] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[43ページ]RFC3584Coexistence
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モジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
- 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を使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこの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).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
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バージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.
[RFC1155] ローズ、M.、K.McCloghrie、および「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and C. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, RFC
1157, May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびC.デーヴィン(「簡単なネットワーク管理プロトコル(SNMP)」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, Eds., "Concise MIB
Definitions", STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、Eds、「簡潔なMIB定義」、STD16、RFC1212、3月1991日
Frye, et al. Best Current Practice [Page 44] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[44ページ]RFC3584Coexistence
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[RFC1303] McCloghrie, K. and M. Rose, "A Convention for Describing
SNMP-based Agents", RFC 1303, February 1992.
[RFC1303]McCloghrieとK.とM.ローズ、「SNMPベースのエージェントについて説明するためのコンベンション」、RFC1303、1992年2月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1901] ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
RFC 2578, STD 58, April 1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」RFC2578、STD58(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3411] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411、2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
[RFC3412] ケース、J.、ハリントン、D.、Presuhn、R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、STD62、RFC3412、2002年12月。
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
[RFC3413] レビとD.とマイヤーとP.とB.スチュワート、「簡単なネットワーク管理プロトコル(SNMP)アプリケーション」、STD62、RFC3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security
Model (USM) for Version 3 of the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3414, December
2002.
[RFC3414] ブルーメンソル、U.、およびB.Wijnen、「簡単なネットワークマネージメントのバージョン3のためのユーザベースのセキュリティモデル(USM)は(SNMP)について議定書の中で述べます」、STD62、RFC3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
[RFC3415] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、2002年12月。
Frye, et al. Best Current Practice [Page 45] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[45ページ]RFC3584Coexistence
[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.(エド)、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMPv2)について議定書の中で述べます」、STD62、RFC3416、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.(エド)、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、STD62、RFC3417、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.(エド)、「簡単なネットワークマネージメントのバージョン2のための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、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]情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
9.2. Informative References
9.2. 有益な参照
[RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC
1908, January 1996.
[RFC1908]ケースとJ.とMcCloghrieとK.、ローズとM.とS.Waldbusser、「インターネット標準ネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存」RFC1908(1996年1月)。
[RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1
within a bilingual SNMP agent", RFC 2089, January 1997.
[RFC2089] レビとD.とB.Wijnen、「バイリンガルSNMPエージェントの中でSNMPv2をSNMPv1に写像する」RFC2089、1997年1月。
[RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
RFC 2576, March 2000.
[RFC2576]フライとR.とレビとD.、RouthierとS.とB.Wijnen、「インターネット標準ネットワークマネージメントフレームワークのバージョン1と、バージョン2と、バージョン3の間の共存」RFC2576(2000年3月)。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケースとJ.とマンディとR.とパーテイン、D.とB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」RFC3410(2002年12月)。
Frye, et al. Best Current Practice [Page 46] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[46ページ]RFC3584Coexistence
Appendix A. Change Log
付録A.チェンジログ
A.1. Changes From RFC 2576
A.1。 RFC2576からの変化
Section numbers below refer to the old section numbers from RFC 2576. Some section numbers have changed since RFC 2576.
以下のセクション番号はRFC2576から古いセクション番号を示します。 RFC2576以来いくつかのセクション番号が変化しています。
- Added text to abstract about conversion of MIBs from SMIv1 to
SMIv2.
- MIBsのSMIv1からSMIv2までの変換に関する要約にテキストを追加しました。
- 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として'MIBデータへのSNMPv3アクセス'なんてものがないセクション1.4の端の加えられたテキストはただSNMPv2 PDUタイプとプロトコル操作を使用します。
- Moved section 1.4 to the beginning of section 4.
- セクション4の始まりまでセクション1.4を動かしました。
- Changed "MUST" to "SHOULD" in item (3) of the first list in
Section 2.1.1 to since unconstrained INTEGER is not actually
illegal in SMIv2.
- 自由な整数以来1つの番目ものの(3)がセクション2.1.1で記載する項目の“SHOULD"への変えられた“MUST"は実際にSMIv2で不法ではありません。
- Changed "SHOULD" to "MUST" in item (13) of the first list in
Section 2.1.1 to clarify that collecting related objects into
groups is required when translating a MIB module from SMIv1 to
SMIv2.
- SMIv1からSMIv2までMIBモジュールを翻訳するとき、関連するオブジェクトをグループに集めながらそれをはっきりさせるセクション2.1.1における最初のリストの項目(13)の“MUST"への変えられた“SHOULD"が必要です。
- 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.
- RFC1303によってSMIv2と定義された言語から能力声明を翻訳するとき、本当に、それらのアップデート以来のセクション2.3の項目(1)と(2)の“MUST"への変えられた“SHOULD"が必要です。
- 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.
- snmpTrapOIDパラメタが2番目の変項束縛の値の部分(名前部分でない)を呼んで、セクション3.2の弾丸(1)の下の「snmpTrapOID」から「snmpTrapOID値」までのテキストの言葉遣いを変えたSNMPv2通知パラメタをリストアップして、はっきりさせられたセクション3の最後の部分の2番目の弾丸では、このポイントを強調してください。
- 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の可変結合がsnmpTrapOID.0あたり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
- はっきりさせられたセクション4.2では、その'上流のバージョン'はコマンドジェネレータか通知受信機の間で使用されるバージョンとプロキシについて言及します、そして、'川下のバージョン'は参照されます。
Frye, et al. Best Current Practice [Page 47] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[47ページ]RFC3584Coexistence
version used between the proxy and the command responder or
notification originator. RFC 2576 neglected to mention the
notification receiver and notification originator.
プロキシとコマンド応答者か通知創始者の間で使用されるバージョン。 RFC2576は、通知受信機と通知創始者について言及するのを忘れました。
- 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.
- 続く小区分は唯一SNMPv2を使用するコマンド応答者に関係があることに注意するためにSNMPv2cかSNMPv3メッセージと再言い表された最終節を処理するとき、MIBデータSHOULD NOTへのSNMPv1アクセスが使用されることに注意するセクション4.1.2の加えられたテキストでは、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.
- セクションでは、誤りインデックス部をあるに違いない.1がはっきりさせた4.2で、'tooBig'のエラー状況で翻訳されたGetResponse-PDUのゼロにセットして、一度だけGetBulkRequest-PDUを再試行するための原理は明白になりました。
- Added text to the Deployment Hint in Section 4.2.2 to clarify that
different principals should be used for SNMPv1 requests and
SNMPv2/v3c requests if for SNMPv1 requests a principal for which
Counter64 objects are not-in-view is used.
- SNMPv1要求において、Counter64オブジェクトが視点でない元本が使用されているならはっきりさせるセクション4.2.2におけるDeploymentヒントへの異なった主体がそうするべきであるテキストがSNMPv1要求と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.
- scopedPDUのsecurityNameが評価するはっきりさせられたセクション5.2.1、contextSnmpEngineID、およびcontextNameでは、値はsnmpCommunityTableの選択されたエントリーから来ます。 また、maxSizeResponseScopedPDUが断固としていて、そのsecurityStateReferenceがどうオリジナルの要求の共同体ストリングを含まなければならないかをはっきりさせました。
- Added Section 5.2.4 on Proxy Forwarding Of Requests.
- 加えられたセクション5.2 .4 要求のプロキシ推進に関して。
- In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored
whenever its use is not explicitly called for.
- はっきりさせられたセクション5.3では、使用が明らかに求められないときはいつも、そのsnmpTargetAddrTMaskは無視されることになっています。
- Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and
added a copyright notice to the DESCRIPTION clause of the MIB
module's MODULE-IDENTITY invocation.
- LAST-UPDATED、CONTACT-INFO、およびREVISION節をアップデートして、MIBモジュールのMODULE-IDENTITY実施の記述節に版権情報を追加しました。
- Added text to DESCRIPTION of snmpCommunityName and
snmpTrapCommunity to clarify why the object has no size
restriction.
- オブジェクトにはサイズ制限が全くなぜないかをはっきりさせるためにsnmpCommunityNameとsnmpTrapCommunityの記述にテキストを加えました。
- Updated the description of snmpCommunityTransportTag to make it
consistent with the rest of the document.
- それをドキュメントの残りと一致するようにするようにsnmpCommunityTransportTagの記述をアップデートしました。
- Updated the description of 'snmpTargetAddrMMS' to clarify that a
value of 0 means that the maximum message size is unknown.
- 最大のメッセージサイズが0つの手段の値ですが、それをはっきりさせる'snmpTargetAddrMMS'未知の記述をアップデートしました。
Frye, et al. Best Current Practice [Page 48] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[48ページ]RFC3584Coexistence
- 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.
- 参照をNormative ReferencesとInformative Referenceに分割して、現在のドキュメントを示すために彼らをアップデートしました。
- Inserted current year into all copyright notices.
- すべての版権情報に本年度を挿入しました。
- Corrected various typographical and grammatical errors.
- 直っている様々な印刷的、そして、文法的な誤り。
A.2. Changes Between RFC 1908 and RFC 2576
A.2。 RFC1908とRFC2576の間の変化
- Editorial changes to comply with current RFC requirements.
- 社説は、現在のRFC要件に従うために変化します。
- Added/updated copyright statements.
- 著作権宣言文を加えたか、またはアップデートしました。
- Added Intellectual Property section.
- Intellectual Property部を加えました。
- Replaced old introduction with complete new introduction/overview.
- 古い序論を完全な新しい序論/概要に取り替えました。
- Added content for the Security Considerations Section.
- Security Considerationsセクションのための内容を加えました。
- Updated References to current documents.
- 現在のドキュメントにReferencesをアップデートしました。
- 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 Message Processing Models、SNMPv1、およびSNMPv2c CommunityベースのSecurity Modelsのために記述を加えました。
- 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は、次にアクセスに使用できるSNMPバージョン無党派パラメタにそのSNMPv1とSNMPv2共同体ストリングを写像できるように標準のSNMPv3 ViewベースのAccess Control Modelと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.
- 加えられた2MIBが反対するので、SNMPv1通知(罠)をSNMPv2通知に変換しなければならないとき、私たちは起因しているSNMPv1エージェントのアドレスと共同体の情報を保存するためにそれらの2個のオブジェクトを加えます。
- Included (and extended) from RFC 2089 the SNMPv2 to SNMPv1 mapping
within a multi-lingual SNMP Engine.
- RFC2089から多言語SNMP Engineの中のSNMPv1マッピングにSNMPv2を含めました(そして、広がっています)。
Frye, et al. Best Current Practice [Page 49] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[49ページ]RFC3584Coexistence
- Use keywords from RFC 2119 to describe requirements for
compliance.
- RFC2119からのキーワードを使用して、承諾のための要件について説明してください。
- Changed/added some rules for converting a MIB module from SMIv1 to
SMIv2.
- SMIv1からSMIv2までMIBモジュールを変換するためのいくつかの規則を変えたか、または加えました。
- Extended and improved the description of Proxy Forwarder behaviour
when multiple SNMP versions are involved.
- 複数のSNMPバージョンがかかわるとき、Proxy Forwarderのふるまいの記述を広げて、改良しました。
Editors' Addresses
エディタのアドレス
Rob Frye Vibrant Solutions 2711 Prosperity Ave Fairfax, Virginia 22031 U.S.A.
ロブ・フライ・敏感なソリューション2711繁栄Aveヴァージニア22031フェアファクス(米国)
Phone: +1 703 270 2000 EMail: rfrye@vibrant-1.com
以下に電話をしてください。 +1 2000年の703 270メール: rfrye@vibrant-1.com
David B. Levi Nortel Networks 3505 Kesterwood Drive Knoxville, TN 37918 U.S.A.
デヴィッドB.レビノーテルは3505Kesterwood Driveテネシー37918ノクスビル(米国)をネットワークでつなぎます。
Phone: +1 865 686 0432 EMail: dlevi@nortelnetworks.com
以下に電話をしてください。 +1 0432年の865 686メール: dlevi@nortelnetworks.com
Shawn A. Routhier Wind River Systems, Inc. 500 Wind River Way Alameda, CA 94501 U.S.A.
ショーンA.Routhierが500の風の川の方法アラメダ(カリフォルニア)94501で水系Inc.を巻き上げする、米国
Phone: + 1 510 749 2095 EMail: sar@epilogue.com
以下に電話をしてください。 2095がメールする+1 510 749: sar@epilogue.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten Netherlands
バートWijnenルーセントテクノロジーズSchagen33 3461GLリンスホーテン・オランダ
Phone: +31 348 407 775 EMail: bwijnen@lucent.com
以下に電話をしてください。 +31 348 407 775はメールされます: bwijnen@lucent.com
Frye, et al. Best Current Practice [Page 50] RFC 3584 Coexistence between SNMP versions August 2003
フライ、他 SNMPバージョン2003年8月の間の最も良いCurrent Practice[50ページ]RFC3584Coexistence
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Frye, et al. Best Current Practice [Page 51]
フライ、他 最も良い現在の習慣[51ページ]
一覧
スポンサーリンク
