RFC1098 日本語訳
1098 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor,M.L. Schoffstall, J. Davin. April 1989. (Format: TXT=71563 bytes) (Obsoletes RFC1067) (Obsoleted by RFC1157) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Case
Request for Comments: 1098 University of Tennessee at Knoxville
Obsoletes: RFC 1067 M. Fedor
NYSERNet, Inc.
M. Schoffstall
Rensselaer Polytechnic Institute
C. Davin
MIT Laboratory for Computer Science
April 1989
コメントを求めるワーキンググループJ.ケース要求をネットワークでつないでください: ノクスビルの1098年のテネシー大学は以下を時代遅れにします。 RFC1067M.ヒョードルNYSERNet Inc.M.Schoffstallレンセラー工科大学C.デーヴィンMITコンピュータサイエンス研究所1989年4月
A Simple Network Management Protocol (SNMP)
簡単なネットワーク管理プロトコル(SNMP)
Table of Contents
目次
1. Status of this Memo ................................... 2 2. Introduction .......................................... 2 3. The SNMP Architecture ................................. 4 3.1 Goals of the Architecture ............................ 4 3.2 Elements of the Architecture ......................... 4 3.2.1 Scope of Management Information .................... 5 3.2.2 Representation of Management Information ........... 5 3.2.3 Operations Supported on Management Information ..... 6 3.2.4 Form and Meaning of Protocol Exchanges ............. 7 3.2.5 Definition of Administrative Relationships ......... 7 3.2.6 Form and Meaning of References to Managed Objects .. 11 3.2.6.1 Resolution of Ambiguous MIB References ........... 11 3.2.6.2 Resolution of References across MIB Versions...... 11 3.2.6.3 Identification of Object Instances ............... 11 3.2.6.3.1 ifTable Object Type Names ...................... 12 3.2.6.3.2 atTable Object Type Names ...................... 12 3.2.6.3.3 ipAddrTable Object Type Names .................. 13 3.2.6.3.4 ipRoutingTable Object Type Names ............... 13 3.2.6.3.5 tcpConnTable Object Type Names ................. 13 3.2.6.3.6 egpNeighTable Object Type Names ................ 14 4. Protocol Specification ................................ 15 4.1 Elements of Procedure ................................ 16 4.1.1 Common Constructs .................................. 18 4.1.2 The GetRequest-PDU ................................. 19 4.1.3 The GetNextRequest-PDU ............................. 20 4.1.3.1 Example of Table Traversal ....................... 22 4.1.4 The GetResponse-PDU ................................ 23 4.1.5 The SetRequest-PDU ................................. 24 4.1.6 The Trap-PDU ....................................... 26 4.1.6.1 The coldStart Trap ............................... 27 4.1.6.2 The warmStart Trap ............................... 27 4.1.6.3 The linkDown Trap ................................ 27 4.1.6.4 The linkUp Trap .................................. 27
1. このMemoの状態… 2 2. 序論… 2 3. SNMPアーキテクチャ… 4 アーキテクチャの3.1の目標… 4 3.2 アーキテクチャのElements… 4 3.2 .1 経営情報の範囲… 5 3.2 .2 経営情報の表現… 5 3.2 .3の操作が管理で情報をサポートしました… 6 3.2 プロトコル交換の.4のフォームと意味… 7 3.2 .5 管理関係の定義… 7 3.2 管理オブジェクトの参照の.6のフォームと意味。 11 3.2 .6 あいまいなMIB参照の.1解決… 11 3.2 .6 MIBバージョンの向こう側の参照の.2解決… 11 3.2 .6 .3 オブジェクトインスタンスの識別… 11 3.2 .6 .3 .1はオブジェクト型名をifTableします… 12 3.2 .6 .3 .2はオブジェクト型名をatTableします… 12 3.2 .6 .3 .3 ipAddrTableオブジェクト型名… 13 3.2 .6 .3 .4 ipRoutingTableオブジェクト型名… 13 3.2 .6 .3 .5 tcpConnTableオブジェクト型名… 13 3.2 .6 .3 .6 egpNeighTableオブジェクト型名… 14 4. 仕様を議定書の中で述べてください… 15 4.1 手順のElements… 16 4.1 .1 一般的な構造物… 18 4.1 .2 GetRequest-PDU… 19 4.1 .3 GetNextRequest-PDU… 20 4.1 .3 テーブル縦断に関する.1の例… 22 4.1 .4 GetResponse-PDU… 23 4.1 .5 SetRequest-PDU… 24 4.1 .6 PDUを捕らえます… 26 4.1 .6 .1 コールドスタート罠… 27 4.1 .6 .2 warmStartは捕らえます… 27 4.1 .6 .3 linkDownは捕らえます… 27 4.1 .6 .4 結合罠… 27
Case, Fedor, Schoffstall, & Davin [Page 1] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[1ページ]RFC1098SNMP1989年4月
4.1.6.5 The authenticationFailure Trap ................... 27 4.1.6.6 The egpNeighborLoss Trap ......................... 27 4.1.6.7 The enterpriseSpecific Trap ...................... 28 5. Definitions ........................................... 29 6. Acknowledgements ...................................... 32 7. References ............................................ 33
4.1.6.5 authenticationFailureは捕らえます… 27 4.1 .6 .6 egpNeighborLossは捕らえます… 27 4.1 .6 .7 enterpriseSpecificは捕らえます… 28 5. 定義… 29 6. 承認… 32 7. 参照… 33
1. Status of this Memo
1. このMemoの状態
This RFC is a re-release of RFC 1067, with a changed "Status of this Memo" section. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. In particular, together with its companion memos which describe the structure of management information along with the initial management information base, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet.
変えられた「このMemoの状態」セクションでこのRFCはRFC1067の再リリースです。 このメモはネットワーク要素のための経営情報が論理的にリモートなユーザによって点検されるか、または変更されるかもしれない簡単なプロトコルを定義します。 初期の管理情報ベースに伴う経営情報の構造について説明する仲間メモと共に特に、これらのドキュメントはTCP/IPベースのインターネットと特にインターネットを管理する簡単で、実行可能なアーキテクチャとシステムを提供します。
The Internet Activities Board (IAB) has designated two different network management protocols with the same status of "Draft Standard" and "Recommended".
Activities Board(IAB)には「草稿規格」の同じ状態がある2つの異なったネットワーク管理プロトコルに指定されて、「推薦されること」があるインターネット。
The two protocols are the Common Management Information Services and Protocol over TCP/IP (CMOT) [9], and the Simple Network Management Protocol (SNMP) (this memo).
2つのプロトコルが、TCP/IP(CMOT)[9]の上のCommon Management情報Servicesとプロトコルと、Simple Network Managementプロトコル(SNMP)(このメモ)です。
The IAB intends each of these two protocols to receive the attention of implementers and experimenters. The IAB seeks reports of experience with these two protocols from system builders and users.
それぞれのこれらの2つのプロトコルがIABがimplementersと実験者の配慮を受けるつもりです。 IABはシステムビルダーとユーザからこれらの2つのプロトコルの経験のレポートを求めます。
By this action, the IAB recommends that all IP and TCP implementations be network manageable (e.g., implement the Internet MIB [3]) and that the implementations that are network manageable are expected to adopt and implement at least one of these two Internet Draft Standards.
この動作で、IABは、すべてのIPとTCP実装がネットワーク処理しやすいのを推薦します。(例えば、インターネットMIB[3])とそれが実装であると実装してください処理しやすいネットワークが少なくともこれらの2インターネットDraft Standardsの1つを採用して、実装すると予想されるということである。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
2. Introduction
2. 序論
As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], the Internet Activities Board has directed the Internet Engineering Task Force (IETF) to create two new working groups in the area of network management. One group is charged with the further specification and definition of elements to be included in the Management Information Base (MIB). The other is charged with defining the modifications to the Simple Network Management Protocol (SNMP) to accommodate the short-term
RFC1052、インターネットNetwork Management Standards[1]のDevelopmentのためのIAB Recommendationsで報告されるように、インターネットActivities Boardは、ネットワークマネージメントの領域に2つの新しいワーキンググループを創設するようインターネット・エンジニアリング・タスク・フォース(IETF)に指示しました。 要素のさらなる仕様と定義で1つのグループを告発して、Management Information基地(MIB)に含まれています。 短期的を収容するためにSimple Network Managementプロトコル(SNMP)への変更を定義することでもう片方を告発します。
Case, Fedor, Schoffstall, & Davin [Page 2] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[2ページ]RFC1098SNMP1989年4月
needs of the network vendor and operations communities, and to align with the output of the MIB working group.
ネットワークベンダと操作共同体の必要性、MIBワーキンググループの出力に、並びます。
The MIB working group has produced two memos, one which defines a Structure for Management Information (SMI) [2] for use by the managed objects contained in the MIB. A second memo [3] defines the list of managed objects.
MIBワーキンググループは2つのメモ(使用のためのManagement情報(SMI)[2]のためにMIBに含まれた管理オブジェクトでStructureを定義するもの)を製作しました。 2番目のメモ[3]は管理オブジェクトのリストを定義します。
The output of the SNMP Extensions working group is this memo, which incorporates changes to the initial SNMP definition [4] required to attain alignment with the output of the MIB working group. The changes should be minimal in order to be consistent with the IAB's directive that the working groups be "extremely sensitive to the need to keep the SNMP simple." Although considerable care and debate has gone into the changes to the SNMP which are reflected in this memo, the resulting protocol is not backwardly-compatible with its predecessor, the Simple Gateway Monitoring Protocol (SGMP) [5]. Although the syntax of the protocol has been altered, the original philosophy, design decisions, and architecture remain intact. In order to avoid confusion, new UDP ports have been allocated for use by the protocol described in this memo.
SNMP Extensionsワーキンググループの出力はこのメモです。(そのメモは定義[4]がMIBワーキンググループの出力による整列に達するのを必要とした初期のSNMPへの変化を取り入れます)。 変化は、ワーキンググループがあるIABの指示と一致しているように最小限であるべきです。「SNMPを簡単に保つ必要性に非常に敏感」。 かなりの注意と討論はこのメモに反映されるSNMPへの変化に入りましたが、結果として起こるプロトコルは後方に前任者(SimpleゲートウェイMonitoringプロトコル(SGMP)[5])と互換性がありません。 プロトコルの構文は変更されましたが、オリジナルの哲学、デザイン決定、およびアーキテクチャは元の状態のままになります。 混乱を避けて、このメモで説明されたプロトコルは使用のために新しいUDPポートを割り当てました。
Case, Fedor, Schoffstall, & Davin [Page 3] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[3ページ]RFC1098SNMP1989年4月
3. The SNMP Architecture
3. SNMPアーキテクチャ
Implicit in the SNMP architectural model is a collection of network management stations and network elements. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, gateways, terminal servers, and the like, which have management agents responsible for performing the network management functions requested by the network management stations. The Simple Network Management Protocol (SNMP) is used to communicate management information between the network management stations and the agents in the network elements.
SNMPの建築モデルで暗黙であることは、ネットワークマネージメントステーションとネットワーク要素の収集です。 ネットワークマネージメントステーションはネットワーク要素をモニターして、制御する管理アプリケーションを作成します。 ネットワーク要素は管理エージェントをネットワークマネージメントステーションによって要求されたネットワークマネージメント機能を実行するのに責任があるようにするホストや、ゲートウェイや、ターミナルサーバや、同様のものなどのデバイスです。 Simple Network Managementプロトコル(SNMP)は、ネットワーク要素でネットワークマネージメントステーションとエージェントの間の経営情報を伝えるのに使用されます。
3.1. Goals of the Architecture
3.1. アーキテクチャの目標
The SNMP explicitly minimizes the number and complexity of management functions realized by the management agent itself. This goal is attractive in at least four respects:
SNMPは明らかに管理エージェント自身によって実現された管理機能の数と複雑さを最小にします。 この目標は少なくとも4つの点で魅力的です:
(1) The development cost for management agent software
necessary to support the protocol is accordingly reduced.
(1) プロトコルをサポートするのに必要な管理エージェントソフトウェアのための開発費はそれに従って、下げられます。
(2) The degree of management function that is remotely
supported is accordingly increased, thereby admitting
fullest use of internet resources in the management task.
(2) 離れてサポートされる管理機能の度合いはそれに従って、増強されます、その結果、インターネットリソースの管理タスクで最もふくよかな使用を認めます。
(3) The degree of management function that is remotely
supported is accordingly increased, thereby imposing the
fewest possible restrictions on the form and
sophistication of management tools.
(3) 離れてサポートされる管理機能の度合いはそれに従って、増強されます、その結果、管理ツールに関するフォームと洗練に最もわずかな可能な制限しか課しません。
(4) Simplified sets of management functions are easily
understood and used by developers of network management
tools.
(4) 簡易型の管理機能は、ネットワークマネージメントツールの開発者によって容易に理解されて、使用されます。
A second goal of the protocol is that the functional paradigm for monitoring and control be sufficiently extensible to accommodate additional, possibly unanticipated aspects of network operation and management.
プロトコルの2番目の目標は機能的なパラダイムがモニターとコントロールのためにネットワーク操作と管理の追加していて、ことによると思いがけない局面を収容するのにおいて十分広げることができるということです。
A third goal is that the architecture be, as much as possible, independent of the architecture and mechanisms of particular hosts or particular gateways.
3番目の目標はアーキテクチャが特定のホストか特定のゲートウェイのアーキテクチャとメカニズムからできるだけ独立しているということです。
3.2. Elements of the Architecture
3.2. アーキテクチャのElements
The SNMP architecture articulates a solution to the network management problem in terms of:
SNMPアーキテクチャは以下に関してソリューションについてネットワーク管理問題と明確に話します。
Case, Fedor, Schoffstall, & Davin [Page 4] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[4ページ]RFC1098SNMP1989年4月
(1) the scope of the management information communicated by
the protocol,
(1) 経営情報の範囲はプロトコルで交信しました。
(2) the representation of the management information
communicated by the protocol,
(2) 経営情報の表現はプロトコルで伝えました。
(3) operations on management information supported by the
protocol,
(3) プロトコルによってサポートされた経営情報における操作
(4) the form and meaning of exchanges among management
entities,
(4) 経営体の中の交換のフォームと意味
(5) the definition of administrative relationships among
management entities, and
そして(5) 経営体の中の管理関係の定義。
(6) the form and meaning of references to management
information.
(6) 経営情報の参照のフォームと意味。
3.2.1. Scope of Management Information
3.2.1. 経営情報の範囲
The scope of the management information communicated by operation of the SNMP is exactly that represented by instances of all non- aggregate object types either defined in Internet-standard MIB or defined elsewhere according to the conventions set forth in Internet-standard SMI [2].
経営情報の範囲はまさにすべての非集合のオブジェクト・タイプのインスタンスによってインターネット標準MIBで定義されていた状態でそんなに表されたか、またはインターネット標準SMI[2]に詳しく説明されたコンベンションに従ってほかの場所で定義されたSNMPの操作で交信しました。
Support for aggregate object types in the MIB is neither required for conformance with the SMI nor realized by the SNMP.
MIBの集合オブジェクト・タイプのサポートは、SMIとの順応に必要でなく、またSNMPによって実現されません。
3.2.2. Representation of Management Information
3.2.2. 経営情報の表現
Management information communicated by operation of the SNMP is represented according to the subset of the ASN.1 language [6] that is specified for the definition of non-aggregate types in the SMI.
SMIとの非集成型の定義に指定されるASN.1言語[6]の部分集合に従って、SNMPの操作で伝えられた経営情報は表されます。
The SGMP adopted the convention of using a well-defined subset of the ASN.1 language [6]. The SNMP continues and extends this tradition by utilizing a moderately more complex subset of ASN.1 for describing managed objects and for describing the protocol data units used for managing those objects. In addition, the desire to ease eventual transition to OSI-based network management protocols led to the definition in the ASN.1 language of an Internet-standard Structure of Management Information (SMI) [2] and Management Information Base (MIB) [3]. The use of the ASN.1 language, was, in part, encouraged by the successful use of ASN.1 in earlier efforts, in particular, the SGMP. The restrictions on the use of ASN.1 that are part of the SMI contribute to the simplicity espoused and validated by experience with the SGMP.
SGMPはASN.1言語[6]の明確な部分集合を使用するコンベンションを採用しました。 SNMPは、管理オブジェクトについて説明して、それらのオブジェクトを管理するのに使用されるプロトコルデータ単位について説明するのにASN.1の適度により複雑な部分集合を利用することによって、この伝統を続けていて、広げています。 さらに、OSIベースのネットワーク管理プロトコルへの最後の変遷を緩和する願望はManagement情報(SMI)[2]とManagement Information基地(MIB)の[3]のインターネット標準StructureのASN.1言語との定義につながりました。 ASN.1言語の使用は以前の取り組みにおけるASN.1のうまくいっている使用で一部奨励されていて、コネは事項です、SGMP。 SMIの一部であるASN.1の使用の制限はSGMPの経験で信奉されて、有効にされた簡単さに貢献します。
Case, Fedor, Schoffstall, & Davin [Page 5] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[5ページ]RFC1098SNMP1989年4月
Also for the sake of simplicity, the SNMP uses only a subset of the basic encoding rules of ASN.1 [7]. Namely, all encodings use the definite-length form. Further, whenever permissible, non-constructor encodings are used rather than constructor encodings. This restriction applies to all aspects of ASN.1 encoding, both for the top-level protocol data units and the data objects they contain.
また、簡単にするために、SNMPはASN.1[7]の基本的な符号化規則の部分集合だけを使用します。 すなわち、すべてのencodingsが明確な長さのフォームを使用します。 さらに、許されるときはいつも、非建設者encodingsは建設者encodingsよりむしろ使用されます。 この制限はASN.1コード化の全面に適用されます、トップレベルプロトコルデータ単位とそれらが含むデータ・オブジェクトのために。
3.2.3. Operations Supported on Management Information
3.2.3. 経営情報でサポートされた操作
The SNMP models all management agent functions as alterations or inspections of variables. Thus, a protocol entity on a logically remote host (possibly the network element itself) interacts with the management agent resident on the network element in order to retrieve (get) or alter (set) variables. This strategy has at least two positive consequences:
SNMPは変数の変更か点検としてすべての管理エージェント機能をモデル化します。 したがって、論理的にリモートなホスト(ことによるとネットワーク要素自体)の上のプロトコル実体は、変数を検索するか(得ます)、または変更する(設定する)ためにネットワーク要素の上で管理エージェントの居住者と対話します。 この戦略には、少なくとも2つの肯定的結果があります:
(1) It has the effect of limiting the number of essential
management functions realized by the management agent to
two: one operation to assign a value to a specified
configuration or other parameter and another to retrieve
such a value.
(1) それで、管理エージェントは不可欠の管理機能の数を制限するという効果を2に実現します: そのような値を検索するために指定された構成か他のパラメタと別のものに値を割り当てる1つの操作。
(2) A second effect of this decision is to avoid introducing
into the protocol definition support for imperative
management commands: the number of such commands is in
practice ever-increasing, and the semantics of such
commands are in general arbitrarily complex.
(2) この決定の2番目の効果は必須の管理命令のプロトコル定義サポートに導入するのを避けることです: そのようなコマンドの数は習慣絶えず増加でそうです、そして、一般に、そのようなコマンドの意味論はそうです。任意に複雑です。
The strategy implicit in the SNMP is that the monitoring of network state at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the monitoring center(s). A limited number of unsolicited messages (traps) guide the timing and focus of the polling. Limiting the number of unsolicited messages is consistent with the goal of simplicity and minimizing the amount of traffic generated by the network management function.
SNMPの暗黙の戦略はどんな有意水準の詳細におけるネットワーク状態のモニターもモニターしているセンター側で主として適切な情報のための世論調査で達成されるということです。 限られた数のお節介なメッセージ(罠)が世論調査のタイミングと焦点を誘導します。 お節介なメッセージの数を制限するのは簡単さとトラフィックの量を最小にするというネットワークマネージメント機能によって生成される目標のために一貫しています。
The exclusion of imperative commands from the set of explicitly supported management functions is unlikely to preclude any desirable management agent operation. Currently, most commands are requests either to set the value of some parameter or to retrieve such a value, and the function of the few imperative commands currently supported is easily accommodated in an asynchronous mode by this management model. In this scheme, an imperative command might be realized as the setting of a parameter value that subsequently triggers the desired action. For example, rather than implementing a "reboot command," this action might be invoked by simply setting a parameter indicating the number of seconds until system reboot.
明らかにサポートしている管理機能のセットからの必須のコマンドの除外はどんな望ましい管理エージェント操作も排除しそうにはありません。 現在、ほとんどのコマンドは何らかのパラメタの値を設定するか、または現在サポートされているわずかな必須のコマンドについてそのような値、および機能を検索するどちらかがこのマネジメント・モデルによって非同期モードで容易に設備されるという要求です。 この体系では、必須のコマンドは次に必要な動作の引き金となるパラメタ価値の設定として実現されるかもしれません。 例えば、パラメタがシステムリブートまで秒数を示すように単に設定することによって、「リブートコマンド」を実装するよりむしろ、この動作は呼び出されるかもしれません。
Case, Fedor, Schoffstall, & Davin [Page 6] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[6ページ]RFC1098SNMP1989年4月
3.2.4. Form and Meaning of Protocol Exchanges
3.2.4. プロトコル交換のフォームと意味
The communication of management information among management entities is realized in the SNMP through the exchange of protocol messages. The form and meaning of those messages is defined below in Section 4.
経営体の中の経営情報に関するコミュニケーションはプロトコルメッセージの交換を通してSNMPに実現されます。 それらのメッセージの書式と意味は以下でセクション4で定義されます。
Consistent with the goal of minimizing complexity of the management agent, the exchange of SNMP messages requires only an unreliable datagram service, and every message is entirely and independently represented by a single transport datagram. While this document specifies the exchange of messages via the UDP protocol [8], the mechanisms of the SNMP are generally suitable for use with a wide variety of transport services.
管理エージェントの複雑さを最小にするという目標のために一貫しています、SNMPメッセージの交換は頼り無いデータグラムサービスだけを必要とします、そして、あらゆるメッセージが単一の輸送データグラムによって完全に独自に表されます。 このドキュメントはUDPプロトコル[8]でメッセージの交換を指定しますが、一般に、SNMPのメカニズムはさまざまな輸送サービスによって使用に適しています。
3.2.5. Definition of Administrative Relationships
3.2.5. 管理関係の定義
The SNMP architecture admits a variety of administrative relationships among entities that participate in the protocol. The entities residing at management stations and network elements which communicate with one another using the SNMP are termed SNMP application entities. The peer processes which implement the SNMP, and thus support the SNMP application entities, are termed protocol entities.
SNMPアーキテクチャはプロトコルに参加する実体の中のさまざまな管理関係を認めます。 管理局に住んでいる実体とSNMPを使用することでお互いにコミュニケートするネットワーク要素がSNMPアプリケーション実体と呼ばれます。 SNMPを実装して、その結果SNMPアプリケーション実体をサポートする同輩プロセスはプロトコル実体と呼ばれます。
A pairing of an SNMP agent with some arbitrary set of SNMP application entities is called an SNMP community. Each SNMP community is named by a string of octets, that is called the community name for said community.
何らかの任意のセットのSNMPアプリケーション実体へのSNMPエージェントの組み合わせはSNMP共同体と呼ばれます。 それぞれのSNMP共同体は一連の八重奏で命名されて、それは前述の共同体に共同体名と呼ばれます。
An SNMP message originated by an SNMP application entity that in fact belongs to the SNMP community named by the community component of said message is called an authentic SNMP message. The set of rules by which an SNMP message is identified as an authentic SNMP message for a particular SNMP community is called an authentication scheme. An implementation of a function that identifies authentic SNMP messages according to one or more authentication schemes is called an authentication service.
事実上、前述のメッセージの共同体成分によって指定されたSNMP共同体に属すSNMPアプリケーション実体によって溯源されたSNMPメッセージは正統のSNMPメッセージと呼ばれます。 SNMPメッセージが特定のSNMP共同体に、正統のSNMPメッセージとして特定される規則のセットは認証体系と呼ばれます。 1つ以上の認証体系通りに正統のSNMPメッセージを特定する機能の実装は認証サービスと呼ばれます。
Clearly, effective management of administrative relationships among SNMP application entities requires authentication services that (by the use of encryption or other techniques) are able to identify authentic SNMP messages with a high degree of certainty. Some SNMP implementations may wish to support only a trivial authentication service that identifies all SNMP messages as authentic SNMP messages.
明確に、SNMPアプリケーション実体の中の管理関係の効果的な経営者側は正統のSNMPメッセージを高度合いの確実性と同一視できる(暗号化か他のテクニックの使用で)認証サービスを必要とします。 いくつかのSNMP実装が、些細な唯一の認証がすべてのSNMPメッセージが正統のSNMPメッセージであると認識するサービスであるとサポートしたがっているかもしれません。
For any network element, a subset of objects in the MIB that pertain to that element is called a SNMP MIB view. Note that the names of the object types represented in a SNMP MIB view need not belong to a
どんなネットワーク要素においても、その要素に関係するMIBのオブジェクトの部分集合はSNMP MIB視点と呼ばれます。 SNMP MIB視点で代理をされたオブジェクト・タイプの名前がaに属す必要はないことに注意してください。
Case, Fedor, Schoffstall, & Davin [Page 7] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[7ページ]RFC1098SNMP1989年4月
single sub-tree of the object type name space.
スペースというオブジェクト型名のただ一つの下位木。
An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
access mode.
セットの要素に、READだけ、READ-WRITEはSNMPアクセス・モードと呼ばれます。
A pairing of a SNMP access mode with a SNMP MIB view is called an SNMP community profile. A SNMP community profile represents specified access privileges to variables in a specified MIB view. For every variable in the MIB view in a given SNMP community profile, access to that variable is represented by the profile according to the following conventions:
SNMP MIB視点へのSNMPアクセス・モードの組み合わせはSNMP共同体プロフィールと呼ばれます。 SNMP共同体プロフィールは指定されたMIB視点で指定されたアクセス権を変数に表します。 与えられたSNMP共同体プロフィールのMIB視点におけるあらゆる変数において、以下のコンベンションに従って、その変数へのアクセスはプロフィールによって表されます:
(1) if said variable is defined in the MIB with "Access:" of
"none," it is unavailable as an operand for any operator;
(1) 前述の変数がMIBで定義される、「アクセス:」 「なにも」では、それはどんなオペレータのためのオペランドとしても入手できません。
(2) if said variable is defined in the MIB with "Access:" of
"read-write" or "write-only" and the access mode of the
given profile is READ-WRITE, that variable is available
as an operand for the get, set, and trap operations;
(2) 前述の変数がMIBで定義される、「アクセス:」 または、「-読まれて、書いてください」、「書く、-単に、」 与えられたプロフィールのアクセス・モードがREAD-WRITEである、その変数がオペランドとして利用可能である、得て、設定して、捕らえる、。
(3) otherwise, the variable is available as an operand for
the get and trap operations.
得てください、そして、捕らえてください。(3) さもなければ、変数がオペランドとして利用可能である、操作。
(4) In those cases where a "write-only" variable is an
operand used for the get or trap operations, the value
given for the variable is implementation-specific.
それらの場合における(4)、どこ、「書くか、-単に、」 変数が使用されるオペランドである、得てください。さもないと、罠操作であり変数のために与えられた値は実装特有です。
A pairing of a SNMP community with a SNMP community profile is called a SNMP access policy. An access policy represents a specified community profile afforded by the SNMP agent of a specified SNMP community to other members of that community. All administrative relationships among SNMP application entities are architecturally defined in terms of SNMP access policies.
SNMP共同体プロフィールへのSNMP共同体の組み合わせはSNMPアクセス方針と呼ばれます。 アクセス方針は指定されたSNMP共同体のSNMPエージェントによってその共同体の他のメンバーに都合された指定された共同体プロフィールを表します。 建築上、SNMPアプリケーション実体の中のすべての管理関係がSNMPアクセス方針で定義されます。
For every SNMP access policy, if the network element on which the SNMP agent for the specified SNMP community resides is not that to which the MIB view for the specified profile pertains, then that policy is called a SNMP proxy access policy. The SNMP agent associated with a proxy access policy is called a SNMP proxy agent. While careless definition of proxy access policies can result in management loops, prudent definition of proxy policies is useful in at least two ways:
あらゆるSNMPアクセス方針において、その方針は指定されたSNMP共同体のSNMPエージェントが住んでいるネットワーク要素が指定されたプロフィールのためのMIB視点が関係するそれでないならSNMPプロキシアクセス方針と呼ばれます。 プロキシアクセス方針に関連づけられたSNMPエージェントはSNMPプロキシエージェントと呼ばれます。 プロキシアクセス方針の不注意な定義は管理輪をもたらすことができますが、プロキシ方針の慎重な定義は少なくとも2つの方法で役に立ちます:
(1) It permits the monitoring and control of network elements
which are otherwise not addressable using the management
protocol and the transport protocol. That is, a proxy
agent may provide a protocol conversion function allowing
a management station to apply a consistent management
(1) それはそうでなければ管理プロトコルとトランスポート・プロトコルを使用することでアドレス可能でないネットワーク要素のモニターとコントロールを可能にします。 すなわち、プロキシエージェントは管理局が一貫した管理を適用できるプロトコル変換機能を提供するかもしれません。
Case, Fedor, Schoffstall, & Davin [Page 8] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[8ページ]RFC1098SNMP1989年4月
framework to all network elements, including devices such
as modems, multiplexors, and other devices which support
different management frameworks.
異なった管理がフレームワークであるとサポートするモデムや、マルチプレクサーや、対向機器などのデバイスを含むすべてのネットワーク要素へのフレームワーク。
(2) It potentially shields network elements from elaborate
access control policies. For example, a proxy agent may
implement sophisticated access control whereby diverse
subsets of variables within the MIB are made accessible
to different management stations without increasing the
complexity of the network element.
(2) それは入念なアクセス制御方針からネットワーク要素を潜在的に保護します。 例えば、プロキシエージェントは、洗練されたアクセスがMIBの中の変数のさまざまの部分集合がネットワーク要素の複雑さを増強しないで異なった管理局にアクセスしやすくされるコントロールであると実装するかもしれません。
By way of example, Figure 1 illustrates the relationship between management stations, proxy agents, and management agents. In this example, the proxy agent is envisioned to be a normal Internet Network Operations Center (INOC) of some administrative domain which has a standard managerial relationship with a set of management agents.
一例として、図1は管理局と、プロキシエージェントと、管理エージェントとの関係を例証します。 この例では、プロキシエージェントは、1セットの管理エージェントとの標準の経営者の関係を持っている何らかの管理ドメインの正常なインターネットネットワーク運営センター(INOC)になるように思い描かれます。
Case, Fedor, Schoffstall, & Davin [Page 9] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[9ページ]RFC1098SNMP1989年4月
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
+------------------+ +----------------+ +----------------+ | 領域#1INOC| |領域#2INOC| |領域#3におけるPC| | | | | | | |ドメイン=領域#1| |ドメイン=領域#2| |ドメイン=領域#3| |CPU=超mini-1| |CPU=超mini-1| |CPU=クローン-1| |PCommunityはパブと等しいです。| |PCommunityはパブと等しいです。| |PCommunityはスレートと等しいです。| | | | | | | +------------------+ +----------------+ +----------------+ /|\ /|\ /|\ | | | | | | | \|/ | | +-----------------+ | +-------------->| 領域#3INOC| <、-、-、-、-、-、-、-、-、-、-、-、--+ | | |ドメイン=領域#3| |CPU=超mini-2| |PCommunityはパブと等しいです。| | スレート| |DCommunityは秘密と等しいです。| +-------------->| | <、-、-、-、-、-、-、-、-、-、-、-、--+ | +-----------------+ | | /|\ | | | | | | | \|/ \|/ \|/ +-----------------+ +-----------------+ +-----------------+ |ドメイン=領域#3| |ドメイン=領域#3| |ドメイン=領域#3| |CPU=ルータ-1| |CPU=メインフレーム-1| |CPU=モデム-1| |DCommunityは秘密と等しいです。| |DCommunityは秘密と等しいです。| |DCommunityは秘密と等しいです。| +-----------------+ +-----------------+ +-----------------+
Domain: the administrative domain of the element PCommunity: the name of a community utilizing a proxy agent DCommunity: the name of a direct community
ドメイン: 要素PCommunityの管理ドメイン: プロキシエージェントDCommunityを利用する共同体の名前: ダイレクト共同体の名前
Figure 1
Example Network Management Configuration
図1 例のネットワークマネージメント構成
Case, Fedor, Schoffstall, & Davin [Page 10] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[10ページ]RFC1098SNMP1989年4月
3.2.6. Form and Meaning of References to Managed Objects
3.2.6. 管理オブジェクトの参照のフォームと意味
The SMI requires that the definition of a conformant management protocol address:
SMIは、conformant管理の定義がアドレスについて議定書の中で述べるのを必要とします:
(1) the resolution of ambiguous MIB references,
(1) あいまいなMIB参照の解決
(2) the resolution of MIB references in the presence multiple
MIB versions, and
そして(2) 存在倍数MIBバージョンにおける、MIB参照の解決。
(3) the identification of particular instances of object
types defined in the MIB.
(3) MIBで定義されたオブジェクト・タイプの特定のインスタンスの識別。
3.2.6.1. Resolution of Ambiguous MIB References
3.2.6.1. あいまいなMIB参照の解決
Because the scope of any SNMP operation is conceptually confined to objects relevant to a single network element, and because all SNMP references to MIB objects are (implicitly or explicitly) by unique variable names, there is no possibility that any SNMP reference to any object type defined in the MIB could resolve to multiple instances of that type.
どんなSNMP操作の範囲も概念的にただ一つのネットワーク要素に関連しているオブジェクトに閉じ込められて、MIBオブジェクトのすべてのSNMP参照がユニークな変数名を使用するので(それとなくか明らかに)、MIBで定義されたどんなオブジェクト・タイプについてのどんなSNMP言及も、タイプするようにその複数のインスタンスに決議するかもしれない可能性が全くありません。
3.2.6.2. Resolution of References across MIB Versions
3.2.6.2. MIBバージョンの向こう側の参照の解決
The object instance referred to by any SNMP operation is exactly that specified as part of the operation request or (in the case of a get- next operation) its immediate successor in the MIB as a whole. In particular, a reference to an object as part of some version of the Internet-standard MIB does not resolve to any object that is not part of said version of the Internet-standard MIB, except in the case that the requested operation is get-next and the specified object name is lexicographically last among the names of all objects presented as part of said version of the Internet-Standard MIB.
どんなSNMP操作でも言及されたオブジェクトインスタンスはまさに操作要求かその(aの場合では、次の操作を得てください)すぐ次の後継者の一部として全体でMIBでそんなに指定されています。 特に、インターネット標準MIBの何らかのバージョンの一部としてのオブジェクトの参照は、反対するようにいずれにも決議しません、すなわち、要求された操作が気付くことであり、指定されたオブジェクトが名前であること以外のインターネット標準MIBの前述のバージョンのいずれの一部も、すべてのオブジェクトの名前の中の辞書編集最終がインターネット標準のMIBの前述のバージョンの一部として提示されません。
3.2.6.3. Identification of Object Instances
3.2.6.3. オブジェクトインスタンスの識別
The names for all object types in the MIB are defined explicitly either in the Internet-standard MIB or in other documents which conform to the naming conventions of the SMI. The SMI requires that conformant management protocols define mechanisms for identifying individual instances of those object types for a particular network element.
MIBのすべてのオブジェクト・タイプのための名前はインターネット標準MIBかSMIの命名規則に一致している他のドキュメントで明らかに定義されます。 SMIは、conformant管理プロトコルが特定のネットワーク要素のためにそれらのオブジェクト・タイプの個々のインスタンスを特定するためにメカニズムを定義するのを必要とします。
Each instance of any object type defined in the MIB is identified in SNMP operations by a unique name called its "variable name." In general, the name of an SNMP variable is an OBJECT IDENTIFIER of the form x.y, where x is the name of a non-aggregate object type defined in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
MIBで定義されたどんなオブジェクト・タイプの各インスタンスも「変数名」と呼ばれるユニークな名前によってSNMP操作で特定されます。 一般に、SNMP変数の名前がフォームx.yのOBJECT IDENTIFIERである、どこのxがMIBで定義された非集団オブジェクトタイプの名前であり、yがOBJECT IDENTIFIERであるかは方法でそれを断片化します。
Case, Fedor, Schoffstall, & Davin [Page 11] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[11ページ]RFC1098SNMP1989年4月
specific to the named object type, identifies the desired instance.
名前付のオブジェクトへの詳細は、タイプして、必要なインスタンスを特定します。
This naming strategy admits the fullest exploitation of the semantics of the GetNextRequest-PDU (see Section 4), because it assigns names for related variables so as to be contiguous in the lexicographical ordering of all variable names known in the MIB.
この命名戦略はGetNextRequest-PDUの意味論の最もふくよかな攻略を認めます(セクション4を見てください)、MIBで知られているすべての変数名の辞書編集の注文で隣接であり、関連変数のために名前を割り当てるので。
The type-specific naming of object instances is defined below for a number of classes of object types. Instances of an object type to which none of the following naming conventions are applicable are named by OBJECT IDENTIFIERs of the form x.0, where x is the name of said object type in the MIB definition.
オブジェクトインスタンスのタイプ特有の命名は多くのクラスのオブジェクト・タイプのために以下で定義されます。 以下の命名規則のいずれも適切でないオブジェクト・タイプのインスタンスはフォームx.0のOBJECT IDENTIFIERsによって命名されます。(そこでは、xがMIB定義における前述のオブジェクト・タイプの名前です)。
For example, suppose one wanted to identify an instance of the variable sysDescr The object class for sysDescr is:
例えば、1であるなら、可変sysDescrのインスタンスを特定して欲しくて、sysDescrのためのオブジェクトのクラスは以下の通りです。
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
iso org dodインターネット管理mibシステムsysDescr1 3 6 1 2 1 1 1
Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0 identifies the one and only instance of sysDescr.
したがって、オブジェクト・タイプ(x)はいるでしょう。1.3 .6 .1 .2 .1 .1 .1 0に関するサブ識別子のインスタンスが追加される。 すなわち、1.3 .6 .1 .2 .1 .1 .1 .0 sysDescrの唯一無二のインスタンスを特定します。
3.2.6.3.1. ifTable Object Type Names
3.2.6.3.1. ifTableオブジェクト型名
The name of a subnet interface, s, is the OBJECT IDENTIFIER value of the form i, where i has the value of that instance of the ifIndex object type associated with s.
sサブネットインタフェースの名前はフォームのOBJECT IDENTIFIER値です。i(iはifIndexオブジェクト・タイプのそのインスタンスの値を持っている)はsと交際しました。
For each object type, t, for which the defined name, n, has a prefix of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.s, where s is the name of the subnet interface about which i represents information.
各オブジェクト・タイプ、tにちなんで、インスタンス、tのiはフォームn.sのOBJECT IDENTIFIERによって命名されます、sが私が情報を表すサブネットインタフェースの名前であるところで。(nという定義された名前には、tに関してifEntryの接頭語があります)。
For example, suppose one wanted to identify the instance of the variable ifType associated with interface 2. Accordingly, ifType.2 would identify the desired instance.
例えば、1つがインタフェース2に関連している可変ifTypeのインスタンスを特定したがっていたと仮定してください。 それに従って、ifType.2は必要なインスタンスを特定するでしょう。
3.2.6.3.2. atTable Object Type Names
3.2.6.3.2. atTableオブジェクト型名
The name of an AT-cached network address, x, is an OBJECT IDENTIFIER of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar "dot" notation) of the atNetAddress object type associated with x.
x ATによってキャッシュされたネットワーク・アドレスの名前はフォーム1.a.b.c.dのOBJECT IDENTIFIERです。そこでは、a.b.c.dはxに関連づけられたatNetAddressオブジェクト・タイプの値(身近な「ドット」記法による)です。
The name of an address translation equivalence e is an OBJECT IDENTIFIER value of the form s.w, such that s is the value of that instance of the atIndex object type associated with e and such that w is the name of the AT-cached network address associated with e.
アドレス変換の等価性eの名前はフォームs.wのOBJECT IDENTIFIER値です、sがeに関連づけられたatIndexオブジェクト・タイプのそのインスタンスの値であり、wがeに関連しているATによってキャッシュされたネットワーク・アドレスの名前であるように。
Case, Fedor, Schoffstall, & Davin [Page 12] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[12ページ]RFC1098SNMP1989年4月
For each object type, t, for which the defined name, n, has a prefix of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the address translation equivalence about which i represents information.
各オブジェクト・タイプ、tにちなんで、インスタンス、tのiはフォームn.yのOBJECT IDENTIFIERによって命名されます、yが私が情報を表すアドレス変換の等価性の名前であるところで。(nという定義された名前には、tに関してatEntryの接頭語があります)。
For example, suppose one wanted to find the physical address of an entry in the address translation table (ARP cache) associated with an IP address of 89.1.1.42 and interface 3. Accordingly, atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
例えば、1つが89.1の.1の.42とインタフェース3のIPアドレスに関連しているアドレス変換テーブル(ARPキャッシュ)でエントリーの物理アドレスを見つけたがっていたと仮定してください。 それに従って、atPhysAddress、.3 .1 .89 .1 .1 .42は必要なインスタンスを特定するでしょう。
3.2.6.3.3. ipAddrTable Object Type Names
3.2.6.3.3. ipAddrTableオブジェクト型名
The name of an IP-addressable network element, x, is the OBJECT IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the familiar "dot" notation) of that instance of the ipAdEntAddr object type associated with x.
x IPアドレス可能なネットワーク要素の名前がフォームa.b.c.dのOBJECT IDENTIFIERであるので、a.b.c.dはxに関連づけられたipAdEntAddrオブジェクト・タイプのそのインスタンスの値(身近な「ドット」記法による)です。
For each object type, t, for which the defined name, n, has a prefix of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the IP-addressable network element about which i represents information.
各オブジェクト・タイプ、tにちなんで、インスタンス、tのiはフォームn.yのOBJECT IDENTIFIERによって命名されます、yが私が情報を表すIPアドレス可能なネットワーク要素の名前であるところで。(nという定義された名前には、tに関してipAddrEntryの接頭語があります)。
For example, suppose one wanted to find the network mask of an entry in the IP interface table associated with an IP address of 89.1.1.42. Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired instance.
例えば、1つが.42に89.1のIPアドレスに関連しているIPインタフェーステーブルのエントリーのネットワークマスクに.1を見つけたがっていたと仮定してください。 それに従って、ipAdEntNetMask、.89 .1 .1 .42は必要なインスタンスを特定するでしょう。
3.2.6.3.4. ipRoutingTable Object Type Names
3.2.6.3.4. ipRoutingTableオブジェクト型名
The name of an IP route, x, is the OBJECT IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the familiar "dot" notation) of that instance of the ipRouteDest object type associated with x.
x IPルートの名前がフォームa.b.c.dのOBJECT IDENTIFIERであるので、a.b.c.dはxに関連づけられたipRouteDestオブジェクト・タイプのそのインスタンスの値(身近な「ドット」記法による)です。
For each object type, t, for which the defined name, n, has a prefix of ipRoutingEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the IP route about which i represents information.
各オブジェクト・タイプ、tにちなんで、インスタンス、tのiはフォームn.yのOBJECT IDENTIFIERによって命名されます、yが私が情報を表すIPルートの名前であるところで。(nという定義された名前には、tに関してipRoutingEntryの接頭語があります)。
For example, suppose one wanted to find the next hop of an entry in the IP routing table associated with the destination of 89.1.1.42. Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired instance.
例えば、1つが.42に89.1の目的地に関連しているIP経路指定テーブルのエントリーの次のホップに.1を見つけたがっていたと仮定してください。 それに従って、ipRouteNextHop、.89 .1 .1 .42は必要なインスタンスを特定するでしょう。
3.2.6.3.5. tcpConnTable Object Type Names
3.2.6.3.5. tcpConnTableオブジェクト型名
The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
x TCP接続の名前がフォームa.b.c.d.e.f.g.h.i.jのOBJECT IDENTIFIERであるのでa.b.c.dが値である、(なじみ深さ
Case, Fedor, Schoffstall, & Davin [Page 13] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[13ページ]RFC1098SNMP1989年4月
"dot" notation) of that instance of the tcpConnLocalAddress object type associated with x and such that f.g.h.i is the value (in the familiar "dot" notation) of that instance of the tcpConnRemoteAddress object type associated with x and such that e is the value of that instance of the tcpConnLocalPort object type associated with x and such that j is the value of that instance of the tcpConnRemotePort object type associated with x.
「ドット」記法) tcpConnLocalAddressのそのインスタンスでは、xに関連しているオブジェクト・タイプとf.g.h.iがtcpConnRemoteAddressオブジェクト・タイプのそのインスタンスの値(身近な「ドット」記法による)であるようにものはxと交際して、eがtcpConnLocalPortオブジェクト・タイプのそのインスタンスの値であるようにものはxと交際して、jがtcpConnRemotePortオブジェクト・タイプのそのインスタンスの値であるようにものはxと交際しました。
For each object type, t, for which the defined name, n, has a prefix of tcpConnEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the TCP connection about which i represents information.
各オブジェクト・タイプ、tにちなんで、インスタンス、tのiはフォームn.yのOBJECT IDENTIFIERによって命名されます、yが私が情報を表すTCP接続の名前であるところで。(nという定義された名前には、tに関してtcpConnEntryの接頭語があります)。
For example, suppose one wanted to find the state of a TCP connection between the local address of 89.1.1.42 on TCP port 21 and the remote address of 10.0.0.51 on TCP port 2059. Accordingly, tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired instance.
例えば、1であるなら、89.1のローカルアドレスの間のTCP関係の状態が.0がTCPポート21とリモートの.42が10.0を扱う.1であることがわかって欲しくて、TCPの上の.51は2059を移植します。 それに従って、tcpConnState、.89 .1 .1 .42 .21 .10 .0 .0 .51 .2059は必要なインスタンスを特定するでしょう。
3.2.6.3.6. egpNeighTable Object Type Names
3.2.6.3.6. egpNeighTableオブジェクト型名
The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the familiar "dot" notation) of that instance of the egpNeighAddr object type associated with x.
x EGP隣人の名前がフォームa.b.c.dのOBJECT IDENTIFIERであるので、a.b.c.dはxに関連づけられたegpNeighAddrオブジェクト・タイプのそのインスタンスの値(身近な「ドット」記法による)です。
For each object type, t, for which the defined name, n, has a prefix of egpNeighEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of the form n.y, where y is the name of the EGP neighbor about which i represents information.
各オブジェクト・タイプ、tにちなんで、インスタンス、tのiはフォームn.yのOBJECT IDENTIFIERによって命名されます、yが私が情報を表すEGP隣人の名前であるところで。(nという定義された名前には、tに関してegpNeighEntryの接頭語があります)。
For example, suppose one wanted to find the neighbor state for the IP address of 89.1.1.42. Accordingly, egpNeighState.89.1.1.42 would identify the desired instance.
例えば、1つが.1がIPのための州が89.1を扱う隣人のために.42を見つけたがっていたと仮定してください。 それに従って、egpNeighState、.89 .1 .1 .42は必要なインスタンスを特定するでしょう。
Case, Fedor, Schoffstall, & Davin [Page 14] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[14ページ]RFC1098SNMP1989年4月
4. Protocol Specification
4. プロトコル仕様
The network management protocol is an application protocol by which the variables of an agent's MIB may be inspected or altered.
ネットワーク管理プロトコルはエージェントのMIBの変数が点検されるか、または変更されるかもしれないアプリケーション・プロトコルです。
Communication among protocol entities is accomplished by the exchange of messages, each of which is entirely and independently represented within a single UDP datagram using the basic encoding rules of ASN.1 (as discussed in Section 3.2.2). A message consists of a version identifier, an SNMP community name, and a protocol data unit (PDU). A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps (i.e., all messages except those which contain the Trap-PDU). Messages which report traps should be received on UDP port 162 for further processing. An implementation of this protocol need not accept messages whose length exceeds 484 octets. However, it is recommended that implementations support larger datagrams whenever feasible.
プロトコル実体の中のコミュニケーションはメッセージの交換で達成されます。ASN.1の基本的な符号化規則を使用することで(セクション3.2.2で議論するように)それは単一のUDPデータグラムの中にそれぞれ完全に独自に表されます。 メッセージはバージョン識別子、SNMP共同体名、およびプロトコルデータ単位(PDU)から成ります。 プロトコル実体はそれが罠(Trap-PDUを含むもの以外のすなわちすべてのメッセージ)を報告するもの以外のすべてのメッセージのために関連づけられるホストの上のUDPポート161にメッセージを受け取ります。 さらなる処理のためにUDPポート162の上に罠を報告するメッセージを受け取るべきです。 このプロトコルの実装は長さが484の八重奏を超えているメッセージを受け入れる必要はありません。 しかしながら、可能であるときはいつも、実装が、より大きいデータグラムを支えるのは、お勧めです。
It is mandatory that all implementations of the SNMP support the five PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU, and Trap-PDU.
SNMPのすべての実装が5PDUsをサポートするのは、義務的です: GetRequest-PDU、GetNextRequest-PDU、GetResponse-PDU、SetRequest-PDU、および罠-PDU。
RFC1098-SNMP DEFINITIONS ::= BEGIN
RFC1098-SNMP定義:、:= 始まってください。
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1065-SMI;
RFC1065-SMIからObjectName、ObjectSyntax、NetworkAddress、IpAddress、TimeTicksをインポートします。
-- top-level message
-- トップレベルメッセージ
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
以下を通信させてください:= SEQUENCE、バージョン--このRFC INTEGERバージョン-1(0)のためのバージョン-1
community -- community name
OCTET STRING,
共同体--共同体はOCTET STRINGを命名します。
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
データ--、例えば、PDUs、些細である、少しも、認証は使用されています。
Case, Fedor, Schoffstall, & Davin [Page 15] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[15ページ]RFC1098SNMP1989年4月
-- protocol data units
-- プロトコルデータ単位
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
PDUs:、:= CHOICE、要求を得ているGetRequest-PDU
get-next-request
GetNextRequest-PDU,
次の要求を得ているGetNextRequest-PDU
get-response
GetResponse-PDU,
応答を得ているGetResponse-PDU
set-request
SetRequest-PDU,
SetRequest-PDUをセット要求してください。
trap
Trap-PDU
}
Trap-PDUを捕らえてください。
-- the individual PDUs and commonly used
-- data types will be defined later
-- 個々のPDUsで一般的に使用--データ型は後で定義されるでしょう。
END
終わり
4.1. Elements of Procedure
4.1. 手順のElements
This section describes the actions of a protocol entity implementing the SNMP. Note, however, that it is not intended to constrain the internal architecture of any conformant implementation.
このセクションはSNMPを実装するプロトコル実体の動作について説明します。 しかしながら、どんなconformant実装の内部のアーキテクチャも抑制することを意図しないことに注意してください。
In the text that follows, the term transport address is used. In the case of the UDP, a transport address consists of an IP address along with a UDP port. Other transport services may be used to support the SNMP. In these cases, the definition of a transport address should be made accordingly.
従うテキストでは、用語輸送アドレスは使用されています。 UDPの場合では、輸送アドレスはUDPポートに伴うIPアドレスから成ります。 他の輸送サービスは、SNMPをサポートするのに使用されるかもしれません。 これらの場合では、それに従って、輸送アドレスの定義をするべきです。
The top-level actions of a protocol entity which generates a message are as follows:
メッセージを生成するプロトコル実体のトップレベル動作は以下の通りです:
(1) It first constructs the appropriate PDU, e.g., the
GetRequest-PDU, as an ASN.1 object.
(1) ASN.1が反対するようにそれは最初に、適切なPDU、例えばGetRequest-PDUを組み立てます。
(2) It then passes this ASN.1 object along with a community
name its source transport address and the destination
transport address, to the service which implements the
desired authentication scheme. This authentication
(2) 次に、ソース輸送アドレスと送付先輸送アドレスを共同体名に伴うこのASN.1オブジェクトに通過します、必要な認証体系を実装するサービスに。 この認証
Case, Fedor, Schoffstall, & Davin [Page 16] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[16ページ]RFC1098SNMP1989年4月
service returns another ASN.1 object.
サービスは別のASN.1オブジェクトを返します。
(3) The protocol entity then constructs an ASN.1 Message
object, using the community name and the resulting ASN.1
object.
(3) そして、共同体名と結果として起こるASN.1オブジェクトを使用して、プロトコル実体はASN.1Messageオブジェクトを組み立てます。
(4) This new ASN.1 object is then serialized, using the basic
encoding rules of ASN.1, and then sent using a transport
service to the peer protocol entity.
(4) この新しいASN.1オブジェクトに次に、ASN.1の基本的な符号化規則を使用して、連載して、次に、同輩プロトコル実体への輸送サービスを使用させます。
Similarly, the top-level actions of a protocol entity which receives a message are as follows:
同様に、メッセージを受け取るプロトコル実体のトップレベル動作は以下の通りです:
(1) It performs a rudimentary parse of the incoming datagram
to build an ASN.1 object corresponding to an ASN.1
Message object. If the parse fails, it discards the
datagram and performs no further actions.
(1) それは初歩的にaを実行します。受信データグラムを分析して、ASN.1Messageオブジェクトに対応するASN.1オブジェクトを造ってください。 やり損ないを分析してください、それは、データグラムを捨てて、これ以上動作を実行しません。
(2) It then verifies the version number of the SNMP message.
If there is a mismatch, it discards the datagram and
performs no further actions.
(2) そして、それはSNMPメッセージのバージョン番号について確かめます。 ミスマッチがあれば、それは、データグラムを捨てて、これ以上動作を実行しません。
(3) The protocol entity then passes the community name and
user data found in the ASN.1 Message object, along with
the datagram's source and destination transport addresses
to the service which implements the desired
authentication scheme. This entity returns another ASN.1
object, or signals an authentication failure. In the
latter case, the protocol entity notes this failure,
(possibly) generates a trap, and discards the datagram
and performs no further actions.
(3) 次に、プロトコル実体はASN.1Messageオブジェクトで見つけられた共同体名と利用者データを通過します、輸送が必要な認証体系を実装するサービスに演説するデータグラムのソースと目的地と共に。 この実体は、別のASN.1オブジェクトを返すか、または認証失敗を示します。 後者の場合では、プロトコル実体は、この失敗に注意して、(ことによると)罠、および破棄がデータグラムであると生成して、さらなる動作を全く実行しません。
(4) The protocol entity then performs a rudimentary parse on
the ASN.1 object returned from the authentication service
to build an ASN.1 object corresponding to an ASN.1 PDUs
object. If the parse fails, it discards the datagram and
performs no further actions. Otherwise, using the named
SNMP community, the appropriate profile is selected, and
the PDU is processed accordingly. If, as a result of
this processing, a message is returned then the source
transport address that the response message is sent from
shall be identical to the destination transport address
that the original request message was sent to.
(4) 次に、プロトコル実体は初歩的にaを実行します。ASN.1PDUsオブジェクトに対応するASN.1オブジェクトを造るために認証サービスから返されたASN.1オブジェクトの上に分析してください。 やり損ないを分析してください、それは、データグラムを捨てて、これ以上動作を実行しません。 さもなければ、命名されたSNMP共同体を使用して、適切なプロフィールは選択されます、そして、PDUはそれに従って、処理されます。 この処理の結果、メッセージを返すと、応答メッセージが送られるソース輸送アドレスはオリジナルの要求メッセージが送られた送付先輸送アドレスと同じになるでしょう。
Case, Fedor, Schoffstall, & Davin [Page 17] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[17ページ]RFC1098SNMP1989年4月
4.1.1. Common Constructs
4.1.1. 一般的な構造物
Before introducing the six PDU types of the protocol, it is appropriate to consider some of the ASN.1 constructs used frequently:
プロトコルの6つのPDUタイプを導入する前に、頻繁に使用されるASN.1構造物のいくつかを考えるのは適切です:
-- request/response information
-- 要求/応答情報
RequestID ::=
INTEGER
RequestID:、:= 整数
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
ErrorStatus:、:= 整数noError(0)、tooBig(1)、noSuchName(2)、badValue(3)、readOnly(4) genErr(5)
ErrorIndex ::=
INTEGER
ErrorIndex:、:= 整数
-- variable bindings
-- 変項束縛
VarBind ::=
SEQUENCE {
name
ObjectName,
VarBind:、:= SEQUENCE、ObjectNameを命名してください。
value
ObjectSyntax
}
ObjectSyntaxを評価してください。
VarBindList ::=
SEQUENCE OF
VarBind
VarBindList:、:= VarBindの系列
RequestIDs are used to distinguish among outstanding requests. By use of the RequestID, an SNMP application entity can correlate incoming responses with outstanding requests. In cases where an unreliable datagram service is being used, the RequestID also provides a simple means of identifying messages duplicated by the network.
RequestIDsは、傑出している要求の中で区別するのに使用されます。 RequestIDの使用で、SNMPアプリケーション実体は傑出している要求で入って来る応答を関連させることができます。 また、頼り無いデータグラムサービスが使用されている場合では、RequestIDはネットワークによってコピーされたメッセージを特定する簡潔な方法を提供します。
A non-zero instance of ErrorStatus is used to indicate that an
ErrorStatusの非ゼロインスタンスは、それを示すのに使用されます。
Case, Fedor, Schoffstall, & Davin [Page 18] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[18ページ]RFC1098SNMP1989年4月
exception occurred while processing a request. In these cases, ErrorIndex may provide additional information by indicating which variable in a list caused the exception.
例外は要求を処理している間、起こりました。 これらの場合では、リストのどの変数が例外を引き起こしたかを示すことによって、ErrorIndexは追加情報を提供するかもしれません。
The term variable refers to an instance of a managed object. A variable binding, or VarBind, refers to the pairing of the name of a variable to the variable's value. A VarBindList is a simple list of variable names and corresponding values. Some PDUs are concerned only with the name of a variable and not its value (e.g., the GetRequest-PDU). In this case, the value portion of the binding is ignored by the protocol entity. However, the value portion must still have valid ASN.1 syntax and encoding. It is recommended that the ASN.1 value NULL be used for the value portion of such bindings.
可変であるという用語は管理オブジェクトのインスタンスについて言及します。 変項束縛、またはVarBindが変数の名前の組み合わせを変数の値と呼びます。 VarBindListは変数名と換算値に関する単純並びです。 いくつかのPDUsが値(例えば、GetRequest-PDU)ではなく、変数の名前だけに関係があります。 この場合、結合の値の部分はプロトコル実体によって無視されます。 しかしながら、値の部分には、まだ、有効なASN.1構文とコード化がなければなりません。 ASN.1値のNULLがそのような結合の値の部分に使用されるのは、お勧めです。
4.1.2. The GetRequest-PDU
4.1.2. GetRequest-PDU
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
GetRequest-PDUのフォームは以下の通りです。 GetRequest-PDU:、:= [0] IMPLICIT SEQUENCE、要求イドRequestID
error-status -- always 0
ErrorStatus,
エラー状況--いつも0ErrorStatus
error-index -- always 0
ErrorIndex,
誤りインデックス--いつも0ErrorIndex
variable-bindings
VarBindList
}
変項束縛VarBindList
The GetRequest-PDU is generated by a protocol entity only at the request of its SNMP application entity.
GetRequest-PDUは単にSNMPアプリケーション実体の依頼でプロトコル実体によって生成されます。
Upon receipt of the GetRequest-PDU, the receiving protocol entity responds according to any applicable rule in the list below:
GetRequest-PDUを受け取り次第、以下のリストのどんな適切な規則に従っても、受信プロトコル実体は応じます:
(1) If, for any object named in the variable-bindings field,
the object's name does not exactly match the name of some
object available for get operations in the relevant MIB
view, then the receiving entity sends to the originator
of the received message the GetResponse-PDU of identical
form, except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
(1) 変数結合分野で指定されたどんなオブジェクトのためのオブジェクトの名前もまさに名前に合っていないなら、いくつかでは、利用可能な状態で反対してください。関連MIB視点における操作を得てください、そして、次に、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がnoSuchNameであるのを除いて誤りインデックス部の値が受け取られているところの前述のオブジェクト名コンポーネントのインデックスです。
Case, Fedor, Schoffstall, & Davin [Page 19] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[19ページ]RFC1098SNMP1989年4月
message.
メッセージ。
(2) If, for any object named in the variable-bindings field,
the object is an aggregate type (as defined in the SMI),
then the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is
noSuchName, and the value of the error-index field is the
index of said object name component in the received
message.
(2) 受信実体はオブジェクトが変項束縛分野で指定されたどんなオブジェクトに関する集成型(SMIで定義されるように)であるならも同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がnoSuchNameであり、誤りインデックス部の値が受信されたメッセージの前述のオブジェクト名コンポーネントのインデックスであるのを除いて。
(3) If the size of the GetResponse-PDU generated as described
below would exceed a local limitation, then the receiving
entity sends to the originator of the received message
the GetResponse-PDU of identical form, except that the
value of the error-status field is tooBig, and the value
of the error-index field is zero.
(3) 以下で説明されるように生成されたGetResponse-PDUのサイズが地方の制限を超えているなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がtooBigであり、誤りインデックス部の値がゼロであるのを除いて。
(4) If, for any object named in the variable-bindings field,
the value of the object cannot be retrieved for reasons
not covered by any of the foregoing rules, then the
receiving entity sends to the originator of the received
message the GetResponse-PDU of identical form, except
that the value of the error-status field is genErr and
the value of the error-index field is the index of said
object name component in the received message.
(4) 以上の規則のいずれでもカバーされなかった理由で変項束縛分野で指定されたどんなオブジェクトに関してもオブジェクトの値を検索できないなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がgenErrであり、誤りインデックス部の値が受信されたメッセージの前述のオブジェクト名コンポーネントのインデックスであるのを除いて。
If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of the received message the GetResponse-PDU such that, for each object named in the variable- bindings field of the received message, the corresponding component of the GetResponse-PDU represents the name and value of that variable. The value of the error- status field of the GetResponse- PDU is noError and the value of the error-index field is zero. The value of the request-id field of the GetResponse-PDU is that of the received message.
以上の規則のいずれも適用されないなら、受信プロトコル実体は、GetResponse-PDUの対応する部品が受信されたメッセージの可変結合分野で指定された各オブジェクトに関してその変数の名前と値を表すように、受信されたメッセージの創始者にGetResponse-PDUを送ります。 GetResponse- PDUの誤り状態分野の値はnoErrorです、そして、誤りインデックス部の値はゼロです。 GetResponse-PDUの要求イド分野の値は受信されたメッセージのものです。
4.1.3. The GetNextRequest-PDU
4.1.3. GetNextRequest-PDU
The form of the GetNextRequest-PDU is identical to that of the GetRequest-PDU except for the indication of the PDU type. In the ASN.1 language:
GetNextRequest-PDUのフォームはPDUタイプのしるし以外のGetRequest-PDUのものと同じです。 ASN.1言語で:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
GetNextRequest-PDU:、:= [1] IMPLICIT SEQUENCE、要求イドRequestID
Case, Fedor, Schoffstall, & Davin [Page 20] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[20ページ]RFC1098SNMP1989年4月
error-status -- always 0
ErrorStatus,
エラー状況--いつも0ErrorStatus
error-index -- always 0
ErrorIndex,
誤りインデックス--いつも0ErrorIndex
variable-bindings
VarBindList
}
変項束縛VarBindList
The GetNextRequest-PDU is generated by a protocol entity only at the request of its SNMP application entity.
GetNextRequest-PDUは単にSNMPアプリケーション実体の依頼でプロトコル実体によって生成されます。
Upon receipt of the GetNextRequest-PDU, the receiving protocol entity responds according to any applicable rule in the list below:
GetNextRequest-PDUを受け取り次第、以下のリストのどんな適切な規則に従っても、受信プロトコル実体は応じます:
(1) If, for any object name in the variable-bindings field,
that name does not lexicographically precede the name of
some object available for get operations in the relevant
MIB view, then the receiving entity sends to the
originator of the received message the GetResponse-PDU of
identical form, except that the value of the error-status
field is noSuchName, and the value of the error-index
field is the index of said object name component in the
received message.
(1) 何か変項束縛分野のオブジェクト名のために、名前が辞書編集に利用可能な状態であるオブジェクトの名前に先行しないのが関連MIB視点における操作を届けて、次に、エラー状況分野の値がnoSuchNameであるのを除いて、受信実体が同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送るか、そして、誤りインデックス部の値は受信されたメッセージの前述のオブジェクト名コンポーネントのインデックスです。
(2) If the size of the GetResponse-PDU generated as described
below would exceed a local limitation, then the receiving
entity sends to the originator of the received message
the GetResponse-PDU of identical form, except that the
value of the error-status field is tooBig, and the value
of the error-index field is zero.
(2) 以下で説明されるように生成されたGetResponse-PDUのサイズが地方の制限を超えているなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がtooBigであり、誤りインデックス部の値がゼロであるのを除いて。
(3) If, for any object named in the variable-bindings field,
the value of the lexicographical successor to the named
object cannot be retrieved for reasons not covered by any
of the foregoing rules, then the receiving entity sends
to the originator of the received message the
GetResponse-PDU of identical form, except that the value
of the error-status field is genErr and the value of the
error-index field is the index of said object name
component in the received message.
(3) 以上の規則のいずれでもカバーされなかった理由で変項束縛分野で指定されたどんなオブジェクトに関しても命名されたオブジェクトの辞書編集の後継者の価値を検索できないなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がgenErrであり、誤りインデックス部の値が受信されたメッセージの前述のオブジェクト名コンポーネントのインデックスであるのを除いて。
If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of the received message the GetResponse-PDU such that, for each name in the variable-bindings field of the received message, the corresponding component of the
以上の規則のいずれも適用されないなら受信プロトコル実体が受信されたメッセージの創始者にGetResponse-PDUを送る、それぞれにちなんで、中で受信されたメッセージの変項束縛分野を命名してください、対応するコンポーネントのようなもの
Case, Fedor, Schoffstall, & Davin [Page 21] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[21ページ]RFC1098SNMP1989年4月
GetResponse-PDU represents the name and value of that object whose name is, in the lexicographical ordering of the names of all objects available for get operations in the relevant MIB view, together with the value of the name field of the given component, the immediate successor to that value. The value of the error-status field of the GetResponse-PDU is noError and the value of the errorindex field is zero. The value of the request-id field of the GetResponse-PDU is that of the received message.
GetResponse-PDUは名前を表します、そして、名前があって、すべての名前の辞書編集の注文で利用可能な状態で反対するそのオブジェクトの値は関連MIB視点における操作を得ます、与えられたコンポーネントの名前欄の値と共に、その値のすぐ次の後継者。 GetResponse-PDUのエラー状況分野の値はnoErrorです、そして、errorindex分野の値はゼロです。 GetResponse-PDUの要求イド分野の値は受信されたメッセージのものです。
4.1.3.1. Example of Table Traversal
4.1.3.1. テーブル縦断に関する例
One important use of the GetNextRequest-PDU is the traversal of conceptual tables of information within the MIB. The semantics of this type of SNMP message, together with the protocol-specific mechanisms for identifying individual instances of object types in the MIB, affords access to related objects in the MIB as if they enjoyed a tabular organization.
GetNextRequest-PDUの1つの重要な使用はMIBの中の情報の概念的なテーブルの縦断です。 まるで彼らが表組織を楽しむかのようにこのタイプに関するSNMPメッセージの意味論はMIBのオブジェクト・タイプの個々のインスタンスを特定するためのプロトコル特有のメカニズムと共にMIBの関連するオブジェクトへのアクセスを提供します。
By the SNMP exchange sketched below, an SNMP application entity might extract the destination address and next hop gateway for each entry in the routing table of a particular network element. Suppose that this routing table has three entries:
以下にスケッチされたSNMP交換で、SNMPアプリケーション実体は特定のネットワーク要素の経路指定テーブルの各エントリーに送付先アドレスと隣のホップゲートウェイを抜粋するかもしれません。 この経路指定テーブルには3つのエントリーがあると仮定してください:
Destination NextHop Metric
目的地、NextHopメートル法
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
10.0.0.99 89.1.1.42 5 9.1.2.3 99.0.0.3 3 10.0.0.51 89.1.1.42 5
The management station sends to the SNMP agent a GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as the requested variable names:
管理局は要求された変数名として示されたOBJECT IDENTIFIER値を含むGetNextRequest-PDUをSNMPエージェントに送ります:
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
GetNextRequest(ipRouteDest、ipRouteNextHop、ipRouteMetric1)
The SNMP agent responds with a GetResponse-PDU:
SNMPエージェントはGetResponse-PDUと共に応じます:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
GetResponse(ipRouteDest.9.1.2.3=、「9.1 .2 0.3インチ)、(ipRouteNextHop.9.1.2.3=、「99.0 .0 0.3インチ)、(ipRouteMetric1.9、.1、.2、.3、=3)、」
The management station continues with:
管理局は以下で続きます。
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
GetNextRequest、(ipRouteDest、.9 .1 .2 .3、ipRouteNextHop、.9 .1 .2 .3
Case, Fedor, Schoffstall, & Davin [Page 22] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[22ページ]RFC1098SNMP1989年4月
ipRouteMetric1.9.1.2.3 )
ipRouteMetric1.9.1.2、.3)
The SNMP agent responds:
SNMPエージェントは応じます:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
GetResponse(ipRouteDest.10.0.0.51=、「10.0 .0 0.51インチ)、(ipRouteNextHop.10.0.0.51=、「89.1 .1 0.42インチ)、(ipRouteMetric1.10、.0、.0、.51、=5)、」
The management station continues with:
管理局は以下で続きます。
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
GetNextRequest(ipRouteDest.10.0、.0、.51、ipRouteNextHop.10.0、.0、.51、ipRouteMetric1.10.0.0、.51)
The SNMP agent responds:
SNMPエージェントは応じます:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
GetResponse(ipRouteDest.10.0.0.99=、「10.0 .0 0.99インチ)、(ipRouteNextHop.10.0.0.99=、「89.1 .1 0.42インチ)、(ipRouteMetric1.10、.0、.0、.99、=5)、」
The management station continues with:
管理局は以下で続きます。
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
GetNextRequest(ipRouteDest.10.0、.0、.99、ipRouteNextHop.10.0、.0、.99、ipRouteMetric1.10.0.0、.99)
As there are no further entries in the table, the SNMP agent returns those objects that are next in the lexicographical ordering of the known object names. This response signals the end of the routing table to the management station.
エントリーがこれ以上テーブルにないとき、SNMPエージェントはそれらの知られているオブジェクト名の辞書編集の注文で次のオブジェクトを返します。 この応答は経路指定テーブルの端を管理局に示します。
4.1.4. The GetResponse-PDU
4.1.4. GetResponse-PDU
The form of the GetResponse-PDU is identical to that of the GetRequest-PDU except for the indication of the PDU type. In the ASN.1 language:
GetResponse-PDUのフォームはPDUタイプのしるし以外のGetRequest-PDUのものと同じです。 ASN.1言語で:
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
GetResponse-PDU:、:= [2] IMPLICIT SEQUENCE、要求イドRequestID
Case, Fedor, Schoffstall, & Davin [Page 23] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[23ページ]RFC1098SNMP1989年4月
error-status
ErrorStatus,
エラー状況ErrorStatus
error-index
ErrorIndex,
誤りインデックスErrorIndex
variable-bindings
VarBindList
}
変項束縛VarBindList
The GetResponse-PDU is generated by a protocol entity only upon receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU, as described elsewhere in this document.
GetResponse-PDUは単にGetRequest-PDU、GetNextRequest-PDU、またはSetRequest-PDUを受け取り次第プロトコル実体によって生成されます、ほかの場所で本書では説明されるように。
Upon receipt of the GetResponse-PDU, the receiving protocol entity presents its contents to its SNMP application entity.
GetResponse-PDUを受け取り次第、受信プロトコル実体はSNMPアプリケーション実体にコンテンツを提示します。
4.1.5. The SetRequest-PDU
4.1.5. SetRequest-PDU
The form of the SetRequest-PDU is identical to that of the GetRequest-PDU except for the indication of the PDU type. In the ASN.1 language:
SetRequest-PDUのフォームはPDUタイプのしるし以外のGetRequest-PDUのものと同じです。 ASN.1言語で:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
SetRequest-PDU:、:= [3] IMPLICIT SEQUENCE、要求イドRequestID
error-status -- always 0
ErrorStatus,
エラー状況--いつも0ErrorStatus
error-index -- always 0
ErrorIndex,
誤りインデックス--いつも0ErrorIndex
variable-bindings
VarBindList
}
変項束縛VarBindList
The SetRequest-PDU is generated by a protocol entity only at the request of its SNMP application entity.
SetRequest-PDUは単にSNMPアプリケーション実体の依頼でプロトコル実体によって生成されます。
Upon receipt of the SetRequest-PDU, the receiving entity responds according to any applicable rule in the list below:
SetRequest-PDUを受け取り次第、以下のリストのどんな適切な規則に従っても、受信実体は応じます:
(1) If, for any object named in the variable-bindings field,
(1)、変項束縛分野でどんなオブジェクトにちなんでも命名されています。
Case, Fedor, Schoffstall, & Davin [Page 24] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[24ページ]RFC1098SNMP1989年4月
the object is not available for set operations in the
relevant MIB view, then the receiving entity sends to the
originator of the received message the GetResponse-PDU of
identical form, except that the value of the error-status
field is noSuchName, and the value of the error-index
field is the index of said object name component in the
received message.
オブジェクトが関連MIB視点における集合演算に利用可能でない、次に、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がnoSuchNameであり、誤りインデックス部の値が受信されたメッセージの前述のオブジェクト名コンポーネントのインデックスであるのを除いて。
(2) If, for any object named in the variable-bindings field,
the contents of the value field does not, according to
the ASN.1 language, manifest a type, length, and value
that is consistent with that required for the variable,
then the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is
badValue, and the value of the error-index field is the
index of said object name in the received message.
(2) ASN.1言語に従って値の分野のコンテンツが変項束縛分野で指定されたどんなオブジェクトに関しても変数に必要であるそれと一致したタイプ、長さ、および値を表さないなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がbadValueであり、誤りインデックス部の値が受信されたメッセージの前述のオブジェクト名のインデックスであるのを除いて。
(3) If the size of the Get Response type message generated as
described below would exceed a local limitation, then the
receiving entity sends to the originator of the received
message the GetResponse-PDU of identical form, except
that the value of the error-status field is tooBig, and
the value of the error-index field is zero.
(3) 以下で説明されるように生成されたGet Responseタイプメッセージのサイズが地方の制限を超えているなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がtooBigであり、誤りインデックス部の値がゼロであるのを除いて。
(4) If, for any object named in the variable-bindings field,
the value of the named object cannot be altered for
reasons not covered by any of the foregoing rules, then
the receiving entity sends to the originator of the
received message the GetResponse-PDU of identical form,
except that the value of the error-status field is genErr
and the value of the error-index field is the index of
said object name component in the received message.
(4) 以上の規則のいずれでもカバーされなかった理由で変項束縛分野で指定されたどんなオブジェクトに関しても命名されたオブジェクトの値を変更できないなら、受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります、エラー状況分野の値がgenErrであり、誤りインデックス部の値が受信されたメッセージの前述のオブジェクト名コンポーネントのインデックスであるのを除いて。
If none of the foregoing rules apply, then for each object named in the variable-bindings field of the received message, the corresponding value is assigned to the variable. Each variable assignment specified by the SetRequest-PDU should be effected as if simultaneously set with respect to all other assignments specified in the same message.
以上の規則のいずれも適用されないなら、受信されたメッセージの変項束縛分野で指定された各オブジェクトに関して換算値は変数に割り当てられます。 SetRequest-PDUによって指定されたそれぞれの可変課題はまるで同時に同じメッセージで指定された他の課題に関して設定されるかのように作用するべきです。
The receiving entity then sends to the originator of the received message the GetResponse-PDU of identical form except that the value of the error-status field of the generated message is noError and the value of the error-index field is zero.
発生しているメッセージのエラー状況分野の値がnoErrorであり、誤りインデックス部の値がゼロであるのを除いて、そして受信実体は同じ形式のGetResponse-PDUを受信されたメッセージの創始者に送ります。
Case, Fedor, Schoffstall, & Davin [Page 25] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[25ページ]RFC1098SNMP1989年4月
4.1.6. The Trap-PDU
4.1.6. PDUを捕らえます。
The form of the Trap-PDU is:
Trap-PDUのフォームは以下の通りです。
Trap-PDU ::=
[4]
罠-PDU:、:= [4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [2]
OBJECT IDENTIFIER,
IMPLICIT SEQUENCE、sysObjectIDは、[2] OBJECT IDENTIFIERで計画(オブジェクトの生成することのタイプ)が捕らえられるのを見ます。
agent-addr -- address of object generating
NetworkAddress, -- trap
エージェント-addr(NetworkAddressを生成するオブジェクトのアドレス)は捕らえられます。
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
ジェネリック罠--ジェネリックはタイプINTEGERのためにcoldStart(0)、warmStart(1)、linkDown(2)、linkUp(3)、authenticationFailure(4)、egpNeighborLoss(5)、enterpriseSpecific(6)を捕らえます。
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
特定の罠--特定のコードはINTEGERにさえジェネリック罠がそうでないならenterpriseSpecificを寄贈します。
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
タイムスタンプ--時間は最後のTimeTicks--ネットワークの(re)初期化--罠の実体と世代の間で経過しました。
variable-bindings -- "interesting" information
VarBindList
}
変項束縛--「おもしろい」情報、VarBindList
The Trap-PDU is generated by a protocol entity only at the request of the SNMP application entity. The means by which an SNMP application entity selects the destination addresses of the SNMP application entities is implementation-specific.
Trap-PDUは単にSNMPアプリケーション実体の依頼でプロトコル実体によって生成されます。 SNMPアプリケーション実体がSNMPアプリケーション実体の送付先アドレスを選択する手段は実装特有です。
Upon receipt of the Trap-PDU, the receiving protocol entity presents its contents to its SNMP application entity.
Trap-PDUを受け取り次第、受信プロトコル実体はSNMPアプリケーション実体にコンテンツを提示します。
Case, Fedor, Schoffstall, & Davin [Page 26] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[26ページ]RFC1098SNMP1989年4月
The significance of the variable-bindings component of the Trap-PDU is implementation-specific.
Trap-PDUの変項束縛の部品の意味は実装特有です。
Interpretations of the value of the generic-trap field are:
ジェネリック罠分野の価値の解釈は以下の通りです。
4.1.6.1. The coldStart Trap
4.1.6.1. コールドスタート罠
A coldStart(0) trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the protocol entity implementation may be altered.
coldStart(0)罠は、送付プロトコル実体がエージェントの構成かプロトコル実体実装を変更できるための再初期化自体であることを意味します。
4.1.6.2. The warmStart Trap
4.1.6.2. warmStart罠
A warmStart(1) trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered.
warmStart(1)罠が、送付プロトコル実体が再初期化自体であることを意味するので、エージェント構成もプロトコル実体実装も変更されません。
4.1.6.3. The linkDown Trap
4.1.6.3. linkDown罠
A linkDown(2) trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration.
linkDown(2)罠は、送付プロトコル実体がエージェントの構成で表された通信リンクの1つにおける失敗を認識するのを意味します。
The Trap-PDU of type linkDown contains as the first element of its variable-bindings, the name and value of the ifIndex instance for the affected interface.
linkDownが影響を受けるインタフェースへのifIndexインスタンスの変項束縛の最初の要素、名前、および値として含むタイプのTrap-PDU。
4.1.6.4. The linkUp Trap
4.1.6.4. 結合罠
A linkUp(3) trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up.
linkUp(3)罠は、送付プロトコル実体が、エージェントの構成で表された通信リンクの1つが来たと認めるのを意味します。
The Trap-PDU of type linkUp contains as the first element of its variable-bindings, the name and value of the ifIndex instance for the affected interface.
linkUpが影響を受けるインタフェースへのifIndexインスタンスの変項束縛の最初の要素、名前、および値として含むタイプのTrap-PDU。
4.1.6.5. The authenticationFailure Trap
4.1.6.5. authenticationFailure罠
An authenticationFailure(4) trap signifies that the sending protocol entity is the addressee of a protocol message that is not properly authenticated. While implementations of the SNMP must be capable of generating this trap, they must also be capable of suppressing the emission of such traps via an implementation-specific mechanism.
authenticationFailure(4)罠は、送付プロトコル実体が適切に認証されないプロトコルメッセージの受け取り人であることを意味します。 また、SNMPの実装がこの罠を生成することができなければならない間、それらは実装特有のメカニズムでそのような罠の放出を抑圧できなければなりません。
4.1.6.6. The egpNeighborLoss Trap
4.1.6.6. egpNeighborLoss罠
An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
egpNeighborLoss(5)罠が意味する、EGPをだれのために近所付き合いさせるか。
Case, Fedor, Schoffstall, & Davin [Page 27] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[27ページ]RFC1098SNMP1989年4月
the sending protocol entity was an EGP peer has been marked down and the peer relationship no longer obtains.
送付プロトコル実体はEGP同輩が関係がもう得ない下であるのと同輩であるとマークされたということでした。
The Trap-PDU of type egpNeighborLoss contains as the first element of its variable-bindings, the name and value of the egpNeighAddr instance for the affected neighbor.
egpNeighborLossが影響を受ける隣人のためのegpNeighAddrインスタンスの変項束縛の最初の要素、名前、および値として含むタイプのTrap-PDU。
4.1.6.7. The enterpriseSpecific Trap
4.1.6.7. enterpriseSpecific罠
A enterpriseSpecific(6) trap signifies that the sending protocol entity recognizes that some enterprise-specific event has occurred. The specific-trap field identifies the particular trap which occurred.
enterpriseSpecific(6)罠は、送付プロトコル実体が、何らかの企業特有のイベントが起こったと認めるのを意味します。 特定の罠分野は起こった特定の罠を特定します。
Case, Fedor, Schoffstall, & Davin [Page 28] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[28ページ]RFC1098SNMP1989年4月
5. Definitions
5. 定義
RFC1098-SNMP DEFINITIONS ::= BEGIN
RFC1098-SNMP定義:、:= 始まってください。
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1065-SMI;
RFC1065-SMIからObjectName、ObjectSyntax、NetworkAddress、IpAddress、TimeTicksをインポートします。
-- top-level message
-- トップレベルメッセージ
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
以下を通信させてください:= SEQUENCE、バージョン--このRFC INTEGERバージョン-1(0)のためのバージョン-1
community -- community name
OCTET STRING,
共同体--共同体はOCTET STRINGを命名します。
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
データ--、例えば、PDUs、些細である、少しも、認証は使用されています。
-- protocol data units
-- プロトコルデータ単位
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
PDUs:、:= CHOICE、要求を得ているGetRequest-PDU
get-next-request
GetNextRequest-PDU,
次の要求を得ているGetNextRequest-PDU
get-response
GetResponse-PDU,
応答を得ているGetResponse-PDU
set-request
SetRequest-PDU,
SetRequest-PDUをセット要求してください。
trap
Trap-PDU
}
Trap-PDUを捕らえてください。
Case, Fedor, Schoffstall, & Davin [Page 29] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[29ページ]RFC1098SNMP1989年4月
-- PDUs
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetRequest-PDU:、:= [0] 内在しているPDU
GetNextRequest-PDU ::=
[1]
IMPLICIT PDU
GetNextRequest-PDU:、:= [1] 内在しているPDU
GetResponse-PDU ::=
[2]
IMPLICIT PDU
GetResponse-PDU:、:= [2] 内在しているPDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
SetRequest-PDU:、:= [3] 内在しているPDU
PDU ::=
SEQUENCE {
request-id
INTEGER,
PDU:、:= SEQUENCE、要求イドINTEGER
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
},
エラー状況--時々INTEGERを無視する、noError(0)、tooBig(1)、noSuchName(2)、badValue(3)、readOnly(4)、genErr(5)
error-index -- sometimes ignored
INTEGER,
誤りインデックス--時々無視されたINTEGER
variable-bindings -- values are sometimes ignored
VarBindList
}
変項束縛--値は時々無視されたVarBindListです。
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [2]
罠-PDU:、:= [4] IMPLICIT SEQUENCE、sysObjectIDは、計画(オブジェクトの生成することのタイプ)が捕らえられるのを中を見ます。[2]
OBJECT IDENTIFIER,
オブジェクト識別子
Case, Fedor, Schoffstall, & Davin [Page 30] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[30ページ]RFC1098SNMP1989年4月
agent-addr -- address of object generating
NetworkAddress, -- trap
エージェント-addr(NetworkAddressを生成するオブジェクトのアドレス)は捕らえられます。
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
ジェネリック罠--ジェネリックはタイプINTEGERのためにcoldStart(0)、warmStart(1)、linkDown(2)、linkUp(3)、authenticationFailure(4)、egpNeighborLoss(5)、enterpriseSpecific(6)を捕らえます。
specific-trap -- specific code, present even
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
特定の罠--特定のコードはINTEGERにさえジェネリック罠がそうでないならenterpriseSpecificを寄贈します。
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the
network
-- entity and the generation of the
trap
タイムスタンプ--時間は最後のTimeTicks--ネットワークの(re)初期化--罠の実体と世代の間で経過しました。
variable-bindings -- "interesting" information
VarBindList
}
変項束縛--「おもしろい」情報、VarBindList
-- variable bindings
-- 変項束縛
VarBind ::=
SEQUENCE {
name
ObjectName,
VarBind:、:= SEQUENCE、ObjectNameを命名してください。
value
ObjectSyntax
}
ObjectSyntaxを評価してください。
VarBindList ::=
SEQUENCE OF
VarBind
VarBindList:、:= VarBindの系列
END
終わり
Case, Fedor, Schoffstall, & Davin [Page 31] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[31ページ]RFC1098SNMP1989年4月
6. Acknowledgements
6. 承認
This memo was influenced by the IETF SNMP Extensions working group:
このメモはIETF SNMP Extensionsワーキンググループによって影響を及ぼされました:
Karl Auerbach, Epilogue Technology
K. Ramesh Babu, Excelan
Amatzia Ben-Artzi, 3Com/Bridge
Lawrence Besaw, Hewlett-Packard
Jeffrey D. Case, University of Tennessee at Knoxville
Anthony Chung, Sytek
James Davidson, The Wollongong Group
James R. Davin, MIT Laboratory for Computer Science
Mark S. Fedor, NYSERNet
Phill Gross, The MITRE Corporation
Satish Joshi, ACC
Dan Lynch, Advanced Computing Environments
Keith McCloghrie, The Wollongong Group
Marshall T. Rose, The Wollongong Group (chair)
Greg Satz, cisco
Martin Lee Schoffstall, Rensselaer Polytechnic Institute
Wengyik Yeong, NYSERNet
カール・アウアーバック、エピローグ技術K.Rameshインド紳士、Excelan Amatziaベン-Artzi、3Com/ブリッジローレンスBesaw、ヒューレット・パッカードジェフリーD.事件、ノクスビルアンソニー・チャン、Sytekジェームス・ディヴィッドソン・ウォロンゴンのテネシー大学はジェームス・R.デーヴィン(MIT Laboratory for Computer ScienceマークS)から構成されています; ヒョードル、NYSERNetフィルGross、MITRE社のサティシュ・ジョーシー、ACCダン・リンチ、Advanced Computing EnvironmentsコクチマスマーチンリーSchoffstall、レンセラー工科大学Wengyik YeongのキースMcCloghrie、ウォロンゴンGroupマーシャル・T.ローズ、ウォロンゴンGroup(いす)グレッグSatz、NYSERNet
Case, Fedor, Schoffstall, & Davin [Page 32] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[32ページ]RFC1098SNMP1989年4月
7. References
7. 参照
[1] Cerf, V., "IAB Recommendations for the Development of
Internet Network Management Standards", RFC 1052, IAB,
April 1988.
[1] サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、IAB、1988年4月。
[2] Rose, M., and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based internets",
RFC 1065, TWG, August 1988.
[2]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、RFC1065、TWG、8月1988日
[3] McCloghrie, K., and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets",
RFC 1066, TWG, August 1988.
[3]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1066、TWG、1988年8月。
[4] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
"A Simple Network Management Protocol", Internet
Engineering Task Force working note, Network Information
Center, SRI International, Menlo Park, California,
March 1988.
[4] J.とM.ヒョードル、M.SchoffstallとJ.デーヴィン、「簡単なネットワーク管理プロトコル」インターネット・エンジニアリング・タスク・フォースが注意を扱うNetworkインフォメーション・センターをケースに入れてください、SRIインターナショナル、1988年のメンローパーク(カリフォルニア)の行進。
[5] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
"A Simple Gateway Monitoring Protocol", RFC 1028,
Proteon, University of Tennessee at Knoxville,
Cornell University, and Rensselaer Polytechnic
Institute, November 1987.
[5] デーヴィン、J.とJ.ケース、M.ヒョードルとM.Schoffstall、「簡単なゲートウェイモニターしているプロトコル」RFC1028、Proteon、ノクスビルのテネシー大学、コーネル大学、およびレンセラー工科大学(1987年11月)。
[6] Information processing systems - Open Systems
Interconnection, "Specification of Abstract Syntax
Notation One (ASN.1)", International Organization for
Standardization, International Standard 8824,
December 1987.
[6]情報処理システム--オープン・システム・インターコネクション、「抽象構文記法1(ASN.1)の仕様」、国際標準化機構、国際規格8824(1987年12月)。
[7] Information processing systems - Open Systems
Interconnection, "Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1)", International
Organization for Standardization, International Standard
8825, December 1987.
[7]情報処理システム--オープン・システム・インターコネクション、「基本的なコード化の仕様は抽象的な記法1(ASN.1)のために統治されます」、国際標準化機構、国際規格8825、1987年12月。
[8] Postel, J., "User Datagram Protocol", RFC 768,
USC/Information Sciences Institute, November 1980.
[8] ポステル、J.、「ユーザー・データグラム・プロトコル」、RFC768、科学が1980年11月に設けるUSC/情報。
[9] Warrier, U., and L. Besaw, "The Common Management Information
Services and Protocol over TCP/IP", RFC 1095, Unisys Corporation
and Hewlett-Packard, April 1989.
ユニシスの[9]Warrier、U.、L.Besaw、「TCP/IPの上の共通管理情報サービスとプロトコル」、RFC1095、社、およびヒューレット・パッカード(1989年4月)。
Case, Fedor, Schoffstall, & Davin [Page 33] RFC 1098 SNMP April 1989
ケース、ヒョードル、Schoffstall、およびデーヴィン[33ページ]RFC1098SNMP1989年4月
Authors' Addresses
作者のアドレス
Jeffrey D. Case
University of Tennessee Computing Center
Associate Driector
200 Stokely Management Center
Knoxville, TN 37996-0520
テネシー計算機センタ仲間Driector200Stokely管理センターノクスビル、テネシー37996-0520のジェフリーD.ケース大学
Phone: (615) 974-6721
以下に電話をしてください。 (615) 974-6721
Email: case@UTKUX1.UTK.EDU
メール: case@UTKUX1.UTK.EDU
Mark Fedor
Nysernet, Inc.
Rensselaer Technology Park
125 Jordan Road
Troy, NY 12180
マークヒョードルNysernet Inc.レンセラー技術公園125ジョーダンRoadトロイ(ニューヨーク)12180
Phone: (518) 283-8860
以下に電話をしてください。 (518) 283-8860
Email: fedor@patton.NYSER.NET
メール: fedor@patton.NYSER.NET
Martin Lee Schoffstall
NYSERNET Inc.
Rensselaer Technology Park
165 Jordan Road
Troy, NY 12180
マーチンリーSchoffstall NYSERNET株式会社レンセラー技術公園165ジョーダンRoadトロイ(ニューヨーク)12180
Phone: (518) 283-8860
以下に電話をしてください。 (518) 283-8860
Email: schoff@NISC.NYSER.NET
メール: schoff@NISC.NYSER.NET
Chuck Davin
MIT Laboratory for Computer Science, NE43-507
545 Technology Square
Cambridge, MA 02139
チャックデーヴィンMIT Laboratory for Computer Science、NE43-507 545の技術の正方形のケンブリッジ、MA 02139
Phone: (617) 253-6020
以下に電話をしてください。 (617) 253-6020
EMail: jrd@ptt.lcs.mit.edu
メール: jrd@ptt.lcs.mit.edu
Case, Fedor, Schoffstall, & Davin [Page 34]
ケース、ヒョードル、Schoffstall、およびデーヴィン[34ページ]
一覧
スポンサーリンク
