RFC1908 日本語訳

Network Working Group                               SNMPv2 Working Group
Request for Comments: 1908                                       J. Case
Obsoletes: 1452                                      SNMP Research, Inc.
Category: Standards Track                                  K. McCloghrie
                                                     Cisco Systems, Inc.
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                          International Network Services
                                                            January 1996

コメントを求めるワーキンググループSNMPv2ワーキンググループ要求をネットワークでつないでください: 1908年のJ.ケースは時代遅れにします: 1452年のSNMP研究Inc.カテゴリ: 標準化過程K.McCloghrieシスコシステムズInc.M.はドーヴァービーチコンサルティングInc.S.Waldbusser国際ネットワークサービス1996年1月に上昇しました。

           Coexistence between Version 1 and Version 2 of the
             Internet-standard Network Management Framework

インターネット標準ネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Table of Contents

目次

   1. Introduction ................................................    2
   2. Management Information ......................................    2
   2.1 Object Definitions .........................................    3
   2.2 Trap Definitions ...........................................    5
   2.3 Compliance Statements ......................................    5
   2.4 Capabilities Statements ....................................    6
   3 Protocol Operations ..........................................    6
   3.1 Proxy Agent Behavior .......................................    6
   3.1.1 SNMPv2 -> SNMPv1 .........................................    7
   3.1.2 SNMPv1 -> SNMPv2 .........................................    7
   3.2 Bi-lingual Manager Behavior ................................    8
   4. Security Considerations .....................................    8
   5. Editor's Address ............................................    8
   6. Acknowledgements ............................................    8
   7. References ..................................................    9

1. 序論… 2 2. 管理情報… 2 2.1 オブジェクト定義… 3 2.2 罠定義… 5 2.3 承諾声明… 5 2.4の能力声明… 6 3は操作について議定書の中で述べます… 6 3.1 プロキシエージェントの振舞い… 6 3.1 .1 SNMPv2->SNMPv1… 7 3.1 .2 SNMPv1->SNMPv2… 7 3.2 バイリンガルマネージャの振舞い… 8 4. セキュリティ問題… 8 5. エディタのアドレス… 8 6. 承認… 8 7. 参照… 9

SNMPv2 Working Group        Standards Track                     [Page 1]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[1ページ]RFC1908共存

1.  Introduction

1. 序論

   The purpose of this document is to describe coexistence between
   version 2 of the Internet-standard Network Management Framework [1-
   6], termed the SNMP version 2 framework (SNMPv2), and the original
   Internet-standard Network Management Framework (SNMPv1), which
   consists of these three documents:

このドキュメントの目的はSNMPバージョン2フレームワーク(SNMPv2)と呼ばれたインターネット標準Network Management Framework[1- 6]のバージョン2とこれらの3通のドキュメントから成る元のインターネット標準Network Management Framework(SNMPv1)の間の共存について説明することです:

      STD 16, RFC 1155 [7] which defines the Structure of Management
      Information (SMI), the mechanisms used for describing and naming
      objects for the purpose of management.

STD16、Management情報(SMI)のStructureを定義するRFC1155[7]、メカニズムは説明と命名に管理の目的のためのオブジェクトを使用しました。

      STD 16, RFC 1212 [8] which defines a more concise description
      mechanism, which is wholly consistent with the SMI.

STD16、完全にSMIと一致したより簡潔な記述メカニズムを定義するRFC1212[8]。

      STD 15, RFC 1157 [9] which defines the Simple Network Management
      Protocol (SNMP), the protocol used for network access to managed
      objects.

STD15、Simple Network Managementプロトコル(SNMP)(管理オブジェクトへのネットワークアクセスに使用されるプロトコル)を定義するRFC1157[9]。

2.  Management Information

2. 経営情報

   The SNMPv2 approach towards describing collections of managed objects
   is nearly a proper superset of the approach defined in the Internet-
   standard Network Management Framework.  For example, both approaches
   use ASN.1 [10] as the basis for a formal descriptive notation.
   Indeed, one might note that the SNMPv2 approach largely codifies the
   existing practice for defining MIB modules, based on extensive
   experience with the current framework.

