この文書はRFC1215の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group M. Rose, Editor
Request for Comments: 1215 Performance Systems International
March 1991
A Convention for Defining Traps
for use with the SNMP
ＳＮＭＰで使用するトラップを
定義することに対する取り決め
Status of this 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.
このメモはＳＮＭＰで使うトラップを定義する簡単な方法を示唆します。読
者はインターネット標準ネットワーク管理フレームワークでのトラップの使
用が議論中であることを知るべきです。それで、このメモは情報目的で提出
されています。トラップを使用するネットワーク管理関係者がこの文書を利
用するよう奨励されます。トラップを使用しない関係者が安全にこの文書を
無視することができます。
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
2.1 トラップ種別マクロのマッピング
2.1.1 Mapping of the ENTERPRISE clause
2.1.1 企業項のマッピング
2.1.2 Mapping of the VARIABLES clause
2.1.2 変数項のマッピング
2.1.3 Mapping of the DESCRIPTION clause
2.1.3 記述項のマッピング
2.1.4 Mapping of the REFERENCE clause
2.1.4 参照項のマッピング
2.1.5 Mapping of the TRAP-TYPE value
2.1.5 トラップ種別値のマッピング
2.2 Usage Examples
2.2 使用例
2.2.1 Enterprise-specific Trap
2.2.1 企業特定のトラップ
2.2.2 Generic-Traps for use with the SNMP
2.2.2 ＳＮＭＰと共に使用する一般トラップ
3. Acknowledgements
3. 謝辞
4. References
4. 参考文献
5. Security Considerations
5. セキュリティの考察
6. Author's Address
6. 著者のアドレス
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
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.
ＲＦＣ１０５２、インターネットネットワーク管理標準の開発[1]のＩＡＢ推
薦、で報告されたように、ＴＣＰ／ＩＰベースのインターネットネットワー
ク管理の２つの作戦が着手されました。短期でＲＦＣ１０６７で定義された
単純ネットワーク管理プロトコル（ＳＮＭＰ）がインターネット共同体でノー
ドを管理するために使われるはずでした。長期でＯＳＩネットワーク管理機
構の使用が調べられるはずでした。２つの文書は管理情報を定義するために
作られました：管理情報の構造（ＳＭＩ）を定義するＲＦＣ１０６５と、管
理情報ベース（ＭＩＢ）を定義するＲＦＣ１０６６です。これらの文書の両
方がＳＮＭＰとＯＳＩネットワーク管理フレームワークの両方と互換性があ
るように設計されました。
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.
ＲＦＣ１１０９、２番目のアドホックネットワーク管理レビューグループ報
告[2]で報告されるように、ＳＮＭＰとＯＳＩネットワーク管理フレームワー
クのの必要条件は予想より異なっていました。そして、ＳＭＩ／ＭＩＢ間の
互換性と両方のフレームワークの必要条件が示されました。この行動は、Ｓ
ＮＭＰに基づく運用ネットワーク管理フレームワークに、インターネット共
同体でＭＩＢ−ＩＩを生成する新しい運用ニーズを許します。
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.
１９９０年５月に、核となる文書は「推薦」状態の「標準プロトコル」に移
行しました。それで、インターネット標準ネットワーク管理フレームワーク
が以下から成り立ちます：ＲＦＣ１１５５、ＴＣＰ／ＩＰベースのインター
ネットのための管理情報の構造と識別子[3]、これは管理オブジェクトがどう
やってＭＩＢ内に含まれるかを定義します；ＲＦＣ１１５６、ＴＣＰ／ＩＰ
ベースのネットワーク管理のための管理情報ベース[4]、これは、ＭＩＢ内の
管理情報を記述します；ＲＦＣ１１５７、単純ネットワーク管理プロトコル
[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.
最初の必要条件がプロトコルに依存しない事であるために、インターネット
標準ＳＭＩはトラップを定義するために手段を供給しません。その代わりに、
ＳＮＭＰは少数の標準化されたトラップを定義し、管理企業が企業固有のト
ラップを伝達する手段を供給します。
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:
しかしながら、ある実験固有のトラップを定義する必要のある実験的ＭＩＢ
の導入で、トラップを定義する都合が良い手段が望ましいです。トラップ種
別マクロはこの目的で勧められます：
IMPORTS
ObjectName
FROM RFC1155-SMI;
TRAP-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= "ENTERPRISE" value
(enterprise OBJECT IDENTIFIER)
VarPart
DescrPart
ReferPart
VALUE NOTATION ::= value (VALUE INTEGER)
VarPart ::=
"VARIABLES" "{" VarTypes "}"
| empty
VarTypes ::=
VarType | VarTypes "," VarType
VarType ::=
value (vartype ObjectName)
DescrPart ::=
"DESCRIPTION" value (description DisplayString)
| empty
ReferPart ::=
"REFERENCE" value (reference DisplayString)
| empty
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.
トラップの使用がインターネット標準ネットワーク管理フレームワークで強
く反対されていることは、しかしながら、強調されなくてはなりません。ト
ラップ種別マクロは新しいトラップの定義を増やさないために、既存のトラッ
プの簡潔な定義を許すように意図されます。
2.1. Mapping of the TRAP-TYPE macro
2.1. トラップ種別マクロのマッピング
It should be noted that the expansion of the TRAP-TYPE macro is
something which conceptually happens during implementation and not
during run-time.
トラップ種別マクロの拡張が実行時ではなく、実装時に概念的に起きること
を指摘します。
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.
存在しているに違いない、企業項はこのトラップを定義する登録権限を持つ
管理企業を定義します（登録権限の委任の論議はＳＭＩ[3]を参照）。この
値はＳＮＭＰトラップＰＤＵの企業フィールドの中に置かれます。
By convention, if the value of the ENTERPRISE clause is
慣習によって、もし企業項の値がＭＩＢ−ＩＩ[7]で定義されるように、
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.
であるなら、この値を使う代わりに、sysObjectIDの値がＳＮＭＰトラップ
ＰＤＵの企業フィールドに置かれます。これは既存の標準ＳＮＭＰトラップ
を表すトラップ種別マクロを使う単純な手段を供給します；これは追加の標
準ＳＮＭＰトラップを定義する手段を供給することを意図しません。
2.1.2. Mapping of the VARIABLES clause
2.1.2. 変数項のマッピング
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.
ないかもしれない変数項は、トラップ種別のすべて実体の中に含むＭＩＢオ
ブジェクトの順序列を定義します。それぞれの変数がＳＮＭＰトラップＰＤ
Ｕの変数結合フィールドに、順番に、置かれます。エージェントのオプショ
ンで、追加変数が変数結合フィールドの後に続くかもしれないことに注意し
てください。
However, if the value of the ENTERPRISE clause is
しかしながら、もし企業項値がＭＩＢ−ＩＩ[7]で定義されるように
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.
であるなら、追加の変数の導入はＳＮＭＰメッセージが４８４オクテットよ
り大きくなる結果になってはなりません。
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.
存在している必要がない記述条項はわなタイプの原文の定義を含んでいます。
ＡＳＮ．１構文に従うために、この項の全部の値は、値が複数行であるかも
しれないけれども、二重引用符で括って囲われなくてはならないことに注意
してください。
Further, note that if the MIB module does not contain a textual
description of the trap elsewhere then the DESCRIPTION clause must be
present.
さらに、もしＭＩＢモジュールが他のところでトラップのテキスト記述を含
まないなら、記述項が存在しているに違いないことに注意してください。
2.1.4. Mapping of the REFERENCE clause
2.1.4. 参照項のマッピング
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.
存在していないかもしれない、参照項は、何か他のＭＩＢモジュールで定義
されたトラップやイベントやアラームテキストの相互参照を含んでいます。
これは、何か他の組織によってＭＩＢが作り出した時に有用です。
2.1.5. Mapping of the TRAP-TYPE value
2.1.5. トラップ種別値のマッピング
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
inside the specific-trap field of the SNMP Trap-PDU, and the
generic-trap field is set to "enterpriseSpecific(6)".
トラップ種別マクロの値は、企業項で示された登録権限によって一意にトラッ
プに割り当てられる（整）数です。この値はＳＮＭＰトラップＰＤＵの特定
フィールドに置かれ、そして一般トラップフィールドは
「enterpriseSpecific(6)」に設定されます。
By convention, if the value of the ENTERPRISE clause is
慣習によって、もし企業項の値が、ＭＩＢ−ＩＩ[7]で定義されるように、
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.
であるなら、トラップ種別マクロの値はＳＮＭＰトラップＰＤＵの一般トラッ
プフィールドの中に置かれ、そして特定トラップフィールドは０が設定され
ます。これは既存の標準ＳＮＭＰトラップを表すためにトラップ種別マクロ
を使う単純な手段を供給します；これは追加の標準ＳＮＭＰトラップを定義
する手段を供給することが意図されません。
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 }
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.
myLinkDownトラップは、送信ＳＮＭＰアプリケーショ
ンエンティティーがエージェント設定で表される通
信リンクの１つの故障を認識したことを示します。"
::= 2
2.2.2. Generic-Traps for use with the SNMP
2.2.2. ＳＮＭＰと共に使用する一般トラップ
Consider how the standard SNMP traps might be defined:
どのように標準ＳＮＭＰトラップが定義されるか考えてください：
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.
coldStartトラップは、エージェント設定あるいは
プロトコルエンティティー実装が変わったなどで、
送信プロトコルエンティティーが自身を最初期化し
ていることを示します。"
::= 0
warmStart TRAP-TYPE
ENTERPRISE snmp
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.
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.
linkDownトラップは、 送信プロトコルエンティ
ティーがエージェント設定で表されてコミュニケー
ションリンクの１つの故障を認識することを示しま
す。"
::= 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.
inkUpトラップは、送信プロトコルエンティティー
ががエージェント設定で表されるコミュニケーショ
ンリンクの１つが起動したことを認識することを示
します。"
::= 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.
authenticationFailureトラップは、送信プロトコ
ルエンティティーが正確に認証されないプロトコル
メッセージの受取人であることを示します。ＳＮＭ
Ｐ実装がこのトラップを生成できなくてはならない
が、同時に実装固有のメカニズムでこのようなト
ラップの送出を抑制できなくてはなりません。"
::= 4
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.
egpNeighborLossトラップは、送信プロトコルエン
ティティーのＥＧＰピアであるＥＧＰ隣人が停止し、
ピア関係が行われていないことを示します。"
::= 5
3. Acknowledgements
3. 謝辞
This document was produced by the SNMP Working Group:
この文書はＳＮＭＰ作業班によって作り出されました：
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
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
4. References
4. 参考文献
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
Group", RFC 1109, NRI, August 1989.
[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.
[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.
[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.
[6] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization International
Standard 8824, December 1987.
[7] Rose M., Editor, "Management Information Base for Network
Management of TCP/IP-based internets: MIB-II", RFC 1213,
Performance Systems International, March 1991.
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
Phone: +1 408 562 6222
EMail: mrose@psi.com
X.500: rose, psi, us