RFC1161 日本語訳

Network Working Group                                   M. Rose, Editor
Request for Comments: 1161      Performance Systems International, Inc.
                                                              June 1990

ワーキンググループのM.ローズ、コメントを求めるエディタ要求をネットワークでつないでください: Inc.1990年6月の国際の1161個の言語運用機構

                             SNMP over OSI

OSIの上のSNMP

                           Table of Contents

目次

   1. Status of this Memo ...................................    1
   2. Background ............................................    1
   2.1 A Digression on User Interfaces ......................    2
   2.1.1 Addressing Conventions for UDP-based service .......    3
   2.2 A Digression of Layering .............................    3
   3. Mapping onto CLTS .....................................    4
   3.1 Addressing Conventions ...............................    4
   3.1.1 Conventions for CLNP-based service .................    4
   4. Mapping onto COTS .....................................    4
   4.1 Addressing Conventions ...............................    5
   4.1.1 Conventions for TP4/CLNP-based service .............    5
   4.1.2 Conventions for TP0/X.25-based service .............    6
   5. Acknowledgements ......................................    6
   6. References ............................................    7
   7. Security Considerations................................    8
   8. Author's Address.......................................    8

1. このMemoの状態… 1 2. バックグラウンド… 1 2.1 ユーザにおける脱線は連結します… 2 2.1 .1 UDPベースのサービスのためにConventionsを扱います… 3 2.2 レイヤリングの脱線… 3 3. CLTSに写像します。 4 3.1 コンベンションに演説します… 4 3.1 CLNPベースのサービスのための.1のコンベンション… 4 4. 簡易寝台に写像します。 4 4.1 コンベンションに演説します… 5 4.1 TP4/CLNPベースのサービスのための.1のコンベンション… 5 4.1 TP0/X.25ベースのサービスのための.2のコンベンション… 6 5. 承認… 6 6. 参照… 7 7. セキュリティ問題… 8 8. 作者のアドレス… 8

1.  Status of this Memo

1. このMemoの状態

   This memo defines an experimental means for running the Simple
   Network Management Protocol (SNMP) over OSI transports.

このメモは、Simple Network Managementプロトコル(SNMP)をOSI輸送の上に実行するために実験的手段を定義します。

   This memo does not specify a standard for the Internet community,
   However, after experimentation, if sufficient consensus is reached in
   the Internet community, then a subsequent revision of this document
   might be made an Internet standard for those systems choosing to
   implement the SNMP over OSI transport services.

十分なコンセンサスにインターネットコミュニティで達しているなら、このメモは実験の後にインターネットコミュニティの規格、Howeverを指定しないで、次に、このドキュメントのその後の改正は作られていて、OSIの上でSNMPを実装するのを選ぶそれらのシステムのインターネット標準がサービスを輸送するということであるかもしれません。

   Distribution of this memo is unlimited.

このメモの分配は無制限です。

2.  Background

2. バックグラウンド

   The Simple Network Management Protocol (SNMP) as defined in [1] is
   now used as an integral part of the network management framework for
   TCP/IP-based internets.  Together, with its companions standards,
   which define the Structure of Management Information (SMI) [2], and
   the Management Information Base (MIB) [3], the SNMP has received
   widespread deployment in many operational networks running the
   Internet suite of protocols.

[1]で定義されるSimple Network Managementプロトコル(SNMP)は現在、TCP/IPベースのインターネットにネットワークマネージメントフレームワークの不可欠の部分として使用されます。 SNMPは仲間規格とManagement Information基地(MIB)の[3]でプロトコルのインターネットスイートを動かす多くの操作上のネットワークで広範囲の展開を一緒に、受けました。(規格はManagement情報(SMI)[2]のStructureを定義します)。

IETF SNMP Working Group                                         [Page 1]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[1ページ]RFC1161SNMP

   It should not be surprising that many of these sites might acquire
   OSI capabilities and may wish to leverage their investment in SNMP
   technology towards managing those OSI components.  This memo
   addresses these concerns by defining a framework for running the SNMP
   in an environment which supports the OSI transport services.