管理オブジェクトの収集について説明することに向かったSNMPv2アプローチはほとんどインターネットの標準のNetwork Management Frameworkで定義されたアプローチの適切なスーパーセットです。 例えば、両方のアプローチは正式な描写的である記法の基礎としてASN.1[10]を使用します。 本当に、人は、SNMPv2アプローチがMIBモジュールを定義するために既存の習慣を主に成文化することに注意するかもしれません、現在のフレームワークの広範囲の経験に基づいて。

   The SNMPv2 documents which deal with information modules are:

情報モジュールに対処するSNMPv2ドキュメントは以下の通りです。

     Structure of Management Information for SNMPv2 [1], which defines
     concise notations for describing information modules, managed
     objects and notifications;

情報モジュール、管理オブジェクト、および通知について説明するための簡潔な記法を定義するSNMPv2[1]のためのManagement情報の構造。

     Textual Conventions for SNMPv2 [2], which defines a concise
     notation for describing textual conventions, and also defines some
     initial conventions; and,

SNMPv2[2]のための原文のConventions(SNMPv2は原文のコンベンションについて説明するための簡潔な記法を定義して、また、いくつかの初期のコンベンションを定義します)。 そして

     Conformance Statements for SNMPv2 [3], which defines concise
     notation for describing compliance and capabilities statements.

SNMPv2[3]のための順応Statements。(SNMPv2はコンプライアンスと能力声明について説明するための簡潔な記法を定義します)。

   The following sections consider the three areas:  MIB modules,
   compliance statements, and capabilities statements.

以下のセクションは3つの領域を考えます: MIBモジュール、承諾声明、および能力声明。

   MIB modules defined using the current framework may continue to be
   used with the SNMPv2 protocol.  However, for the MIB modules to
   conform to the SNMPv2 framework, the following changes are required:

現在のフレームワークを使用することで定義されたMIBモジュールは、SNMPv2プロトコルと共に使用され続けるかもしれません。 しかしながら、MIBモジュールがSNMPv2フレームワークに従うために、以下の変化が必要です:

SNMPv2 Working Group        Standards Track                     [Page 2]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[2ページ]RFC1908共存

2.1.  Object Definitions

2.1. オブジェクト定義

   In general, conversion of a MIB module does not require the
   deprecation of the objects contained therein.  Only if the semantics
   of an object truly changes should deprecation be performed.

一般に、MIBモジュールの変換はそこに含まれたオブジェクトの不賛成を必要としません。 オブジェクトの意味論が本当に変化する場合にだけ、不賛成は実行されるべきですか?

