RFC1906 日本語訳

Network Working Group                               SNMPv2 Working Group
Request for Comments: 1906                                       J. Case
Obsoletes: 1449                                      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ワーキンググループ要求をネットワークでつないでください: 1906年のJ.ケースは時代遅れにします: 1449年のSNMP研究Inc.カテゴリ: 標準化過程K.McCloghrieシスコシステムズInc.M.はドーヴァービーチコンサルティングInc.S.Waldbusser国際ネットワークサービス1996年1月に上昇しました。

                Transport Mappings for Version 2 of the
              Simple Network Management Protocol (SNMPv2)

簡単なネットワーク管理プロトコルのバージョン2のための輸送マッピング(SNMPv2)

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
   1.1 A Note on Terminology ......................................    2
   2. Definitions .................................................    3
   3. SNMPv2 over UDP .............................................    5
   3.1 Serialization ..............................................    5
   3.2 Well-known Values ..........................................    5
   4. SNMPv2 over OSI .............................................    6
   4.1 Serialization ..............................................    6
   4.2 Well-known Values ..........................................    6
   5. SNMPv2 over DDP .............................................    6
   5.1 Serialization ..............................................    6
   5.2 Well-known Values ..........................................    6
   5.3 Discussion of AppleTalk Addressing .........................    7
   5.3.1 How to Acquire NBP names .................................    8
   5.3.2 When to Turn NBP names into DDP addresses ................    8
   5.3.3 How to Turn NBP names into DDP addresses .................    8
   5.3.4 What if NBP is broken ....................................    9
   6. SNMPv2 over IPX .............................................    9
   6.1 Serialization ..............................................    9
   6.2 Well-known Values ..........................................    9
   7. Proxy to SNMPv1 .............................................   10
   8. Serialization using the Basic Encoding Rules ................   10
   8.1 Usage Example ..............................................   11

1. 序論… 2 1.1 用語に関する注… 2 2. 定義… 3 3. UDPの上のSNMPv2… 5 3.1連載… 5 3.2 よく知られる値… 5 4. OSIの上のSNMPv2… 6 4.1連載… 6 4.2 よく知られる値… 6 5. DDPの上のSNMPv2… 6 5.1連載… 6 5.2 よく知られる値… 6 5.3 AppleTalkアドレシングの議論… 7 5.3 .1、Acquire NBP名へのどのように… 8 5.3 .2 DDPアドレスへのTurn NBP名に… 8 5.3 .3 Turn NBPへのどのようにがアドレスをDDPと命名するか… 8 5.3 .4 NBPが壊れていると、どうなるだろうか… 9 6. IPXの上のSNMPv2… 9 6.1連載… 9 6.2 よく知られる値… 9 7. SNMPv1のプロキシ… 10 8. 基本的なコード化を使用する連載が統治されます… 10 8.1使用例… 11

SNMPv2 Working Group        Standards Track                     [Page 1]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[1ページ]RFC1906輸送マッピング

   9. Security Considerations .....................................   11
   10. Editor's Address ...........................................   12
   11. Acknowledgements ...........................................   12
   12. References .................................................   13

9. セキュリティ問題… 11 10. エディタのアドレス… 12 11. 承認… 12 12. 参照… 13

1.  Introduction

1. 序論

   A management system contains:  several (potentially many) nodes, each
   with a processing entity, termed an agent, which has access to
   management instrumentation; at least one management station; and, a
   management protocol, used to convey management information between
   the agents and management stations.  Operations of the protocol are
   carried out under an administrative framework which defines
   authentication, authorization, access control, and privacy policies.

マネージメントシステムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証、承認、アクセスコントロール、およびプライバシーに関する方針を定義する管理フレームワークの下で行われます。

   Management stations execute management applications which monitor and
   control managed elements.  Managed elements are devices such as
   hosts, routers, terminal servers, etc., which are monitored and
   controlled via access to their management information.

管理局は管理された要素をモニターして、制御する管理アプリケーションを作成します。 管理された要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。

   The management protocol, version 2 of the Simple Network Management
   Protocol [1], may be used over a variety of protocol suites.  It is
   the purpose of this document to define how the SNMPv2 maps onto an
   initial set of transport domains.  Other mappings may be defined in
   the future.

管理プロトコル(Simple Network Managementプロトコル[1]のバージョン2)はさまざまなプロトコル群にわたって使用されるかもしれません。 SNMPv2がどう1人の始発の輸送にドメインを写像するかを定義するのは、このドキュメントの目的です。 他のマッピングは将来、定義されるかもしれません。

   Although several mappings are defined, the mapping onto UDP is the
   preferred mapping.  As such, to provide for the greatest level of
   interoperability, systems which choose to deploy other mappings
   should also provide for proxy service to the UDP mapping.

いくつかのマッピングが定義されますが、UDPへのマッピングは都合のよいマッピングです。 また、そういうものとして、最も大きいレベルの相互運用性に備えるために、他のマッピングを配布するのを選ぶシステムはUDPマッピングへの代理業務に備えるはずです。

1.1.  A Note on Terminology

1.1. 用語に関する注

   For the purpose of exposition, the original Internet-standard Network
   Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
   15), and 1212 (STD 16), is termed the SNMP version 1 framework
   (SNMPv1).  The current framework is termed the SNMP version 2
   framework (SNMPv2).