これらのサイトの多くが、OSI能力を取得するかもしれなくて、管理に向かったSNMP技術への彼らの投資がそれらのOSIの部品であると利用したがっているのは、驚くべきものであるべきではありません。 このメモは、OSI輸送がサービスであるとサポートする環境で実行のためにフレームワークを定義するのによるこれらの関心がSNMPであると扱います。

   In OSI, there are two such services, a connection-oriented transport
   services (COTS) as defined in [4], and a connectionless-mode
   transport service (CLTS) as defined in [5].  Although the primary
   deployment of the SNMP is over the connectionless-mode transport
   service provided by the Internet suite of protocols (i.e., the User
   Datagram Protocol or UDP [6]), a design goal of the SNMP was to be
   able to use either a CO-mode or CL-mode transport service.  As such,
   this memo describes mappings from the SNMP onto both the COTS and the
   CLTS.

OSIに、そのような2つのサービス[4]、および[5]で定義されるコネクションレスなモード輸送サービス(CLTS)で定義される接続指向の輸送サービス(COTS)があります。 コネクションレスなモードの上にSNMPのプライマリ展開がありましたが、輸送サービスはプロトコルのインターネットスイートのそばで提供しました。(すなわち、ユーザー・データグラム・プロトコルかUDP[6])、SNMPのデザイン目標はCO-モードかCL-モード輸送サービスのどちらかを使用することであることができました。 そういうものとして、このメモはCOTSとCLTSの両方にSNMPからのマッピングについて説明します。

2.1.  A Digression on User Interfaces

2.1. ユーザインタフェースにおける脱線

   It is likely that user-interfaces to the SNMP will be developed that
   support multiple transport backings.  In an environment such as this,
   it is often important to maintain a consistent addressing scheme for
   users.  Since the mappings described in this memo are onto the OSI
   transport services, use of the textual scheme described in [7], which
   describes a string encoding for OSI presentation addresses, is
   recommended.  The syntax defined in [7] is equally applicable towards
   transport addresses.

SNMPへの複数の輸送が支援であるとサポートするユーザインタフェースは開発されそうでしょう。 これなどの環境で、ユーザの一貫したアドレシング体系を維持するのはしばしば重要です。 OSI輸送サービスにはこのメモで説明されたマッピングがあるので、OSIのためにプレゼンテーションアドレスをコード化するストリングについて説明する[7]で説明された原文の体系の使用はお勧めです。 [7]で定義された構文は等しく輸送アドレスに向かって適切です。

   In this context, a string encoding usually appears as:

このような関係においては、通常、ストリングコード化は以下として現れます。

      [<t-selector>/]<n-provider><n-address>[+<n-info>]

[<t-セレクタ>/]<n-プロバイダー><n-アドレス>。[+ <n-インフォメーション>]

      where:

どこ:

      (1)  <t-selector> is usually either an ASCII string enclosed
           in double-quotes (e.g., "snmp"), or a hexadecimal number
           (e.g., '736e6d70'H);

(1) 通常、<t-セレクタ>は二重引用符に同封されたASCIIストリング(例えば、"snmp")か16進数(例えば、'736e6d70'H)のどちらかです;、'

      (2)  <n-provider> is one of several well-known providers of a
           connectivity-service, one of: "Internet=" for a
           transport-service from the Internet suite of protocols,
           "Int-X25=" for the 1980 CCITT X.25 recommendation, or
           "NS+" for the OSI network service;

(2) <n-プロバイダー>がいくつかのよく知られる接続性サービスのプロバイダーの1つ、1である、: プロトコルのインターネットスイートからの輸送サービスのための「インターネット=」、1980年のCCITT X.25推薦のための「Int-X25=」、またはオウシのための「ナノ秒+」がサービスをネットワークでつなぎます。

      (3)  <n-address> is an address in a format specific to the
           <n-provider>; and,

(3) <n-アドレス>は<n-プロバイダー>に特定の形式のアドレスです。 そして

      (4)  <n-info> is any additional addressing information in a
           format specific to the <n-provider>.

(4) <n-インフォメーション>は<n-プロバイダー>に特定の形式のあらゆる追加アドレス指定情報です。

IETF SNMP Working Group                                         [Page 2]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[2ページ]RFC1161SNMP

   It is not the purpose of this memo to provide an exhaustive
   description of string encodings such as these.  Readers should
   consult [7] for detailed information on the syntax.  However, this
   memo recommends that, as an implementation option, user-interfaces to
   the SNMP that support multiple transport backings SHOULD implement
   this syntax.

これらなどのストリングencodingsの徹底的な記述を提供するのは、このメモの目的ではありません。 読者は構文の詳細な情報のための[7]に相談するべきです。 しかしながら、このメモは、複数の輸送が支援SHOULDであるとサポートするSNMPへのユーザインタフェースが実装オプションとしてこの構文を実装することを勧めます。