(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 descriptor which contains the hyphen character, the hyphen
     character is removed.

(3) ハイフンキャラクタを含むどんな記述子に関してはも、ハイフンキャラクタは外されます。

(4)  For any label for a named-number enumeration which contains the
     hyphen character, the hyphen character is removed.

(4) ハイフンキャラクタを含む命名された数の列挙のためのどんなラベルに関してはも、ハイフンキャラクタは外されます。

(5)  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
     must have the value of its SYNTAX clause changed to Integer32.

(5) そして、対応するINTEGERが範囲制限を持っていない整数で評価されたSYNTAX節でのどんなオブジェクト、も(すなわち、INTEGERには定義されたセットの名前付の数の列挙も課題も、より低くない、値に関する上限)、オブジェクトで、SYNTAX節の値はInteger32に変わらなければなりません。

(6)  For any object with a SYNTAX clause value of an enumerated INTEGER,
     the hyphen character is removed from any named-number labels which
     contain the hyphen character.

(6) 列挙されたINTEGERのSYNTAX節価値があるどんなオブジェクトに関してはも、ハイフンキャラクタはハイフンキャラクタを含むどんな命名された数のラベルからも外されます。

(7)  For any object with a SYNTAX clause value of Counter, the object
     must have the value of its SYNTAX clause changed to Counter32.

(7) CounterのSYNTAX節価値があるどんなオブジェクトに関してはも、オブジェクトで、SYNTAX節の値はCounter32に変わらなければなりません。

(8)  For any object with a SYNTAX clause value of Gauge, the object must
     have the value of its SYNTAX clause changed to Gauge32.

(8) GaugeのSYNTAX節価値があるどんなオブジェクトに関してはも、オブジェクトで、SYNTAX節の値はGauge32に変わらなければなりません。

(9)  For all objects, the ACCESS clause must be replaced by a MAX-ACCESS
     clause.  The value of the MAX-ACCESS clause is 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, will 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 is "read-write", and the DESCRIPTION clause
     notes that reading this object will result implementation-specific
     results.

(9) すべてのオブジェクトに関しては、ACCESS節をマックス-ACCESS節に取り替えなければなりません。 ある他の値がオブジェクトのための最大限度のアクセスのレベルとして「プロトコル感覚」を作らない場合、マックス-ACCESS節の値はACCESS節のものと同じです。 インスタンスがどれについてプロトコルセット操作で明らかに作成できて、マックス-ACCESS節を持つように、特に、オブジェクトはタイプされるか。「読書して作成します」。 ACCESS節の値がそうである、「書く、-単に、」、そして、マックス-ACCESS節の値は、「読書して書いてください」と、このオブジェクトを読むのは結果実装詳細結果がそうするという記述節メモです。

(10) For all objects, if the value of the STATUS clause is "mandatory",
     the value must be replaced with "current".

(10) すべてのオブジェクトに関しては、STATUS節の値が「義務的である」なら、値を「電流」に取り替えなければなりません。

SNMPv2 Working Group        Standards Track                     [Page 3]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[3ページ]RFC1908共存

(11) For all objects, if the value of the STATUS clause is "optional",
     the value must be replaced with "obsolete".

(11) すべてのオブジェクトに関して、STATUS節の値が「任意である」なら、値を「時代遅れ」に取り替えなければなりません。

(12) For any object not containing a DESCRIPTION clause, the object must
     have a DESCRIPTION clause defined.

(12) 記述節を含まないどんなオブジェクトに関してはも、オブジェクトには、定義された記述節がなければなりません。

(13) 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.

(13) INDEX節を持っていない概念的な行に対応するどんなオブジェクトに関してはも、オブジェクトは節が定義したINDEX節かAUGMENTSのどちらかを持たなければなりません。

(14) For any object with an INDEX clause that references an object with
     a syntax of NetworkAddress, the value of the STATUS clause of both
     objects is changed to "obsolete".

(14) いずれに関してはも、「時代遅れにする」ために変わるNetworkAddressの構文、両方のSTATUS節の値があるオブジェクトが参照を反対させるINDEX節で、反対してください。

(15) For any object containing a DEFVAL clause with an OBJECT IDENTIFIER
     value which is expressed as a collection of sub-identifiers, change
     the value to reference a single ASN.1 identifier.

(15) サブ識別子の収集として言い表されるOBJECT IDENTIFIER値があるDEFVAL節を含むあらゆるオブジェクトに関しては、値を変えて、ただ一つのASN.1識別子に参照をつけてください。

Other changes are desirable, but not necessary:

他の変化は、望ましいのですが、必要ではありません:

(1)  Creation and deletion of conceptual rows is inconsistent using the
     current framework.  The SNMPv2 framework 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 it may be worthwhile to deprecate the objects
     relating to those tables and replace them with objects defined
     using the new approach.

(1) 概念的な行の作成と削除は現在のフレームワークを使用するのにおいて無節操です。 SNMPv2フレームワークはこれを修正します。 そういうものとして、MIBモジュールが早く一代でレビューを受けて、概念的な行の作成と削除を許す概念的なテーブルを含んでいるなら、それらのテーブルに関連するオブジェクトを非難して、それらを新しいアプローチを使用することで定義されたオブジェクトに取り替える価値があるかもしれません。

(2)  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), one might consider defining the bounds for the size of
     the object.