博覧会の目的のために、RFCs1155(STD16)、1157年(STD15)、および1212年(STD16)に説明されるオリジナルのインターネット標準Network Management FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。

SNMPv2 Working Group        Standards Track                     [Page 2]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[2ページ]RFC1906輸送マッピング

2.  Definitions

2. 定義

SNMPv2-TM DEFINITIONS ::= BEGIN

SNMPv2-Tm定義:、:= 始まってください。

IMPORTS
    OBJECT-IDENTITY, snmpDomains, snmpProxys
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION
        FROM SNMPv2-TC;

SNMPv2-Tcからの原文のコンベンションのSNMPv2-SMIからオブジェクトアイデンティティ、snmpDomains、snmpProxysをインポートします。

-- SNMPv2 over UDP over IPv4

-- IPv4の上のUDPの上のSNMPv2

snmpUDPDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over UDP transport domain.  The corresponding
            transport address is of type SnmpUDPAddress."
    ::= { snmpDomains 1 }

snmpUDPDomain OBJECT-IDENTITY STATUSの現在の記述、「UDPの上のSNMPv2はドメインを輸送します」。 「タイプSnmpUDPAddressには対応する輸送アドレスがあります。」 ::= snmpDomains1

SnmpUDPAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d/2d"
    STATUS       current
    DESCRIPTION
            "Represents a UDP address:

SnmpUDPAddress:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"1d.1d.1d.1d/2d"STATUSの現在の記述、「UDPアドレスを表します:、」

               octets   contents        encoding
                1-4     IP-address      network-byte order
                5-6     UDP-port        network-byte order
            "
    SYNTAX       OCTET STRING (SIZE (6))

1-4 IP-アドレスネットワークバイトオーダー5-6UDP-ポートネットワークバイトオーダー「構文八重奏ストリング」をコード化する八重奏コンテンツ(サイズ(6))

-- SNMPv2 over OSI

-- OSIの上のSNMPv2

snmpCLNSDomain OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over CLNS transport domain.  The corresponding
            transport address is of type SnmpOSIAddress."
    ::= { snmpDomains 2 }

snmpCLNSDomain OBJECT-IDENTITY STATUSの現在の記述、「CLNSの上のSNMPv2はドメインを輸送します」。 「タイプSnmpOSIAddressには対応する輸送アドレスがあります。」 ::= snmpDomains2

snmpCONSDomain OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over CONS transport domain.  The corresponding
            transport address is of type SnmpOSIAddress."
    ::= { snmpDomains 3 }

snmpCONSDomain OBJECT-IDENTITY STATUSの現在の記述、「コンズの上のSNMPv2はドメインを輸送します」。 「タイプSnmpOSIAddressには対応する輸送アドレスがあります。」 ::= snmpDomains3

SNMPv2 Working Group        Standards Track                     [Page 3]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[3ページ]RFC1906輸送マッピング

SnmpOSIAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "*1x:/1x:"
    STATUS       current
    DESCRIPTION
            "Represents an OSI transport-address:

SnmpOSIAddress:、:= 「原文のコンベンションは」 *1x: /1xをディスプレイでほのめかします」 STATUSの現在の記述、「OSI輸送アドレスを表します:、」

               octets   contents           encoding
                  1     length of NSAP     'n' as an unsigned-integer
                                              (either 0 or from 3 to 20)
               2..(n+1) NSAP                concrete binary representation
               (n+2)..m TSEL                string of (up to 64) octets
            "
    SYNTAX       OCTET STRING (SIZE (1 | 4..85))

'八重奏コンテンツがNSAPの1つの長さをコード化する、'(3〜どちらかの0か20)2の符号のない整数として。(n+1) NSAPの具体的な2進法表示(n+2)。TSELが結ぶ(最大64)八重奏「構文八重奏ストリング」のm(サイズ(1| 4 .85))

-- SNMPv2 over DDP

-- DDPの上のSNMPv2

snmpDDPDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over DDP transport domain.  The corresponding
            transport address is of type SnmpNBPAddress."
    ::= { snmpDomains 4 }

snmpDDPDomain OBJECT-IDENTITY STATUSの現在の記述、「DDPの上のSNMPv2はドメインを輸送します」。 「タイプSnmpNBPAddressには対応する輸送アドレスがあります。」 ::= snmpDomains4

SnmpNBPAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Represents an NBP name:

SnmpNBPAddress:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「NBP名を表します:、」

                 octets        contents          encoding
                    1          length of object  'n' as an unsigned integer
                  2..(n+1)     object            string of (up to 32) octets
                   n+2         length of type    'p' as an unsigned integer
              (n+3)..(n+2+p)   type              string of (up to 32) octets
                  n+3+p        length of zone    'q' as an unsigned integer
            (n+4+p)..(n+3+p+q) zone              string of (up to 32) octets

'八重奏コンテンツが1つの長さのオブジェクトをコード化する、'符号のない整数2として。(n+1) 符号のない整数(n+3)としてのタイプ'p'の(最大32)八重奏のn+2長さのオブジェクトストリング。(n+2+p) 符号のない整数(n+4+p)としてゾーン'q'の(最大32)八重奏nの+3+pの長さのストリングをタイプしてください。(n+3+p+q) (最大32)八重奏のゾーンストリング

            For comparison purposes, strings are case-insensitive All
            strings may contain any octet other than 255 (hex ff)."
    SYNTAX       OCTET STRING (SIZE (3..99))