2.1.1.  Addressing Conventions for UDP-based service

2.1.1. UDPベースのサービスのためにConventionsを扱います。

   In the context of a UDP-based transport backing, addresses would be
   encoded as:

UDPベースの輸送支援の文脈では、アドレスは以下としてコード化されるでしょう。

                           Internet=<host>+161+2

<インターネット=ホスト>+161+2

   which says that the transport service is from the Internet suite of
   protocols, residing at <host>, on port 161, using the UDP (2).  The
   token <host> may be either a domain name or a dotted-quad, e.g., both

UDP(2)を使用して、ポート161の上の<ホスト>に住んでいて、輸送サービスがプロトコルのインターネットスイートから来ていると言います。 トークン<ホスト>はドメイン名か点を打たされた回路のどちらか、例えば、両方であるかもしれません。

                     Internet=cheetah.nyser.net+161+2

インターネット=cheetah.nyser.net+161+2

   and

そして

                        Internet=192.52.180.1+161+2

インターネット=192.52.180.1+161+2

   are both valid.  Note however that if domain name "cheetah.nyser.net"
   maps to multiple IP addresses, then this implies multiple transport
   addresses.  The number of addresses examined by the application (and
   the order of examination) are specific to each application.

両方が有効ですか? しかしながら、ドメイン名"cheetah.nyser.net"が複数のIPにアドレスを写像するならこれが複数の輸送アドレスを含意することに注意してください。 アプリケーション(そして、試験の注文)で調べられたアドレスの数は各アプリケーションに特定です。

   Of course, this memo does not require that other interface schemes
   not be used.  Clearly, use of a simple hostname is preferable to the
   string encoding above.  However, for the sake of uniformity, for
   those user-interfaces to the SNMP that support multiple transport
   backings, it is strongly RECOMMENDED that the syntax in [7] be
   adopted and even the mapping for UDP-based transport be valid.

もちろん、このメモは他のインタフェース体系が使用されないのを必要としません。 明確に、簡単なホスト名の使用は上でコード化されるストリングより望ましいです。 [7]の構文があるSNMPへのサポート複数の輸送支援、それが強くそうであるそれらのユーザインタフェースRECOMMENDEDのための一様性のためにしかしながら、採用されて同等である、UDPベースの輸送のために写像して、有効であってください。

2.2.  A Digression of Layering

2.2. レイヤリングの脱線

   Although other frameworks view network management as an application,
   extensive experience with the SNMP suggests otherwise.  In essense,
   network management is a function unlike any other user of a transport
   service.  The citation [8] develops this argument in full.  As such,
   it is inappropriate to map the SNMP onto the OSI application layer.
   Rather, it is mapped to OSI transport services, in order to build on
   the proven success of the Internet network management framework.

他のフレームワークはネットワークマネージメントをアプリケーションであるとみなしますが、SNMPの広範囲の経験は別の方法で示されます。 essenseでは、ネットワークマネージメントは輸送サービスのいかなる他のユーザと異なった機能です。 引用[8]は全部のこの議論を発生します。 そういうものとして、OSI応用層にSNMPを写像するのは不適当です。 むしろ、それはOSI輸送サービスに写像されます、インターネット網管理フレームワークの立証された成功に建てるために。

IETF SNMP Working Group                                         [Page 3]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[3ページ]RFC1161SNMP

3.  Mapping onto CLTS

3. CLTSへのマッピング

   Mapping the SNMP onto the CLTS is straight-forward: the elements of
   procedure are identical to that of using the UDP.  In particular,
   note that the CLTS and the service offered by the UDP both transmit
   packets of information which contain full addressing information.
   Thus, mapping the SNMP onto the CLTS, a "transport address" in the
   context of [1], is simply a transport-selector and network address.

SNMPをCLTSに写像するのは簡単です: 手順の要素はUDPを使用するものと同じです。 特に、UDPによって提供されたCLTSとサービスがともに完全なアドレス指定情報を含む情報のパケットを伝えることに注意してください。 したがって、[1]の文脈の「輸送アドレス」は単に輸送セレクタとネットワーク・アドレスであって、SNMPをCLTSに写像します。

3.1.  Addressing Conventions

