RFC1215 日本語訳
1215 Convention for defining traps for use with the SNMP. M.T. Rose. March 1991. (Format: TXT=19336 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose, Editor Request for Comments: 1215 Performance Systems International March 1991
ワーキンググループのM.ローズ、コメントを求めるエディタ要求をネットワークでつないでください: 1991年3月の国際の1215個の言語運用機構
A Convention for Defining Traps for use with the SNMP
SNMPとの使用のためのDefining TrapsのためのConvention
Status of this Memo
このMemoの状態
This memo suggests a straight-forward approach towards defining traps used with the SNMP. Readers should note that the use of traps in the Internet-standard network management framework is controversial. As such, this memo is being put forward for information purposes. Network management practitioners who employ traps are encouraged to make use of this document. Practitioners who do not employ traps can safely ignore this document.
このメモはSNMPと共に使用される罠を定義することに向かった簡単なアプローチを示します。 読者は、インターネット標準ネットワークマネージメントフレームワークにおける罠の使用が論議を呼ぶことに注意するべきです。 そういうものとして、このメモは情報目的のために提唱されています。 罠を使うネットワークマネージメント開業医がこのドキュメントを利用するよう奨励されます。 罠を使わない開業医は安全にこのドキュメントを無視できます。
This memo provides information for the Internet community. It does not specify any standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな規格も指定しません。 このメモの分配は無制限です。
Table of Contents
目次
1. Historical Perspective ................................ 1 2. Defining Traps ........................................ 2 2.1 Mapping of the TRAP-TYPE macro ....................... 3 2.1.1 Mapping of the ENTERPRISE clause ................... 3 2.1.2 Mapping of the VARIABLES clause .................... 4 2.1.3 Mapping of the DESCRIPTION clause .................. 4 2.1.4 Mapping of the REFERENCE clause .................... 4 2.1.5 Mapping of the TRAP-TYPE value ..................... 4 2.2 Usage Examples ....................................... 5 2.2.1 Enterprise-specific Trap ........................... 5 2.2.2 Generic-Traps for use with the SNMP ................ 5 3. Acknowledgements ...................................... 7 4. References ............................................ 9 5. Security Considerations................................ 9 6. Author's Address....................................... 9
1. 歴史的な見解… 1 2. 定義は捕らえられます… 2 TRAP-TYPEマクロに関する2.1マッピング… 3 2.1 エンタープライズ節に関する.1マッピング… 3 2.1 VARIABLES節に関する.2マッピング… 4 2.1 記述節に関する.3マッピング… 4 2.1 REFERENCE節に関する.4マッピング… 4 2.1 TRAP-TYPE価値に関する.5マッピング… 4 2.2 用法の例… 5 2.2 .1のエンタープライズ特有の罠… 5 2.2 .2 SNMPとの使用のためのジェネリック罠… 5 3. 承認… 7 4. 参照… 9 5. セキュリティ問題… 9 6. 作者のアドレス… 9
1. Historical Perspective
1. 歴史観
As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP), defined in RFC 1067, was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was be examined. Two documents were produced to define the management
RFC1052、インターネットNetwork Management Standards[1]のDevelopmentのためのIAB Recommendationsで報告されるように、TCP/IPベースのインターネットのネットワークマネージメントのための2歯の戦略は引き受けられました。 短期的では、RFC1067で定義されたSimple Network Managementプロトコル(SNMP)はインターネットコミュニティでノードを管理するのに使用されることでした。 長期では、OSIネットワークマネージメントフレームワークの使用はそうでした。調べられます。 2通のドキュメントが、管理を定義するために製作されました。
SNMP Working Group [Page 1] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[1ページ]RFC1215コンベンション
information: RFC 1065, which defined the Structure of Management Information (SMI), and RFC 1066, which defined the Management Information Base (MIB). Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework.
情報: (RFCはManagement情報(SMI)のStructureを定義しました)。RFC1065とRFC1066。(RFCはManagement Information基地(MIB)を定義しました)。 これらのドキュメントの両方が、SNMPとOSIネットワークマネージメントフレームワークの両方と互換性があるように設計されました。
This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion.
この戦略は短期的にかなり成功していました: インターネットを利用するネットワークマネージメント技術は数カ月以内に研究と商業共同体の両方によってさばかれました。 これの結果、インターネットコミュニティの部分はタイムリーなファッションで処理しやすいネットワークになりました。
As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [2], the requirements of the SNMP and the OSI network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, based on the SNMP, to respond to new operational needs in the Internet community by producing MIB-II.
RFC1109で報告されるように、Second Ad Hoc Network Management Review Group[2]のReport、SNMPの要件、およびOSIネットワークマネージメントフレームワークは予期されるより異なっていました。 そういうものとして、SMI/MIBとフレームワークの両方との互換性のための要件は中断しました。 この動作は、SNMPに基づく操作上のネットワークマネージメントフレームワークがMIB-IIを生産することによってインターネットコミュニティの新たな操作上の必要性に応じることを許可しました。
In May of 1990, the core documents were elevated to "Standard Protocols" with "Recommended" status. As such, the Internet-standard network management framework consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [3], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets, which describes the managed objects contained in the MIB, RFC 1156 [4]; and, the Simple Network Management Protocol, RFC 1157 [5], which defines the protocol used to manage these objects.
1990年5月に、コアドキュメントは「お勧め」の状態で「標準プロトコル」に登用されました。 そういうものとして、インターネット標準ネットワークマネージメントフレームワークは以下から成ります。 TCP/IPベースのインターネットのためのManagement情報、RFC1155[3]の構造とIdentification([3]はMIBに含まれた管理オブジェクトがどう定義されるかを説明します)。 TCP/IPベースのインターネットのNetwork Managementのための管理Information基地(Network ManagementはMIB、RFC1156[4]に含まれた管理オブジェクトについて説明します)。 そして、以前はよくSimple Network Managementプロトコル、プロトコルを定義するRFC1157[5]をこれらのオブジェクトを管理していました。
2. Defining Traps
2. 罠を定義します。
Due to its initial requirement to be protocol-independent, the Internet-standard SMI does not provide a means for defining traps. Instead, the SNMP defines a few standardized traps and provides a means for management enterprises to transmit enterprise-specific traps.
プロトコルから独立しているという初期の要件のため、インターネット標準SMIは罠を定義するための手段を提供しません。 代わりに、SNMPはいくつかの標準化された罠を定義して、管理企業が企業特有の罠を伝える手段を提供します。
However, with the introduction of experimental MIBs, some of which have a need to define experiment-specific traps, a convenient means of defining traps is desirable. The TRAP-TYPE macro is suggested for this purpose:
しかしながら、実験的なMIBsの導入に、罠を定義する便利な手段は望ましいです。その或るものは実験特有の罠を定義する必要性を持っています。 TRAP-TYPEマクロはこのために示されます:
IMPORTS ObjectName FROM RFC1155-SMI;
RFC1155-SMIからObjectNameをインポートします。
SNMP Working Group [Page 2] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[2ページ]RFC1215コンベンション
TRAP-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "ENTERPRISE" value (enterprise OBJECT IDENTIFIER) VarPart DescrPart ReferPart VALUE NOTATION ::= value (VALUE INTEGER)
罠タイプマクロ:、:= タイプ記法を始めてください:、:= 「エンタープライズ」価値(企業OBJECT IDENTIFIER)のVarPart DescrPart ReferPart VALUE NOTATION:、:= 値(値の整数)
VarPart ::= "VARIABLES" "{" VarTypes "}" | empty VarTypes ::= VarType | VarTypes "," VarType VarType ::= value (vartype ObjectName)
VarPart:、:= 「変数」、「「VarTypes」、」| VarTypesを空にしてください:、:= VarType| 」 「VarTypes」、VarType VarType:、:= 値(vartype ObjectName)
DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty
DescrPart:、:= 「記述」値(記述DisplayString)| 空になってください。
ReferPart ::= "REFERENCE" value (reference DisplayString) | empty
ReferPart:、:= "REFERENCE"値(参照DisplayString)| 空になってください。
END
終わり
It must be emphasized however, that the use of traps is STRONGLY discouraged in the Internet-standard Network Management Framework. The TRAP-TYPE macro is intended to allow concise definitions of existing traps, not to spur the definition of new traps.
しかしながら、それを強調しなければならなくて、罠の使用がSTRONGLYであることはインターネット標準でNetwork Management Frameworkをがっかりさせました。 TRAP-TYPEマクロが新しい罠の定義に拍車をかけるのではなく、既存の罠の簡潔な定義を許すことを意図します。
2.1. Mapping of the TRAP-TYPE macro
2.1. TRAP-TYPEマクロに関するマッピング
It should be noted that the expansion of the TRAP-TYPE macro is something which conceptually happens during implementation and not during run-time.
TRAP-TYPEマクロの拡張がランタイムの間、起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
2.1.1. Mapping of the ENTERPRISE clause
2.1.1. エンタープライズ節に関するマッピング
The ENTERPRISE clause, which must be present, defines the management enterprise under whose registration authority this trap is defined (for a discussion on delegation of registration authority, see the SMI [3]). This value is placed inside the enterprise field of the SNMP Trap-PDU.
エンタープライズ節(存在していなければならない)はこの罠が登録局の下で定義される管理企業を定義します。(登録局の委譲についての議論に関しては、SMI[3])を見てください。 この値はSNMP Trap-PDUの企業分野の中に置かれます。
By convention, if the value of the ENTERPRISE clause is
コンベンションで、節はエンタープライズの値であるならそうです。
SNMP Working Group [Page 3] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[3ページ]RFC1215コンベンション
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
snmp OBJECT IDENTIFIER:、:= mib-2 11
as defined in MIB-II [7], then instead of using this value, the value of sysObjectID is placed in the enterprise field of the SNMP Trap- PDU. This provides a simple means of using the TRAP-TYPE macro to represent the existing standard SNMP traps; it is not intended to provide a means to define additional standard SNMP traps.
そしてMIB-II[7]で定義されることこの値を使用することの代わりに、sysObjectIDの値はSNMP Trap- PDUの企業分野に置かれます。 これは既存の標準のSNMP罠を表すTRAP-TYPEマクロを使用する簡潔な方法を提供します。 それが追加標準のSNMP罠を定義する手段を提供することを意図しません。
2.1.2. Mapping of the VARIABLES clause
2.1.2. VARIABLES節に関するマッピング
The VARIABLES clause, which need not be present, defines the ordered sequence of MIB objects which are contained within every instance of the trap type. Each variable is placed, in order, inside the variable-bindings field of the SNMP Trap-PDU. Note that at the option of the agent, additional variables may follow in the variable-bindings field.
VARIABLES節(存在している必要はない)は罠タイプのあらゆるインスタンスの中に含まれているMIBオブジェクトの規則正しい系列を定義します。 各変数はSNMP Trap-PDUの変項束縛分野の中にオーダーに置かれます。 エージェントの選択のときに追加変数が変項束縛分野で従うかもしれないことに注意してください。
However, if the value of the ENTERPRISE clause is
しかしながら、エンタープライズの値であるなら、節はそうです。
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
snmp OBJECT IDENTIFIER:、:= mib-2 11
as defined in MIB-II [7], then the introduction of additional variables must not result in the serialized SNMP Message being larger than 484 octets.
そして、MIB-II[7]で定義されるように、追加変数の導入は484の八重奏より大きい連載されたSNMP Messageをもたらしてはいけません。
2.1.3. Mapping of the DESCRIPTION clause
2.1.3. 記述節に関するマッピング
The DESCRIPTION clause, which need not be present, contains a textual definition of the trap type. Note that in order to conform to the ASN.1 syntax, the entire value of this clause must be enclosed in double quotation marks, although the value may be multi-line.
記述節(存在している必要はない)は罠タイプの原文の定義を含んでいます。 ASN.1構文に従うためにダブル・クォーテーション・マークにこの節の全体の値を同封しなければならないことに注意してください、値はマルチ系列であるかもしれないのにもかかわらず。
Further, note that if the MIB module does not contain a textual description of the trap elsewhere then the DESCRIPTION clause must be present.
さらに、MIBモジュールがほかの場所に罠の原文の記述を含んでいないなら記述節が存在していなければならないことに注意してください。
2.1.4. Mapping of the REFERENCE clause
2.1.4. REFERENCE節に関するマッピング
The REFERENCE clause, which need not be present, contains a textual cross-reference to a trap, event, or alarm, defined in some other MIB module. This is useful when de-osifying a MIB produced by some other organization.
REFERENCE節(存在している必要はない)はある他のMIBモジュールで定義された罠、イベント、またはアラームに原文の相互参照を含んでいます。 反-ある他の組織によって生産されたMIBをosifyingするとき、これは役に立ちます。
2.1.5. Mapping of the TRAP-TYPE value
2.1.5. TRAP-TYPE価値に関するマッピング
The value of an invocation of the TRAP-TYPE macro is the (integer) number which is uniquely assigned to the trap by the registration authority indicated by the ENTERPRISE clause. This value is placed
TRAP-TYPEマクロの実施の値はエンタープライズ節によって示された登録局によって唯一罠に割り当てられる(整数)番号です。 この値は置かれます。
SNMP Working Group [Page 4] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[4ページ]RFC1215コンベンション
inside the specific-trap field of the SNMP Trap-PDU, and the generic-trap field is set to "enterpriseSpecific(6)".
SNMP Trap-PDUの特定の罠分野、およびジェネリック罠分野の中に、"enterpriseSpecific(6)"へのセットがあります。
By convention, if the value of the ENTERPRISE clause is
コンベンションで、節はエンタープライズの値であるならそうです。
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
snmp OBJECT IDENTIFIER:、:= mib-2 11
as defined in MIB-II [7], then the value of an invocation of the TRAP-TYPE macro is placed inside the generic-trap field of the SNMP Trap-PDU, and the specific-trap field is set to 0. This provides a simple means of using the TRAP-TYPE macro to represent the existing standard SNMP traps; it is not intended to provide a means to define additional standard SNMP traps.
MIB-II[7]で定義されるように、次に、TRAP-TYPEマクロの実施の値はSNMP Trap-PDUのジェネリック罠分野の中に置かれます、そして、特定の罠分野は0に位置します。 これは既存の標準のSNMP罠を表すTRAP-TYPEマクロを使用する簡潔な方法を提供します。 それが追加標準のSNMP罠を定義する手段を提供することを意図しません。
2.2. Usage Examples
2.2. 使用例
2.2.1. Enterprise-specific Trap
2.2.1. エンタープライズ特有の罠
Consider a simple example of an enterprise-specific trap that is sent when a communication link failure is encountered:
通信リンク失敗が遭遇するとき送られる企業特有の罠の簡単な例を考えてください:
myEnterprise OBJECT IDENTIFIER ::= { enterprises 9999 }
myEnterpriseする、オブジェクト識別子:、:= 企業9999
myLinkDown TRAP-TYPE ENTERPRISE myEnterprise VARIABLES { ifIndex } DESCRIPTION "A myLinkDown trap signifies that the sending SNMP application entity recognizes a failure in one of the communications links represented in the agent's configuration." ::= 2
myLinkDown TRAP-TYPEエンタープライズmyEnterprise VARIABLES ifIndex、記述、「myLinkDown罠は、送付SNMPアプリケーション実体が、コミュニケーションリンクの1つでの失敗が中にエージェントの構成を表したと認めるのを意味します」。 ::= 2
2.2.2. Generic-Traps for use with the SNMP
2.2.2. SNMPとの使用のためのジェネリック罠
Consider how the standard SNMP traps might be defined:
標準のSNMP罠がどのように定義されるかもしれないか考えてください:
coldStart TRAP-TYPE ENTERPRISE snmp DESCRIPTION "A coldStart trap signifies that the sending protocol entity is reinitializing itself such that the agent's configuration or the rotocol entity implementation may be altered." ::= 0
coldStart TRAP-TYPEエンタープライズは記述をsnmpします。「coldStart罠は、送付プロトコル実体がエージェントの構成かrotocol実体実装を変更できるための再初期化自体であることを意味します」。 ::= 0
warmStart TRAP-TYPE ENTERPRISE snmp
warmStart TRAP-TYPEエンタープライズsnmp
SNMP Working Group [Page 5] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[5ページ]RFC1215コンベンション
DESCRIPTION "A warmStart trap signifies that the sending protocol entity is reinitializing itself such that neither the agent configuration nor the protocol entity implementation is altered." ::= 1
記述、「warmStart罠が、送付プロトコル実体が再初期化自体であることを意味するので、エージェント構成もプロトコル実体実装も変更されません」。 ::= 1
linkDown TRAP-TYPE ENTERPRISE snmp VARIABLES { ifIndex } DESCRIPTION "A linkDown trap signifies that the sending protocol entity recognizes a failure in one of the communication links represented in the agent's configuration." ::= 2
linkDown TRAP-TYPEエンタープライズsnmp VARIABLES ifIndex、記述、「linkDown罠は、送付プロトコル実体が、通信リンクの1つにおける失敗が中にエージェントの構成を表したと認めるのを意味します」。 ::= 2
linkUp TRAP-TYPE ENTERPRISE snmp VARIABLES { ifIndex } DESCRIPTION "A linkUp trap signifies that the sending protocol entity recognizes that one of the communication links represented in the agent's configuration has come up." ::= 3
linkUp TRAP-TYPEエンタープライズsnmp VARIABLES ifIndex、記述、「linkUp罠は、送付プロトコル実体が、エージェントの構成で表される通信リンクの1つが上に来たと認めるのを意味します。」 ::= 3
authenticationFailure TRAP-TYPE ENTERPRISE snmp DESCRIPTION "An authenticationFailure 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." ::= 4
authenticationFailure TRAP-TYPEエンタープライズは記述をsnmpします。「authenticationFailure罠は、送付プロトコル実体が適切に認証されないプロトコルメッセージの受け取り人であることを意味します」。 「また、SNMPの実装がこの罠を生成することができなければならない間、実装の特定のメカニズムでそのような罠の放出を抑圧できなければなりません。」 ::= 4
SNMP Working Group [Page 6] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[6ページ]RFC1215コンベンション
egpNeighborLoss TRAP-TYPE ENTERPRISE snmp VARIABLES { egpNeighAddr } DESCRIPTION "An egpNeighborLoss trap signifies that an EGP neighbor for whom the sending protocol entity was an EGP peer has been marked down and the peer relationship no longer obtains." ::= 5
egpNeighborLoss TRAP-TYPEエンタープライズsnmp VARIABLES egpNeighAddr、記述、「egpNeighborLoss罠が、送付プロトコル実体がEGP同輩であったEGP隣人がもう下にと同輩関係であることはマークされていないのを意味する、入手、」 ::= 5
3. Acknowledgements
3. 承認
This document was produced by the SNMP Working Group:
このドキュメントはSNMP作業部会によって製作されました:
Anne Ambler, Spider Karl Auerbach, Sun Fred Baker, ACC Ken Brinkerhoff Ron Broersma, NOSC Jack Brown, US Army Theodore Brunner, Bellcore Jeffrey Buffum, HP John Burress, Wellfleet Jeffrey D. Case, University of Tennessee at Knoxville Chris Chiptasso, Spartacus Paul Ciarfella, DEC Bob Collet John Cook, Chipcom Tracy Cox, Bellcore James R. Davin, MIT-LCS Eric Decker, cisco Kurt Dobbins, Cabletron Nadya El-Afandi, Network Systems Gary Ellis, HP Fred Engle Mike Erlinger Mark S. Fedor, PSI Richard Fox, Synoptics Karen Frisa, CMU Chris Gunner, DEC Fred Harris, University of Tennessee at Knoxville Ken Hibbard, Xylogics Ole Jacobsen, Interop Ken Jones Satish Joshi, Synoptics Frank Kastenholz, Racal-Interlan Shimshon Kaufman, Spartacus Ken Key, University of Tennessee at Knoxville
アン・アンブラー、クモのカール・アウアーバック、Sunのフレッド・ベイカー、ACCケンBrinkerhoffロンBroersma、NOSCジャック・ブラウン、米陸軍のセオドア・ブルンナー、BellcoreジェフリーBuffum、hpジョン・バレス、WellfleetジェフリーD.事件、ノクスビルクリスChiptassoのテネシー大学、スパルタカスポールCiarfella、12月のボブ・Colletション・クック、Chipcomトレーシーはコックスを務めます、BellcoreのジェームスR; デーヴィン、MIT-LCSエリックDecker、コクチマスカート・ドビンズ、Cabletron Nadya El-Afandi、Network Systemsゲーリー・エリス、HPフレッド・エングル・マイク・Erlingerマーク・S.ヒョードル、PSIリチャードフォックス、SynopticsカレンFrisa、米カーネギーメロン大学クリスGunner、12月のフレッド・ハリス、ノクスビルケン・ヒバートのテネシー大学、Xylogics Oleジェイコブセン、Interopケン・ジョーンズ・サティシュ・ジョーシー、SynopticsフランクKastenholz、Racal-Interlan Shimshonコーフマン、スパルタカスケンKey、ノクスビルのテネシー大学
SNMP Working Group [Page 7] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[7ページ]RFC1215コンベンション
Jim Kinder, Fibercom Alex Koifman, BBN Christopher Kolb, PSI Cheryl Krupczak, NCR Paul Langille, DEC Peter Lin, Vitalink John Lunny, TWG Carl Malamud Randy Mayhew, University of Tennessee at Knoxville Keith McCloghrie, Hughes LAN Systems Donna McMaster, David Systems Lynn Monsanto, Sun Dave Perkins, 3COM Jim Reinstedler, Ungerman Bass Anil Rijsinghani, DEC Kathy Rinehart, Arnold AFB Kary Robertson Marshall T. Rose, PSI (chair) L. Michael Sabo, NCSC Jon Saperia, DEC Greg Satz, cisco Martin Schoffstall, PSI John Seligson Steve Sherry, Xyplex Fei Shu, NEC Sam Sjogren, TGV Mark Sleeper, Sparta Lance Sprung Mike St.Johns Bob Stewart, Xyplex Emil Sturniold Kaj Tesink, Bellcore Dean Throop, Data General Bill Townsend, Xylogics Maurice Turcotte, Racal-Milgo Kannan Varadhou Sudhanshu Verma, HP Bill Versteeg, Network Research Corporation Warren Vik, Interactive Systems David Waitzman, BBN Steve Waldbusser, CMU Dan Wintringhan David Wood Wengyik Yeong, PSI Jeff Young, Cray Research
ジム・キンダー、FibercomアレックスKoifman、BBNクリストファー・コールブ、ψシェリルKrupczak、NCRポールLangille、12月のピーター・リンVitalinkジョンLunny、TWGカール・マラマッド・ランディ・メイヒュー、ノクスビルキースMcCloghrieのテネシー大学、ドナ・マクマスター、ヒューズLANシステムデヴィッドシステムリンモンサント、Sunのデーヴ・パーキンス、3COMジムReinstedler、UngermanバスコマツナギRijsinghani、12月のキャシー・ラインハート、アーノルド・AFB Karyロバートソン・マーシャルT.は上昇しました、ψ(いす。)L; マイケルSabo、NCSCジョンSaperia、12月のグレッグSatz、コクチマスマーチンSchoffstall、PSIジョンSeligsonスティーブSherry、Xyplex Feiシュ、NECのサム・シェーグレン、TGVマークSleeper、スパルタランスSprungマイク通り; ジョーンズ・ボブ・スチュワート、XyplexエミールSturnioldカイTesink、BellcoreディーンThroop、データゼネラルのビル・タウンゼンド、XylogicsモーリスTurcotte、Racal-Milgo Kannan Varadhou Sudhanshu Verma(hpビルVersteeg)は研究社のウォレン・ビークをネットワークでつなぎます、インタラクティブシステムデヴィッドWaitzman、BBNスティーブWaldbusser、米カーネギーメロン大学ダンWintringhanデヴィッドWood Wengyik Yeong、ψジェフ・ヤング、クレイリサーチ
SNMP Working Group [Page 8] RFC 1215 Convention for Defining Traps March 1991
1991年3月に罠を定義するためのSNMP作業部会[8ページ]RFC1215コンベンション
4. References
4. 参照
[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988.
[1] サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、NRI、1988年4月。
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989.
[2] サーフ、V.、「第2臨時のネットワークマネージメントレビューグループのレポート」、RFC1109、NRI、1989年8月。
[3] 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.
[3]ローズM.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、RFC1155、国際パフォーマンスSystemsヒューズLAN Systems(1990年5月)
[4] 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.
[4]McCloghrie K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1156、ヒューズLAN Systems、国際パフォーマンスSystems、1990年5月。
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990.
[5] SNMPが研究するケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、「簡単なネットワーク管理プロトコル」、RFC1157、国際言語運用機構、国際言語運用機構(MITコンピュータサイエンス研究所)は1990がそうするかもしれません。
[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] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構国際規格8824(1987年12月)の仕様。
[7] Rose M., Editor, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, Performance Systems International, March 1991.
[7] ローズM.、Editor、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、RFC1213、国際言語運用機構、1991年3月。
5. Security Considerations
5. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
6. Author's Address
6. 作者のアドレス
Marshall T. Rose Performance Systems International 5201 Great America Parkway Suite 3106 Santa Clara, CA 95054
3106サンタクララ、マーシャルT.バラ言語運用機構国際5201グレート・アメリカ公園道路Suiteカリフォルニア 95054
Phone: +1 408 562 6222
以下に電話をしてください。 +1 408 562 6222
EMail: mrose@psi.com X.500: rose, psi, us
メール: mrose@psi.com X.500: バラ、psi、私たち
SNMP Working Group [Page 9]
SNMP作業部会[9ページ]
一覧
スポンサーリンク