「比較目的のために、ストリングは大文字と小文字を区別しないAllストリングが255(十六進法ff)以外のどんな八重奏も含むかもしれないということです。」 構文八重奏ストリング(サイズ(3 .99))

-- SNMPv2 over IPX

-- IPXの上のSNMPv2

snmpIPXDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The SNMPv2 over IPX transport domain.  The corresponding

snmpIPXDomain OBJECT-IDENTITY STATUSの現在の記述、「IPXの上のSNMPv2はドメインを輸送します」。 対応

SNMPv2 Working Group        Standards Track                     [Page 4]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[4ページ]RFC1906輸送マッピング

            transport address is of type SnmpIPXAddress."
    ::= { snmpDomains 5 }

「タイプSnmpIPXAddressには輸送アドレスがあります。」 ::= snmpDomains5

SnmpIPXAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
    STATUS       current
    DESCRIPTION
            "Represents an IPX address:

SnmpIPXAddress:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「4x.1x:1x:1x:1x:1x: 1x.2d」STATUSの現在の記述、「IPXアドレスを表します:、」

               octets   contents            encoding
                1-4     network-number      network-byte order
                5-10    physical-address    network-byte order
               11-12    socket-number       network-byte order
            "
    SYNTAX       OCTET STRING (SIZE (12))

八重奏コンテンツコード化1-4ネットワーク・ナンバーネットワークバイトオーダー5-10物理アドレスネットワークバイトオーダー11-12ソケット番号ネットワークバイトオーダー「構文八重奏ストリング」(サイズ(12))

-- for proxy to SNMPv1 (RFC 1157)

-- SNMPv1のプロキシのために(RFC1157)

rfc1157Proxy   OBJECT IDENTIFIER ::= { snmpProxys 1 }

rfc1157Proxyオブジェクト識別子:、:= snmpProxys1

rfc1157Domain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The transport domain for SNMPv1 over UDP.  The
            corresponding transport address is of type SnmpUDPAddress."
    ::= { rfc1157Proxy 1 }

rfc1157Domain OBJECT-IDENTITY STATUSの現在の記述、「UDPの上のSNMPv1のための輸送ドメイン。」 「タイプSnmpUDPAddressには対応する輸送アドレスがあります。」 ::= rfc1157Proxy1

--  ::= { rfc1157Proxy 2 }            this OID is obsolete

-- ::= rfc1157Proxy2、このOIDは時代遅れです。

END

終わり

3.  SNMPv2 over UDP

3. UDPの上のSNMPv2

   This is the preferred transport mapping.

これは都合のよい輸送マッピングです。

3.1.  Serialization

3.1. 連載

   Each instance of a message is serialized (i.e., encoded according to
   the convention of [1]) onto a single UDP[2] datagram, using the
   algorithm specified in Section 8.

メッセージの各インスタンスは連載されます。(すなわち、[1])のコンベンションによると、単一のUDP[2]データグラムにコード化されています、アルゴリズムを使用するのはセクション8で指定しました。

3.2.  Well-known Values

3.2. よく知られる値

   It is suggested that administrators configure their SNMPv2 entities
   acting in an agent role to listen on UDP port 161.  Further, it is
   suggested that notification sinks be configured to listen on UDP port

管理者がUDPポート161の上で聴くためにエージェントの役割で行動する彼らのSNMPv2実体を構成することが提案されます。 さらに、通知流し台がUDPポートの上で聴くために構成されることが提案されます。

SNMPv2 Working Group        Standards Track                     [Page 5]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[5ページ]RFC1906輸送マッピング

   162.

162.

   When an SNMPv2 entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.

SNMPv2実体がこの輸送マッピングを使用するとき、それはサイズにおいて少なくとも484の八重奏であるメッセージを受け入れることができなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。

4.  SNMPv2 over OSI

4. OSIの上のSNMPv2

   This is an optional transport mapping.

これは任意の輸送マッピングです。

4.1.  Serialization

4.1. 連載

   Each instance of a message is serialized onto a single TSDU [3,4] for
   the OSI Connectionless-mode Transport Service (CLTS), using the
   algorithm specified in Section 8.

メッセージの各インスタンスはOSI Connectionless-モードTransport Service(CLTS)のために独身のTSDU[3、4]に連載されます、セクション8で指定されたアルゴリズムを使用して。

4.2.  Well-known Values

4.2. よく知られる値

   It is suggested that administrators configure their SNMPv2 entities
   acting in an agent role to listen on transport selector "snmp-l"
   (which consists of six ASCII characters), when using a CL-mode
   network service to realize the CLTS.  Further, it is suggested that
   notification sinks be configured to listen on transport selector
   "snmpt-l" (which consists of seven ASCII characters, six letters and
   a hyphen) when using a CL-mode network service to realize the CLTS.
   Similarly, when using a CO-mode network service to realize the CLTS,
   the suggested transport selectors are "snmp-o" and "snmpt-o", for
   agent and notification sink, respectively.