3.1. コンベンションに演説します。

   Unlike the Internet suite of protocols, OSI does not use well-known
   ports.  Rather demultiplexing occurs on the basis of "selectors",
   which are opaque strings of octets, which have meaning only at the
   destination.  In order to foster interoperable implementations of the
   SNMP over the CLTS, it is necessary define a selector for this
   purpose.

プロトコルのインターネットスイートと異なって、OSIはウェルノウンポートを使用しません。 むしろ逆多重化は目的地だけに意味を持っている八重奏の不透明なストリングである「セレクタ」に基づいて起こります。 それが、CLTSの上でSNMPの共同利用できる実装を伸ばすのに必要です。このためにセレクタを定義してください。

3.1.1.  Conventions for CLNP-based service

3.1.1. CLNPベースのサービスのためのコンベンション

   When the CLTS is used to provide the transport backing for the SNMP,
   demultiplexing will occur on the basis of transport selector.  The
   transport selector used shall be the four ASCII characters

CLTSがSNMPのための輸送支援を提供するのに使用されるとき、逆多重化は輸送セレクタに基づいて起こるでしょう。 4がASCII文字であるつもりであったなら使用される輸送セレクタ

                                   snmp

snmp

   Thus, using the string encoding of [7], such addresses may be
   textual, described as:

したがって、そのようなアドレスは以下と原文で、説明されていて、[7]のストリングコード化を使用するかもしれません。

                             "snmp"/NS+<nsap>

"snmp"/ナノ秒+<nsap>。

   where:

どこ:

   (1)  <nsap> is a hex string defining the nsap, e.g.,

(1) <nsap>は例えばnsapを定義する16進数列です。

                     "snmp"/NS+4900590800200038bafe00

"snmp"/ナノ秒+4900590800200038bafe00

   Similarly, SNMP traps are, by convention, sent to a manager listening
   on the transport selector

同様に、SNMP罠はコンベンションによって輸送セレクタの上に聴いているマネージャに送られます。

                                 snmp-trap

snmp-罠

   which consists of nine ASCII characters.

9人のASCII文字から成ります。

4.  Mapping onto COTS

4. 簡易寝台へのマッピング

   Mapping the SNMP onto the COTS is more difficult as the SNMP does not
   specifically require an existing connection.  Thus, the mapping

SNMPが明確に既存の接続を必要としないとき、SNMPをCOTSに写像するのは、より難しいです。 その結果、マッピング

IETF SNMP Working Group                                         [Page 4]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[4ページ]RFC1161SNMP

   consists of establishing a transport connection, sending one or more
   SNMP messages on that connection, and then releasing the transport
   connection.

1つ以上のSNMPメッセージをその接続に送って、次に、輸送接続を釈放して、輸送接続を確立するのから成ります。

   Consistent with the SNMP model, the initiator of a connection should
   not require that responses to a request be returned on that
   connection.  However, if a responder to a connection sends SNMP
   messages on a connection, then these MUST be in response to requests
   received on that connection.

SNMPモデルと一致しています、接続の創始者は要求への応答がその接続のときに返されるのを必要とするべきではありません。 しかしながら、接続への応答者が接続のときにメッセージをSNMPに送るなら、これらはその接続のときに受け取られた要求に対応しているに違いありません。

   Ideally, the transport connection SHOULD be released by the
   initiator, however, note that the responder may release the
   connection due to resource limitations.  Further note, that the
   amount of time a connection remains established is implementation-
   specific.  Implementors should take care to choose an appropriate
   dynamic algorithm.

しかしながら、輸送接続SHOULDが創始者によってリリースされて、理想的に、応答者がリソース制限による接続を釈放するかもしれないことに注意してください。 接続が確立していたままでいる時間が実装特有であるというさらなるメモ。 作成者は、適切なダイナミックなアルゴリズムを選ぶために注意するべきです。

   Also consistent with the SNMP model, the initiator should not
   associate any reliability characteristics with the use of a
   connection.  Issues such as retransmission of SNMP messages, etc.,
   always remain with the SNMP application, not with the transport
   service.

また、SNMPモデルと一致していて、創始者は少しの信頼性特性値も接続の使用に関連づけるべきではありません。 SNMPメッセージなどの「再-トランスミッション」などの問題は輸送サービスで残っているのではなく、いつもSNMPアプリケーションで残っています。

4.1.  Addressing Conventions