(2) そして、対応するOCTET STRINGがサイズ制限を持っていないストリングで評価されたSYNTAX節でのどんなオブジェクト、も(すなわち、OCTET STRINGには課題が全くより低くない、長さに関する上限)、人は、オブジェクトのサイズのために領域を定義すると考えるかもしれません。

(3)  For all textual conventions informally defined in the MIB module,
     one might consider redefining those conventions using the TEXTUAL-
     CONVENTION macro.  Such a change would not necessitate deprecating
     objects previously defined using an informal textual convention.

(3) MIBモジュールで非公式に定義されたすべての原文のコンベンションに関しては、人は、TEXTUAL- CONVENTIONマクロを使用することでそれらのコンベンションを再定義すると考えるかもしれません。 そのような変化は、以前に非公式の原文のコンベンションを使用することで定義されたオブジェクトを非難するのを必要としないでしょう。

(4)  For any object which represents a measurement in some kind of
     units, one might consider adding a UNITS clause to the definition
     of that object.

(4) ある種のユニットにおける測定を表すどんなオブジェクトに関してはも、人は、そのオブジェクトの定義にUNITS節を加えると考えるかもしれません。

(5)  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,
     one might consider using an AUGMENTS clause in place of the INDEX
     clause for the object corresponding to the conceptual row which is

(5) どの下位の円柱状のオブジェクトが何か別の概念的な行の拡大である概念的な行、すなわち、存在していて、もう片方の概念的な行と同じ意味論で特定されるかに関しては、人は、概念的なそうする行に対応するオブジェクトのためのINDEX節に代わってAUGMENTS節を使用すると考えるかもしれません。

SNMPv2 Working Group        Standards Track                     [Page 4]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[4ページ]RFC1908共存

     an extension.

拡大。

Finally, when encountering common errors in SNMPv1 MIB modules:

SNMPv1 MIBモジュールで最終的に一般的な誤りに遭遇するとき:

(1)  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 is changed to "obsolete".

(1) どんな非円柱状のオブジェクトに関してはも、まるでそれがすぐに概念的な行(そのオブジェクトの節が「時代遅れにする」ために変わるSTATUSの値)に下位であるかのようにそれは例証されます。

(2)  For any conceptual row object that is not contained immediately
     subordinate to a conceptual table, the value of the STATUS clause
     of that object (and all subordinate objects) is changed to
     "obsolete".

(2) すぐに含まれていないあらゆる概念的な行オブジェクトに関しては、概念的なテーブルを従属してください、そのオブジェクト(そして、すべての下位オブジェクト)の節が「時代遅れにする」ために変わるSTATUSの値。

2.2.  Trap Definitions

2.2. 罠定義

   If a MIB module is changed to conform to the SNMPv2 framework, then
   each occurrence of the TRAP-TYPE macro must be changed to a
   corresponding invocation of the NOTIFICATION-TYPE macro:

SNMPv2フレームワークに従うためにMIBモジュールを変えるなら、TRAP-TYPEマクロの各発生はNOTIFICATION-TYPEマクロの対応する実施に変わらなければなりません:

   (1)  The IMPORTS statement must not reference RFC-1215.

(1) 参照RFC-1215ではなく、声明がそうしなければならないIMPORTS。

   (2)  The ENTERPRISES clause must be removed.

(2) エンタープライズ節を取り除かなければなりません。

   (3)  The VARIABLES clause must be renamed to the OBJECTS clause.

(3) VARIABLES節をOBJECTS節に改名しなければなりません。

   (4)  The STATUS clause must be added.