管理者がCLTSがわかるのにCL-モードネットワーク・サービスを使用するとき輸送セレクタの上に「snmp-l」(6人のASCII文字から成る)を聴くためにエージェントの役割で行動する彼らのSNMPv2実体を構成することが提案されます。 さらに、通知流し台がCLTSがわかるのにCL-モードネットワーク・サービスを使用するとき、輸送セレクタの上に「snmpt-l」(7人のASCII文字、6個の手紙、およびハイフンから成る)を聴くために構成されることが提案されます。 CLTSがわかるのにCO-モードネットワーク・サービスを使用するとき、同様に、提案された輸送セレクタは、"snmp-o"と"snmpt-o"です、エージェントと通知がそれぞれ沈むので。

   When an SNMPv2 entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.

SNMPv2実体がこの輸送マッピングを使用するとき、それはサイズにおいて少なくとも484の八重奏であるメッセージを受け入れることができなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。

5.  SNMPv2 over DDP

5. DDPの上のSNMPv2

   This is an optional transport mapping.

これは任意の輸送マッピングです。

5.1.  Serialization

5.1. 連載

   Each instance of a message is serialized onto a single DDP datagram
   [5], using the algorithm specified in Section 8.

セクション8で指定されたアルゴリズムを使用して、メッセージの各インスタンスは単一のDDPデータグラム[5]に連載されます。

5.2.  Well-known Values

5.2. よく知られる値

   SNMPv2 messages are sent using DDP protocol type 8.  SNMPv2 entities
   acting in an agent role listens on DDP socket number 8, whilst
   notification sinks listen on DDP socket number 9.

SNMPv2メッセージにDDPプロトコルタイプ8を使用させます。 エージェントの役割におけるSNMPv2実体芝居はDDPソケットNo.8で聴かれます、通知流し台がDDPソケットNo.9で聴かれますが。

SNMPv2 Working Group        Standards Track                     [Page 6]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[6ページ]RFC1906輸送マッピング

   Administrators must configure their SNMPv2 entities acting in an
   agent role to use NBP type "SNMP Agent" (which consists of ten ASCII
   characters), whilst notification sinks must be configured to use NBP
   type "SNMP Trap Handler" (which consists of seventeen ASCII
   characters).

管理者は、NBPを使用するためにエージェントの役割で行動する彼らのSNMPv2実体が「SNMPエージェント」(10人のASCII文字から成る)をタイプするのを構成しなければなりません、NBPタイプ「SNMP罠操作者」(17人のASCII文字から成る)を使用するために通知流し台を構成しなければなりませんが。

   The NBP name for agents and notification sinks should be stable - NBP
   names should not change any more often than the IP address of a
   typical TCP/IP node.  It is suggested that the NBP name be stored in
   some form of stable storage.

エージェントと通知流し台のためのNBP名は安定しているべきです--NBP名はもう典型的なTCP/IPノードのIPアドレスよりしばしば変化するべきであるというわけではありません。 NBP名が何らかの形式の安定貯蔵に保存されることが提案されます。

   When an SNMPv2 entity uses this transport mapping, it must be capable
   of accepting messages that are at least 484 octets in size.
   Implementation of larger values is encouraged whenever possible.

SNMPv2実体がこの輸送マッピングを使用するとき、それはサイズにおいて少なくとも484の八重奏であるメッセージを受け入れることができなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。

5.3.  Discussion of AppleTalk Addressing

5.3. AppleTalkアドレシングの議論

   The AppleTalk protocol suite has certain features not manifest in the
   TCP/IP suite.  AppleTalk's naming strategy and the dynamic nature of
   address assignment can cause problems for SNMPv2 entities that wish
   to manage AppleTalk networks.  TCP/IP nodes have an associated IP
   address which distinguishes each from the other.  In contrast,
   AppleTalk nodes generally have no such characteristic.  The network-
   level address, while often relatively stable, can change at every
   reboot (or more frequently).

AppleTalkプロトコル群で、ある特徴はTCP/IPスイートで現れるようになりません。 AppleTalkが戦略とアドレスのダイナミックな本質を課題と命名すると、AppleTalkネットワークを管理するというその願望はSNMPv2実体のための問題に引き起こされる場合があります。 TCP/IPノードには、もう片方とそれぞれを区別する関連IPアドレスがあります。 対照的に、一般に、AppleTalkノードには、どんなそのような特性もありません。 ネットワークの平らなアドレスはあらゆるリブート(より頻繁)のときにしばしば比較的安定している間、変化できます。

   Thus, when SNMPv2 is mapped over DDP, nodes are identified by a
   "name", rather than by an "address".  Hence, all AppleTalk nodes that
   implement this mapping are required to respond to NBP lookups and
   confirms (e.g., implement the NBP protocol stub), which guarantees
   that a mapping from NBP name to DDP address will be possible.

SNMPv2がDDPの上で写像されるとき、したがって、ノードは「アドレス」でというよりむしろ「名前」によって特定されます。 したがって、このマッピングを実装するすべてのAppleTalkノードが、NBPルックアップに応じるのが必要であり、どれが、NBP名からDDPアドレスまでのマッピングが可能になるのを保証するかと確認します(例えば、NBPプロトコルスタッブを実装します)。

   In determining the SNMP identity to register for an SNMPv2 entity, it
   is suggested that the SNMP identity be a name which is associated
   with other network services offered by the machine.

SNMPのアイデンティティがSNMPv2実体に登録することを決定する際に、SNMPのアイデンティティがマシンで提供する他のネットワーク・サービスに関連している名前であると示唆されます。

   NBP lookups, which are used to map NBP names into DDP addresses, can
   cause large amounts of network traffic as well as consume CPU
   resources.  It is also the case that the ability to perform an NBP
   lookup is sensitive to certain network disruptions (such as zone
   table inconsistencies) which would not prevent direct AppleTalk
   communications between two SNMPv2 entities.