4.1. コンベンションに演説します。

   Unlike the Internet suite of protocols, OSI does not use well-known
   ports.  Rather demultiplexing occurs on the basis of "selectors",
   which are opaque strings of octets, which have meaning only at the
   destination.  In order to foster interoperable implementations of the
   SNMP over the COTS, it is necessary define a selector for this
   purpose.  However, to be consistent with the various connectivity-
   services, different conventions, based on the actual underlying
   service, will be used.

プロトコルのインターネットスイートと異なって、OSIはウェルノウンポートを使用しません。 むしろ逆多重化は目的地だけに意味を持っている八重奏の不透明なストリングである「セレクタ」に基づいて起こります。 それが、COTSの上でSNMPの共同利用できる実装を伸ばすのに必要です。このためにセレクタを定義してください。 しかしながら、様々な接続性サービスと一致しているように、実際の基本的なサービスに基づく異なったコンベンションは使用されるでしょう。

4.1.1.  Conventions for TP4/CLNP-based service

4.1.1. TP4/CLNPベースのサービスのためのコンベンション

   When a COTS based on the TP4/CLNP is used to provide the transport
   backing for the SNMP, demultiplexing will occur on the basis of
   transport selector.  The transport selector used shall be the four
   ASCII characters

TP4/CLNPに基づくCOTSがSNMPのための輸送支援を提供するのに使用されるとき、逆多重化は輸送セレクタに基づいて起こるでしょう。 4がASCII文字であるつもりであったなら使用される輸送セレクタ

                                   snmp

snmp

   Thus, using the string encoding of [7], such addresses may be
   textual, described as:

したがって、そのようなアドレスは以下と原文で、説明されていて、[7]のストリングコード化を使用するかもしれません。

                             "snmp"/NS+<nsap>

"snmp"/ナノ秒+<nsap>。

IETF SNMP Working Group                                         [Page 5]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[5ページ]RFC1161SNMP

   where:

どこ:

   (1)  <nsap> is a hex string defining the nsap, e.g.,

(1) <nsap>は例えばnsapを定義する16進数列です。

                     "snmp"/NS+4900590800200038bafe00

"snmp"/ナノ秒+4900590800200038bafe00

   Similarly, SNMP traps are, by convention, sent to a manager listening
   on the transport selector

同様に、SNMP罠はコンベンションによって輸送セレクタの上に聴いているマネージャに送られます。

                                 snmp-trap

snmp-罠

   which consists of nine ASCII characters.

9人のASCII文字から成ります。

4.1.2.  Conventions for TP0/X.25-based service

4.1.2. TP0/X.25ベースのサービスのためのコンベンション

   When a COTS based on the TP0/X.25 is used to provide the transport
   backing for the SNMP, demultiplexing will occur on the basis of X.25
   protocol-ID.  The protocol-ID used shall be the four octets

TP0/X.25に基づくCOTSがSNMPのための輸送支援を提供するのに使用されるとき、逆多重化はX.25プロトコルIDに基づいて起こるでしょう。 4が八重奏であるつもりであったなら使用されるプロトコルID

                                 03018200

03018200

   Thus, using the string encoding of [7], such addresses may be textual
   described as:

したがって、以下と説明されていた状態でそのようなアドレスは原文であるかもしれなくて、[7]のストリングコード化を使用します。

                        Int-X25=<dte>+PID+03018200

Int-X25は<dte>+PID+03018200と等しいです。

   where:

どこ:

   (1)  <dte> is the X.121 DTE, e.g.,

(1) <dte>は例えばX.121 DTEです。

                    Int-X25=23421920030013+PID+03018200

Int-X25=23421920030013+PID+03018200

   Similarly, SNMP traps are, by convention, sent to a manager listening
   on the protocol-ID

同様に、SNMP罠はコンベンションによってプロトコルIDで聴いているマネージャに送られます。

                                 03019000

03019000

5.  Acknowledgements

5. 承認

   This document was produced by the SNMP Working Group:

このドキュメントはSNMP作業部会によって製作されました:

         Karl Auerbach, Epilogue Technology
         David Bridgham, Epilogue Technology
         Brian Brown, Synoptics
         John Burress, Wellfleet
         Jeffrey D. Case, University of Tennessee at Knoxville
         James R. Davin, MIT-LCS
         Mark S. Fedor, PSI, Inc.

カール・アウアーバック、エピローグ技術デヴィッドBridgham、エピローグTechnologyブライアン・ブラウン、Synopticsジョン・バレス、WellfleetジェフリーD.事件、ノクスビルジェームス・R.デーヴィンのテネシー大学、MIT-LCSはS.ヒョードルをマークします、ψInc.