(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 is 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.

(5) NOTIFICATION-TYPEマクロの実施の値をINTEGERではなく、OBJECT IDENTIFIERであり、それに従って、変えなければなりません。 明確に、エンタープライズ節の値が'snmp'でないなら、実施の値は2つのサブ識別子で広げられたエンタープライズ節の値です、そして、2番目には、TRAP-TYPEの実施の値があります。その1番目には、値0があります。

2.3.  Compliance Statements

2.3. 承諾声明

   For those information modules which are "standard", a corresponding
   invocation of the MODULE-COMPLIANCE macro 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
   must be removed.  Typically this editing can occur when the
   information module undergoes review.

それらの「標準であること」の情報モジュールにおいて情報モジュール(または仲間情報モジュールで)の中にMODULE-COMPLIANCEマクロの対応する実施を含まなければなりません、そして、コンプライアンスに関連する情報モジュールによるどんな論評テキストも取り除かなければなりません。 情報モジュールがレビューを受けるとき、通常、この編集は起こることができます。

SNMPv2 Working Group        Standards Track                     [Page 5]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[5ページ]RFC1908共存

2.4.  Capabilities Statements

2.4. 能力声明

   In the current framework, the informational document [11] uses the
   MODULE-CONFORMANCE macro to describe an agent's capabilities with
   respect to one or more MIB modules.  Converting such a description
   for use with the SNMPv2 framework requires these changes:

現在のフレームワークでは、情報のドキュメント[11]は、1つ以上のMIBモジュールに関してエージェントの能力について説明するのにMODULE-CONFORMANCEマクロを使用します。 SNMPv2フレームワークで使用のためのそのような記述を変換するのはこれらの変化を必要とします:

   (1)  Use the macro name AGENT-CAPABILITIES instead of MODULE-
        CONFORMANCE.

(1) MODULE- CONFORMANCEの代わりにマクロ名エージェント-CAPABILITIESを使用してください。

   (2)  The STATUS clause must be added.

(2) STATUS節を加えなければなりません。

   (3)  For all occurrences of the CREATION-REQUIRES clause, note the
        slight change in semantics, and omit this clause if appropriate.

(3) CREATION-REQUIRES節のすべての発生によって、意味論における小変化に注意してください、そして、適切であるなら、この節を省略してください。

   In order to ease the coexistence between SNMPv1 and SNMPv2, object
   groups defined in an SNMPv1 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 SNMPv1 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 a SNMPv1 MIB have different sets of mandatory objects
   under the same subtree; in such cases, the only solution is to
   rewrite the MIB using the SNMPv2 SMI in order to define the object
   groups unambiguously.)

SNMPv1とSNMPv2の間の共存を緩和するために、SNMPv1 MIBモジュールで定義されたオブジェクトグループはエージェント-CAPABILITIESマクロの実施のINCLUDES節によって参照をつけられるかもしれません: SNMPv1 MIBモジュールで定義されたOBJECT IDENTIFIER下位木の参照に遭遇すると、下位木に下位であり、義務的のSTATUS節価値を持っているすべての葉のオブジェクトがINCLUDEdであると考えられます。(SNMPv1 MIBの異なった改正が同じ下位木の下で異なったセットの義務的なオブジェクトを持っているとき、このメソッドがあいまいであることに注意してください; そのような場合、唯一のソリューションは明白にオブジェクトグループを定義するのにSNMPv2 SMIを使用することでMIBを書き直すことです。)

3.  Protocol Operations

3. プロトコル操作

   The SNMPv2 documents which deal with protocol operations are:

プロトコル操作に対処するSNMPv2ドキュメントは以下の通りです。

     Protocol Operations for SNMPv2 [4], which defines the syntax and
     semantics of the operations conveyed by the protocol; and,

SNMPv2[4]のためにOperationsについて議定書の中で述べてください。(SNMPv2はプロトコルによって伝えられた操作の構文と意味論を定義します)。 そして

     Transport Mappings for SNMPv2 [5], which defines how the protocol
     operations are carried over different transport services.

SNMPv2[5]のためにMappingsを輸送してください。(SNMPv2はプロトコル操作がどう異なった輸送サービスの上まで運ばれるかを定義します)。

   The following section considers two areas:  the proxy behavior
   between a SNMPv2 entity and a SNMPv1 agent; and, the behavior of
   "bi-lingual" protocol entities acting in a manager role.

以下のセクションは2つの領域を考えます: SNMPv2実体とSNMPv1エージェントの間のプロキシの振舞い。 そして、「バイリンガル」の振舞いはマネージャの役割で行動する実体について議定書の中で述べます。