NBPルックアップ(NBP名をDDPアドレスに写像するのに使用される)は、多量のネットワークトラフィックを引き起こして、CPUリソースを消費できます。 また、NBPルックアップを実行する能力が2つのSNMPv2実体のダイレクトAppleTalkコミュニケーションを防がない、あるネットワーク分裂(ゾーンテーブル矛盾などの)に敏感であることは、事実です。

   Thus, it is recommended that NBP lookups be used infrequently,
   primarily to create a cache of name-to-address mappings.  These
   cached mappings should then be used for any further SNMP traffic.  It
   is recommended that SNMPv2 entities acting in a manager role should
   maintain this cache between reboots.  This caching can help minimize

したがって、NBPルックアップが主として名前からアドレス・マッピングのキャッシュを作成するのにまれに使用されるのは、お勧めです。 そして、これらのキャッシュされたマッピングはどんなさらなるSNMPトラフィックにも使用されるべきです。 マネージャの役割で行動するSNMPv2実体がリブートの間のこのキャッシュを維持するのは、お勧めです。 缶が最小にするのを助けるこのキャッシュ

SNMPv2 Working Group        Standards Track                     [Page 7]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[7ページ]RFC1906輸送マッピング

   network traffic, reduce CPU load on the network, and allow for (some
   amount of) network trouble shooting when the basic name-to-address
   translation mechanism is broken.

トラフィックをネットワークでつないでくださいといって、ネットワークでCPU荷重を抑えてください、許容、(或るものが達する、)、名前からアドレス変換への基本的なメカニズムが壊れているときにはトラブルシューティングをネットワークでつないでください。

5.3.1.  How to Acquire NBP names

5.3.1. Acquire NBP名へのどのように

   An SNMPv2 entity acting in a manager role may have a pre-configured
   list of names of "known" SNMPv2 entities acting in an agent role.
   Similarly, an SNMPv2 entity acting in a manager role might interact
   with an operator.  Finally, an SNMPv2 entity acting in a manager role
   might communicate with all SNMPv2 entities acting in an agent role in
   a set of zones or networks.

マネージャの役割で行動するSNMPv2実体で、「知られている」SNMPv2実体のあらかじめ設定された名簿はエージェントの役割で行動するかもしれません。 同様に、マネージャの役割で行動するSNMPv2実体はオペレータと対話するかもしれません。 最終的に、マネージャの役割で行動するSNMPv2実体は1セットのゾーンかネットワークにおけるエージェントの役割で行動するすべてのSNMPv2実体で交信するかもしれません。

5.3.2.  When to Turn NBP names into DDP addresses

5.3.2. DDPアドレスへのTurn NBP名へのいつ

   When an SNMPv2 entity uses a cache entry to address an SNMP packet,
   it should attempt to confirm the validity mapping, if the mapping
   hasn't been confirmed within the last T1 seconds.  This cache entry
   lifetime, T1, has a minimum, default value of 60 seconds, and should
   be configurable.

SNMPv2実体がSNMPパケットを扱うのにキャッシュエントリーを使用すると、正当性マッピングを確認するのを試みるべきです、マッピングが最後のT1秒以内に確認されていないなら。 これは、エントリー生涯、T1をキャッシュして、最小限、60秒のデフォルト値を持って、構成可能であるべきです。

   An SNMPv2 entity acting in a manager role may decide to prime its
   cache of names prior to actually communicating with another SNMPv2
   entity.  In general, it is expected that such an entity may want to
   keep certain mappings "more current" than other mappings, e.g., those
   nodes which represent the network infrastructure (e.g., routers) may
   be deemed "more important".

マネージャの役割で行動するSNMPv2実体は、実際に別のSNMPv2実体で交信する前に名前のキャッシュを用意すると決めるかもしれません。 一般に、そのような実体が「他のマッピングより現在」に、あるマッピングを保ちたがっているかもしれないと予想されて、例えば、ネットワークインフラ(例えば、ルータ)を表すそれらのノードは「より重要である」と考えられるかもしれません。

   Note that an SNMPv2 entity acting in a manager role should not prime
   its entire cache upon initialization - rather, it should attempt
   resolutions over an extended period of time (perhaps in some pre-
   determined or configured priority order).  Each of these resolutions
   might, in fact, be a wildcard lookup in a given zone.

マネージャの役割で行動するSNMPv2実体が初期化のときに全体のキャッシュを用意するべきでないことに注意してください--むしろ、それは時間(恐らく何らかのプレ断固としたか構成された優先順による)の長期間の間、解決を試みるべきです。 事実上、それぞれのこれらの解決は与えられたゾーンのワイルドカードルックアップであるかもしれません。

   An SNMPv2 entity acting in an agent role must never prime its cache.
   Such an entity should do NBP lookups (or confirms) only when it needs
   to send an SNMP trap.  When generating a response, such an entity
   does not need to confirm a cache entry.

エージェントの役割で行動するSNMPv2実体はキャッシュを決して用意してはいけません。 そのような実体がNBPにルックアップをするべきである、(確認、)、SNMP罠を送る必要がある場合にだけ。 応答を生成するとき、そのような実体はキャッシュエントリーを確認する必要はありません。