IETF SNMP Working Group                                         [Page 6]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[6ページ]RFC1161SNMP

         Stan Froyd, ACC
         Satish Joshi, Synoptics
         Ken Key, University of Tennessee at Knoxville
         Gary Malkin, FTP Software
         Randy Mayhew, University of Tennessee at Knoxville
         Keith McCloghrie, Hughes LAN Systems
         Marshall T. Rose, PSI, Inc. (chair)
         Greg Satz, cisco
         Martin Lee Schoffstall, PSI, Inc.
         Bob Stewart, Xyplex
         Geoff Thompson, Synoptics
         Bill Versteeg, Network Research Corporation
         Wengyik Yeong, PSI, Inc.

スタンFroyd、ACCサティシュ・ジョーシー、SynopticsケンKey、ノクスビルゲーリー・マルキンのテネシー大学、FTP Softwareランディ・メイヒュー、ノクスビルキースMcCloghrie、ヒューズ・LAN Systemsマーシャル・T.ローズ、PSI Inc.(いす)グレッグSatz、コクチマスマーチンリーSchoffstall、PSI Inc.ボブ・スチュワート、Xyplexジェフトンプソン、SynopticsビルVersteeg、Network Research社のWengyik Yeong、PSI Inc.におけるテネシー大学

6.  References

6. 参照

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

[1] ケース(J.、ヒョードル、M.、Schoffstall、M.、J.デーヴィン、「簡単なネットワーク管理プロトコル(SNMP)」、RFC1157、SNMP研究、国際言語運用機構、国際言語運用機構、およびMITコンピュータサイエンス研究所)は、1990がそうするかもしれません。

  [2]  Rose M., and K. McCloghrie, "Structure and Identification of
       Management Information for TCP/IP-based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.

[2]ローズM.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、RFC1155、国際パフォーマンスSystemsヒューズLAN Systems(1990年5月)

  [3]  McCloghrie K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets", RFC 1156, Hughes
       LAN Systems, Performance Systems International, May 1990.

[3]McCloghrie K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1156、ヒューズLAN Systems、国際パフォーマンスSystems、1990年5月。

  [4]  Information Processing Systems - Open Systems Interconnection,
       "Transport Service Definition", International Organization for
       Standardization, International Standard 8072, June 1986.

[4]情報処理システム--オープン・システム・インターコネクション、「輸送サービス定義」、国際標準化機構、国際規格8072、1986年6月。

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

[5]情報処理システム--オープン・システム・インターコネクション、「輸送サービス定義--付加物1:、」 「コネクションレス型伝送」、標準の西暦1年1986年8072/12月の国際の国際標準化機構。

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

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

  [7]  Kille, S., "A String Encoding of Presentation Address", Research
       Note RN/89/14, Department of Computer Science, University College
       London, February 1989.

[7] S.、「プレゼンテーションアドレスをコード化するストリング」というKilleは注意Rn/89/14、コンピュータサイエンス学部、ユニバーシティ・カレッジロンドン(1989年2月)について研究します。

  [8]  Case, J., Davin, J., Fedor, M., and M. Schoffstall, "Network
       Management and the Design of SNMP", ConneXions (ISSN 0894-5926),
       Volume 3, Number 3, March 1989.

[8] ケース、J.、デーヴィン、J.、ヒョードル、M.、およびSchoffstallと、「SNMPのネットワークマネージメントとデザイン」(接続(ISSN0894-5926)、第3巻、No.3)が1989に行進させるM.

IETF SNMP Working Group                                         [Page 7]

RFC 1161                     SNMP over OSI                     June 1990

OSI1990年6月の間のIETF SNMP作業部会[7ページ]RFC1161SNMP

7.  Security Considerations

7. セキュリティ問題

   Security issues are not discussed in this memo.

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

8.  Author's Address

8. 作者のアドレス

   Marshall T. Rose
   PSI, Inc.
   PSI California Office
   P.O. Box 391776
   Mountain View, CA 94039

マウンテンビュー、マーシャルT.バラψInc.ψカリフォルニアオフィスP.O. Box391776カリフォルニア 94039

   Phone: (415) 961-3380

以下に電話をしてください。 (415) 961-3380

   Email: mrose@PSI.COM

メール: mrose@PSI.COM

IETF SNMP Working Group                                         [Page 8]

IETF SNMP作業部会[8ページ]