3.1.  Proxy Agent Behavior

3.1. プロキシエージェントの振舞い

   To achieve coexistence at the protocol-level, a proxy mechanism may
   be used.  A SNMPv2 entity acting in an agent role may be implemented
   and configured to act in the role of a proxy agent.

プロトコルレベルで共存を達成するために、プロキシメカニズムは使用されるかもしれません。 エージェントの役割で行動するSNMPv2実体は、プロキシエージェントの役割で行動するために実装されて、構成されるかもしれません。

SNMPv2 Working Group        Standards Track                     [Page 6]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[6ページ]RFC1908共存

3.1.1.  SNMPv2 -> SNMPv1

3.1.1. SNMPv2->SNMPv1

   When converting requests from a SNMPv2 entity acting in a manager
   role into requests sent to a SNMPv1 entity acting in an agent role:

SNMPv2実体からの要求を変換するとき、マネージャの役割で要求に行動するのはエージェントの役割で行動するSNMPv1実体に発信しました:

   (1)  If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU is
        received, then it is passed unaltered by the proxy agent.

(1) GetRequest-PDU、GetNextRequest-PDU、またはSetRequest-PDUが受け取られているなら、プロキシエージェントによって非変更されて、それは通過されます。

   (2)  If a GetBulkRequest-PDU is received, the proxy agent sets the non-
        repeaters and max-repetitions fields to zero, and sets the tag of
        the PDU to GetNextRequest-PDU.

(2) GetBulkRequest-PDUが受け取られているなら、プロキシエージェントは、非リピータと最大反復分野をゼロに設定して、PDUのタグをGetNextRequest-PDUに設定します。

3.1.2.  SNMPv1 -> SNMPv2

3.1.2. SNMPv1->SNMPv2

   When converting responses received from a SNMPv1 entity acting in an
   agent role into responses sent to a SNMPv2 entity acting in a manager
   role:

変換するとき、応答はエージェントの役割でマネージャの役割で行動するSNMPv2実体に送られた応答に行動するSNMPv1実体から受信されました:

(1)  If a GetResponse-PDU is received, then it is passed unaltered by
     the proxy agent.  Note that even though a SNMPv2 entity will never
     generate a Response-PDU with a error-status field having a value of
     `noSuchName', `badValue', or `readOnly', the proxy agent must not
     change this field.  This allows the SNMPv2 entity acting in a
     manager role to interpret the response correctly.

(1) GetResponse-PDUが受け取られているなら、プロキシエージェントによって非変更されて、それは通過されます。 SNMPv2実体が'noSuchName'、'badValue'、または'readOnly'の値を持っているエラー状況分野があるResponse-PDUを決して生成しませんが、プロキシエージェントがこの分野を変えてはいけないことに注意してください。 これは正しく応答を解釈するためにマネージャの役割で行動するSNMPv2実体を許容します。

     If a GetResponse-PDU is received with an error-status field having
     a value of `tooBig', the proxy agent will remove the contents of
     the variable-bindings field before propagating the response.  Note
     that even though a SNMPv2 entity will never generate a `tooBig' in
     response to a GetBulkRequest-PDU, the proxy agent must propagate
     such a response.

'tooBig'の値を持っているエラー状況分野でGetResponse-PDUを受け取ると、応答を伝播する前に、プロキシエージェントは変項束縛分野のコンテンツを取り除くでしょう。 SNMPv2実体がGetBulkRequest-PDUに対応して'tooBig'を決して生成しませんが、プロキシエージェントがそのような応答を伝播しなければならないことに注意してください。