5.3.3.  How to Turn NBP names into DDP addresses

5.3.3. DDPアドレスへのTurn NBP名へのどのように

   If the only piece of information available is the NBP name, then an
   NBP lookup should be performed to turn that name into a DDP address.
   However, if there is a piece of stale information, it can be used as
   a hint to perform an NBP confirm (which sends a unicast to the
   network address which is presumed to be the target of the name
   lookup) to see if the stale information is, in fact, still valid.

唯一の利用可能な情報がNBP名であるなら、NBPルックアップは、その名前をDDPアドレスに変えるために実行されるべきです。 しかしながら、1つの聞き古した情報があれば、NBPを実行するのにヒントとしてそれを使用できる、確認、(あえてルックアップという名前の目標であるネットワーク・アドレスにユニキャストを送ります) 事実上、聞き古した情報がまだ有効であるかどうか確認するために。

SNMPv2 Working Group        Standards Track                     [Page 8]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[8ページ]RFC1906輸送マッピング

   An NBP name to DDP address mapping can also be confirmed implicitly
   using only SNMP transactions.  For example, an SNMPv2 entity acting
   in a manager role issuing a retrieval operation could also retrieve
   the relevant objects from the NBP group [6] for the SNMPv2 entity
   acting in an agent role.  This information can then be correlated
   with the source DDP address of the response.

また、それとなくSNMPトランザクションだけを使用することでDDPアドレス・マッピングへのNBP名を確認できます。 例えば、また、検索操作を発行するマネージャの役割で行動するSNMPv2実体はエージェントの役割で行動するSNMPv2実体のためにNBPグループ[6]から関連オブジェクトを検索するかもしれません。 そして、この情報は応答のソースDDPアドレスで関連できます。

5.3.4.  What if NBP is broken

5.3.4. NBPが壊れていると、どうなるでしょうか?

   Under some circumstances, there may be connectivity between two
   SNMPv2 entities, but the NBP mapping machinery may be broken, e.g.,

いくつかの状況で、2つのSNMPv2実体の間には、接続性があるかもしれませんが、機械を写像するNBPは例えば壊れているかもしれません。

o    the NBP FwdReq (forward NBP lookup onto local attached network)
     mechanism might be broken at a router on the other entity's
     network; or,

o NBP FwdReq(ローカルの付属ネットワークへの前進のNBPルックアップ)メカニズムはもう片方の実体のネットワークでルータで壊れているかもしれません。 または

o    the NBP BrRq (NBP broadcast request) mechanism might be broken
     at a router on the entity's own network; or,

o NBP BrRq(NBP放送要求)メカニズムは実体の自身のネットワークでルータで壊れているかもしれません。 または

o    NBP might be broken on the other entity's node.

o NBPはもう片方の実体のノードで壊れているかもしれません。

   An SNMPv2 entity acting in a manager role which is dedicated to
   AppleTalk management might choose to alleviate some of these failures
   by directly implementing the router portion of NBP.  For example,
   such an entity might already know all the zones on the AppleTalk
   internet and the networks on which each zone appears.  Given an NBP
   lookup which fails, the entity could send an NBP FwdReq to the
   network in which the agent was last located.  If that failed, the
   station could then send an NBP LkUp (NBP lookup packet) as a directed
   (DDP) multicast to each network number on that network.  Of the above
   (single) failures, this combined approach will solve the case where
   either the local router's BrRq-to-FwdReq mechanism is broken or the
   remote router's FwdReq-to-LkUp mechanism is broken.

AppleTalk管理に捧げられるマネージャの役割で行動するSNMPv2実体は、直接NBPのルータ一部を実装することによってこれらの失敗のいくつかを軽減するのを選ぶかもしれません。 例えば、そのような実体は既に、AppleTalkインターネットのすべてのゾーンと各ゾーンが現れるネットワークを知るかもしれません。 失敗するNBPルックアップを考えて、実体はエージェントが最後に位置したネットワークにNBP FwdReqを送るかもしれません。 それが失敗するなら、ステーションは指示された(DDP)マルチキャストとしてNBP LkUp(NBPルックアップパケット)をそのネットワークの各ネットワーク・ナンバーに送ることができるでしょうに。 上(単一の)の失敗では、この結合したアプローチはBrRqからFwdReqへのローカルルータのメカニズムが壊れているか、またはFwdReqからLkUpへのリモートルータのメカニズムが壊れているケースを解決するでしょう。

6.  SNMPv2 over IPX

6. IPXの上のSNMPv2

   This is an optional transport mapping.

これは任意の輸送マッピングです。

6.1.  Serialization

6.1. 連載

   Each instance of a message is serialized onto a single IPX datagram
   [7], using the algorithm specified in Section 8.

セクション8で指定されたアルゴリズムを使用して、メッセージの各インスタンスは単一のIPXデータグラム[7]に連載されます。

6.2.  Well-known Values

6.2. よく知られる値

   SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
   Exchange Protocol).

SNMPv2メッセージにIPXパケットタイプ4(すなわち、Packet Exchangeプロトコル)を使用させます。

SNMPv2 Working Group        Standards Track                     [Page 9]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[9ページ]RFC1906輸送マッピング

   It is suggested that administrators configure their SNMPv2 entities
   acting in an agent role to listen on IPX socket 36879 (900f
   hexadecimal).  Further, it is suggested that notification sinks be
   configured to listen on IPX socket 36880 (9010 hexadecimal)

管理者がIPXソケット36879の上に聴くためにエージェントの役割で行動する彼らのSNMPv2実体を構成することが提案される、(900f、16進) さらに、通知流し台がIPXソケット36880の上に聴くために構成されることが提案されます。(9010 16進)

   When an SNMPv2 entity uses this transport mapping, it must be capable
   of accepting messages that are at least 546 octets in size.
   Implementation of larger values is encouraged whenever possible.

SNMPv2実体がこの輸送マッピングを使用するとき、それはサイズにおいて少なくとも546の八重奏であるメッセージを受け入れることができなければなりません。 可能であるときはいつも、より大きい値の実装は奨励されます。

7.  Proxy to SNMPv1

7. SNMPv1のプロキシ

   In order to provide proxy to SNMPv1 [8], it may be useful to define a
   transport domain, rfc1157Domain, which indicates the transport
   mapping for SNMP messages as defined in RFC 1157.  Section 3.1 of [9]
   specifies the behavior of the proxy agent.

SNMPv1[8]にプロキシを供給するために、輸送ドメイン、rfc1157Domainを定義するのは役に立つかもしれません。(rfc1157DomainはSNMPのためにRFC1157で定義されるようにメッセージを写像する輸送を示します)。 [9]のセクション3.1はプロキシエージェントの振舞いを指定します。

8.  Serialization using the Basic Encoding Rules

8. 基本的な符号化規則を使用する連載

   When the Basic Encoding Rules [10] are used for serialization:

Basic Encoding Rules[10]が連載に使用されるとき:

   (1)  When encoding the length field, only the definite form is used; use
        of the indefinite form encoding is prohibited.  Note that when
        using the definite-long form, it is permissible to use more than
        the minimum number of length octets necessary to encode the length
        field.

(1) 長さの分野をコード化するとき、已然形だけが使用されています。 無期フォームコード化の使用は禁止されています。 明確に長いフォームを使用するとき、長さの分野をコード化するのに必要な長さの八重奏の最小の数以上を使用するのが許されていることに注意してください。

   (2)  When encoding the value field, the primitive form shall be used for
        all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
        IDENTIFIER (either IMPLICIT or explicit).  The constructed form of
        encoding shall be used only for structured types, i.e., a SEQUENCE
        or an IMPLICIT SEQUENCE.

(2) 値の分野をコード化するとき、原始のフォームはすべての純真なタイプ、すなわち、INTEGER、OCTET STRING、およびOBJECT IDENTIFIER(IMPLICITの、または、明白な)に使用されるものとします。 組み立てられたフォームのコード化は、すなわち、構造化されたタイプ、SEQUENCEだけにおいて使用されていてIMPLICIT SEQUENCEになるでしょう。

   (3)  When encoding an object whose syntax is described using the BITS
        construct, the value is encoded as an OCTET STRING, in which all
        the named bits in (the definition of) the bitstring, commencing
        with the first bit and proceeding to the last bit, are placed in
        bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
        subsequent octet in turn, followed by as many bits as are needed of
        the final subsequent octet, commencing with bit 8.  Remaining bits,
        if any, of the final octet are set to zero on generation and
        ignored on receipt.

(3) 構文がBITS構造物を使用することで説明されるオブジェクトをコード化するとき、値が中のOCTET STRINGとしてコード化される、どれ、中のすべての名前付のビット、(定義、)、bitstringと、最初のビットと共に始まって、最後のビットに続くのは最終的なその後の八重奏について必要とされるのと同じくらい多くのビットに従ってそれぞれのその後の八重奏のビット8〜1が順番に支えた最初の八重奏の8〜1つが続いたビットで置かれます、ビット8と共に始まって もしあれば最終的な八重奏の残っているビットは、世代のときにゼロに設定されて、領収書の上で無視されます。

   These restrictions apply to all aspects of ASN.1 encoding, including
   the message wrappers, protocol data units, and the data objects they
   contain.

これらの制限はASN.1コード化の全面に適用されます、メッセージラッパー、プロトコルデータ単位、およびそれらが含むデータ・オブジェクトを含んでいて。

SNMPv2 Working Group        Standards Track                    [Page 10]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[10ページ]RFC1906輸送マッピング

8.1.  Usage Example

8.1. 使用例

   As an example of applying the Basic Encoding Rules, suppose one
   wanted to encode an instance of the GetBulkRequest-PDU [1]:

Basic Encoding Rulesを適用する例として、1つがGetBulkRequest-PDU[1]のインスタンスをコード化したがっていたと仮定してください:

     [5] IMPLICIT SEQUENCE {
             request-id      1414684022,
             non-repeaters   1,
             max-repetitions 2,
             variable-bindings {
                 { name sysUpTime,
                   value { unspecified NULL } },
                 { name ipNetToMediaPhysAddress,
                   value { unspecified NULL } },
                 { name ipNetToMediaType,
                   value { unspecified NULL } }
             }
         }

[5] 暗黙の系列要求イド1414684022、非リピータ1、最大反復2、変項束縛はsysUpTime、値の不特定のNULLを命名して、ipNetToMediaPhysAddress、値の不特定のNULLを命名して、ipNetToMediaType、値の不特定のNULLを命名します。

Applying the BER, this would be encoded (in hexadecimal) as:

BERを適用して、これは以下としてコード化されるでしょう(16進で)。

[5] IMPLICIT SEQUENCE          a5 82 00 39
    INTEGER                    02 04 52 54 5d 76
    INTEGER                    02 01 01
    INTEGER                    02 01 02
    SEQUENCE                   30 2b
        SEQUENCE               30 0b
            OBJECT IDENTIFIER  06 07 2b 06 01 02 01 01 03
            NULL               05 00
        SEQUENCE               30 0d
            OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 02
            NULL               05 00
        SEQUENCE               30 0d
            OBJECT IDENTIFIER  06 09 2b 06 01 02 01 04 16 01 04
            NULL               05 00

[5] IMPLICIT SEQUENCE a5 82 00 39INTEGER02 04 52 54 5d76INTEGER02 01 01INTEGER02 01 02SEQUENCE30 2b SEQUENCE30 0b OBJECT IDENTIFIER06 07 2b06 01 02 01 01 03NULL05 00SEQUENCE30 0d OBJECT IDENTIFIER06 09 2b06 01 02 01 04 16 01 02NULL05 00SEQUENCE30 0d OBJECT IDENTIFIER06 09 2b06 01 02 01 04 16 01 04NULL05 00

   Note that the initial SEQUENCE is not encoded using the minimum
   number of length octets.  (The first octet of the length, 82,
   indicates that the length of the content is encoded in the next two
   octets.)

初期のSEQUENCEが長さの八重奏の最小の数を使用することでコード化されないことに注意してください。 (長さの最初の八重奏(82)は、内容の長さが次の2つの八重奏でコード化されるのを示します。)

9.  Security Considerations

9. セキュリティ問題

   Security issues are not discussed in this memo.

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

SNMPv2 Working Group        Standards Track                    [Page 11]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[11ページ]RFC1906輸送マッピング

10.  Editor's Address

10. エディタのアドレス

   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

11.  Acknowledgements

11. 承認

   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)
     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)

アレクサンダーI; アルテン(ノベル)デーヴArneson(Cabletron)ユリ・ブルーメンソル(IBM)ダグBook(Chipcom)キム・カラン(ベル-北研究)・ジム・ガルビン(情報システムを信じる)・マリア・グリーン(Ascom Timeplex)イアンハンソン(デジタル)のデーヴ・ハリントン(Cabletron)Nguyen Hien(IBM)ジェフ・ジョンソン(シスコシステムズ)マイケルKornegay; (オブジェクト探索) ディアドラKostick(AT&Tベル研究所)デヴィッド・レビ(SNMP研究)・ダニエル・マホニー(Cabletron)ボブNatale(ACE*COMM)ブライアン・オキーフ(ヒューレットパッカード)アンドリューピアソン(SNMP研究)のデーヴ・パーキンス(同輩ネットワーク)ランディPresuhn(同輩ネットワーク)アレックセイ・ロマーノフ(上質の定足数)ショーンRouthier(エピローグ)ジョンSaperia(BGSシステム)

SNMPv2 Working Group        Standards Track                    [Page 12]

RFC 1906             Transport Mappings for SNMPv2          January 1996

SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[12ページ]RFC1906輸送マッピング

     Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
     Kaj Tesink (Bellcore)
     Glenn Waters (Bell-Northern Research)
     Bert Wijnen (IBM)

ボブ・スチュワート(シスコシステムズ、 bstewart@cisco.com )、いすカイTesink(Bellcore)グレンWaters(ベル-北Research)バートWijnen(IBM)

12.  References

12. 参照

[1]  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.

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

[2]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
     USC/Information Sciences Institute, August 1980.

[2] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。

[3]  Information processing systems - Open Systems Interconnection -
     Transport Service Definition, International Organization for
     Standardization.  International Standard 8072, (June, 1986).

[3] 情報処理システム(オープン・システム・インターコネクション)はService Definition、国際標準化機構を輸送します。 国際規格8072、(1986年6月。)

[4]  Information processing systems - Open Systems Interconnection -
     Transport Service Definition - Addendum 1: Connectionless-mode
     Transmission, International Organization for Standardization.
     International Standard 8072/AD 1, (December, 1986).

[4]情報処理システム--オープン・システム・インターコネクション--輸送Service Definition--付加物1: コネクションレス型伝送、国際標準化機構。 国際規格西暦1年、8072/(1986年12月。)

[5]  G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
     edition).  Addison-Wesley, 1990.

[5] G.Sidhu、R.アンドリュース、A.オッペンハイマー、Inside AppleTalk(第2版)。 アディソン-ウエスリー、1990。

[6]  Waldbusser, S., "AppleTalk Management Information Base", RFC 1243,
     Carnegie Mellon University, July 1991.

[6]Waldbusser、S.、「AppleTalk管理情報ベース」、RFC1243、カーネギメロン大学、1991年7月。

[7]  Network System Technical Interface Overview.  Novell, Inc, (June,
     1989).

[7] システム技術的インタフェース概要をネットワークでつないでください。 ノベル、Inc(1989年6月)。

[8]  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.

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

[9]  SNMPv2 Working Group, 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.

[9]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネット標準ネットワークマネージメントフレームワークのバージョン1とバージョン2の間の共存」、RFC1908(1996年1月)。

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

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

SNMPv2 Working Group        Standards Track                    [Page 13]

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