(2)  If a Trap-PDU is received, then it is mapped into a SNMPv2-Trap-
     PDU.  This is done by prepending onto the variable-bindings field
     two new bindings:  sysUpTime.0 [6], which takes its value from the
     timestamp field of the Trap-PDU; and, snmpTrapOID.0 [6], which is
     calculated thusly:  if the value of generic-trap field is
     `enterpriseSpecific', then the value used is the concatenation of
     the enterprise field from the Trap-PDU with two additional sub-
     identifiers, `0', and the value of the specific-trap field;
     otherwise, the value of the corresponding trap defined in [6] is
     used.  (For example, if the value of the generic-trap field is
     `coldStart', then the coldStart trap [6] is used.)  Then, one new
     binding is appended onto the variable-bindings field:
     snmpTrapEnterprise.0 [6], which takes its value from the enterprise
     field of the Trap-PDU.  The destinations for the SNMPv2-Trap-PDU
     are determined in an implementation-dependent fashion by the proxy
     agent.

(2) Trap-PDUが受け取られているなら、それはSNMPv2-罠PDUに写像されます。 2つの新しい結合を変項束縛フィールドにprependingすることによって、これをします: sysUpTime.0[6]([6]はTrap-PDUのタイムスタンプ分野から値を取ります)。 そして、snmpTrapOID.0[6]:([6]はこのようにして計算されます)。 ジェネリック罠分野の値が'enterpriseSpecific'であるなら、使用される値は特定の罠分野の2つの追加サブ識別子、'0'、および値があるTrap-PDUからの企業分野の連結です。 さもなければ、[6]で定義された対応する罠の値は使用されています。 (例えば、ジェネリック罠分野の値が'coldStart'であるなら、coldStart罠[6]は使用されています。) 次に、1つの新しい結合を変項束縛フィールドに追加します: snmpTrapEnterprise.0[6]。(その[6]はTrap-PDUの企業分野から値を取ります)。 SNMPv2がPDUを捕らえる目的地は実装依存するファッションでプロキシエージェントによって決定されます。

SNMPv2 Working Group        Standards Track                     [Page 7]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[7ページ]RFC1908共存

3.2.  Bi-lingual Manager Behavior

3.2. バイリンガルマネージャの振舞い

   To achieve coexistence at the protocol-level, a protocol entity
   acting in a manager role might support both SNMPv1 and SNMPv2.  When
   a management application needs to contact a protocol entity acting in
   an agent role, the entity acting in a manager role consults a local
   database to select the correct management protocol to use.

プロトコルレベルで共存を達成するために、マネージャの役割で行動するプロトコル実体はSNMPv1とSNMPv2の両方をサポートするかもしれません。 管理アプリケーションが、エージェントの役割で行動するプロトコル実体に連絡する必要があると、マネージャの役割で行動する実体は正しい管理プロトコルが使用するのを選択するローカルのデータベースに相談します。

   In order to provide transparency to management applications, the
   entity acting in a manager role must map operations as if it were
   acting as a proxy agent.

管理アプリケーションに透明を提供するために、マネージャの役割で行動する実体はまるでプロキシエージェントとして務めているかのように操作を写像しなければなりません。

4.  Security Considerations

4. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

5.  Editor's Address

5. エディタのアドレス

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   US

西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)

   Phone: +1 408 526 5260
   EMail: kzm@cisco.com

以下に電話をしてください。 +1 5260年の408 526メール: kzm@cisco.com

6.  Acknowledgements

6. 承認

   This document is the result of significant work by the four major
   contributors:

このドキュメントは4人の一流の貢献者による重要な仕事の結果です:

   Jeffrey D. Case (SNMP Research, case@snmp.com)
   Keith McCloghrie (Cisco Systems, kzm@cisco.com)
   Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
   Steven Waldbusser (International Network Services, stevew@uni.ins.com)

ジェフリーD.事件(SNMP研究、 case@snmp.com )キースMcCloghrie(シスコシステムズ、 kzm@cisco.com )マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング、 mrose@dbc.mtview.ca.us )スティーブンWaldbusser(国際ネットワークサービス、 stevew@uni.ins.com )

   In addition, the contributions of the SNMPv2 Working Group are
   acknowledged.  In particular, a special thanks is extended for the
   contributions of:

さらに、SNMPv2作業部会の貢献は承諾されます。 特に、以下の貢献のために特別な感謝を表します。

     Alexander I. Alten (Novell)
     Dave Arneson (Cabletron)
     Uri Blumenthal (IBM)
     Doug Book (Chipcom)
     Kim Curran (Bell-Northern Research)
     Jim Galvin (Trusted Information Systems)
     Maria Greene (Ascom Timeplex)

アレクサンダー・I.アルテン(ノベル)デーヴArneson(Cabletron)ユリ・ブルーメンソル(IBM)・ダグ・本の(Chipcom)キム・カラン(ベル-北研究)・ジム・ガルビン(情報システムを信じる)・マリア・グリーン(Ascom Timeplex)

SNMPv2 Working Group        Standards Track                     [Page 8]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[8ページ]RFC1908共存

     Iain Hanson (Digital)
     Dave Harrington (Cabletron)
     Nguyen Hien (IBM)
     Jeff Johnson (Cisco Systems)
     Michael Kornegay (Object Quest)
     Deirdre Kostick (AT&T Bell Labs)
     David Levi (SNMP Research)
     Daniel Mahoney (Cabletron)
     Bob Natale (ACE*COMM)
     Brian O'Keefe (Hewlett Packard)
     Andrew Pearson (SNMP Research)
     Dave Perkins (Peer Networks)
     Randy Presuhn (Peer Networks)
     Aleksey Romanov (Quality Quorum)
     Shawn Routhier (Epilogue)
     Jon Saperia (BGS Systems)
     Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

イアンハンソン(デジタル)のデーヴ・ハリントン(Cabletron)Nguyen Hien(IBM)ジェフ・ジョンソン(シスコシステムズ)マイケルKornegay(オブジェクト探索)ディアドラKostick(AT&Tベル研究所)デヴィッド・レビ(SNMP研究)・ダニエル・マホニー(Cabletron)ボブNatale(ACE*COMM)ブライアン・オキーフ(ヒューレットパッカード)アンドリューピアソン(SNMP研究)のデーヴ・パーキンス(同輩ネットワーク)ランディPresuhn(同輩ネットワーク)アレックセイ・ロマーノフ(上質の定足数)ショーンRouthier(エピローグ)ジョンSaperia(BGSシステム)ボブ・スチュワート(シスコシステムズ、 bstewart@cisco.com ); いすカイTesink(Bellcore)グレンWaters(ベル-北Research)バートWijnen(IBM)

7.  References

7. 参照

[1]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.

[1]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。

[2]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[2]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。

[3]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Conformance Statements for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.

[3]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための順応声明は(SNMPv2)について議定書の中で述べます」、RFC1904、1996年1月。

[4]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[4] SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。

[5]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Transport Mappings for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[5]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。

[6]  SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Management Information Base for Version 2 of the
     Simple Network Management Protocol (SNMPv2)", RFC 1907,
     January 1996.

[6]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2)」、RFC1907(1996年1月)。

SNMPv2 Working Group        Standards Track                     [Page 9]

RFC 1908         Coexistence between SNMPv1 and SNMPv2      January 1996

SNMPv1とSNMPv2 January 1996の間のSNMPv2ワーキンググループ標準化過程[9ページ]RFC1908共存

[7]  Rose, M., and K. McCloghrie, "Structure and Identification of
     Management Information for TCP/IP-based internets", STD 16, RFC
     1155, May 1990.

[7]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)

[8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
     RFC 1212, March 1991.

[8] ローズ、M.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。

[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
     Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
     Systems International, MIT Laboratory for Computer Science, May
     1990.

[9] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、STD15、RFC1157、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、1990年5月。

[10] Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).

[10] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)

[11] McCloghrie, K., and M. Rose, "A Convention for Describing SNMP-
     based Agents", RFC 1303, Hughes LAN Systems, Dover Beach
     Consulting, Inc., February 1992.

[11] McCloghrie、K.、およびM.ローズ、「Describing SNMPのためのConventionはエージェントを基礎づけました」、RFC1303、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、1992年2月。

SNMPv2 Working Group        Standards Track                    [Page 10]

SNMPv2ワーキンググループ標準化過程[10ページ]