この文書はRFC1212の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group M. Rose
Request for Comments: 1212 Performance Systems International
K. McCloghrie
Hughes LAN Systems
Editors
March 1991
Concise MIB Definitions
簡潔なＭＩＢ定義
Status of this Memo
この文書の状態
This memo defines a format for producing MIB modules. This RFC
specifies an IAB standards track document for the Internet community,
and requests discussion and suggestions for improvements. Please
refer to the current edition of the "IAB Official Protocol Standards"
for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
この文書はＭＩＢモジュールを作るためのフォーマットを定義します。この
ＲＦＣはインターネット共同体のためにＩＡＢ標準化文書を指定し、そして
改良のための議論と提案を求めます。このプロトコルの標準化状態と状態は、
「ＩＡＢ公式プロトコル標準」の現在の版を参照してください。このメモの
配布は無制限です。
Table of Contents
目次
1. Abstract
1. 要約
2. Historical Perspective
2. 歴史的見地
3. Columnar Objects
3. コラム状オブジェクト
3.1 Row Deletion
3.1 行削除
3.2 Row Addition
3.2 行追加
4. Defining Objects
4. オブジェクト定義
4.1 Mapping of the OBJECT-TYPE macro
4.1 オブジェクト型マクロのマッピング
4.1.1 Mapping of the SYNTAX clause
4.1.1 構文論条項のマッピング
4.1.2 Mapping of the ACCESS clause
4.1.2 アクセス条項のマッピング
4.1.3 Mapping of the STATUS clause
4.1.3 状態条項のマッピング
4.1.4 Mapping of the DESCRIPTION clause
4.1.4 記述条項のマッピング
4.1.5 Mapping of the REFERENCE clause
4.1.5 参照条項のマッピング
4.1.6 Mapping of the INDEX clause
4.1.6 インデックス条項のマッピング
4.1.7 Mapping of the DEFVAL clause
4.1.7 DEFVAL条項のマッピング
4.1.8 Mapping of the OBJECT-TYPE value
4.1.8 オブジェクト型のマッピング
4.2 Usage Example
4.2 使用例
5. Appendix: DE-osifying MIBs
5. 付録：流用ＭＩＢ
5.1 Managed Object Mapping
5.1 管理オブジェクトのマッピング
5.1.1 Mapping to the SYNTAX clause
5.1.1 構文条項へのマッピング
5.1.2 Mapping to the ACCESS clause
5.1.2 アクセス条項へのマッピング
5.1.3 Mapping to the STATUS clause
5.1.3 状態条項へのマッピング
5.1.4 Mapping to the DESCRIPTION clause
5.1.4 記述条項へのマッピング
5.1.5 Mapping to the REFERENCE clause
5.1.5 参照条項へのマッピング
5.1.6 Mapping to the INDEX clause
5.1.6 インデックス条項へのマッピング
5.1.7 Mapping to the DEFVAL clause
5.1.7 DEFVAL条項へのマッピング
5.2 Action Mapping
5.2 行動へのマッピング
5.2.1 Mapping to the SYNTAX clause
5.2.1 構文条項へのマッピング
5.2.2 Mapping to the ACCESS clause
5.2.2 アクセス条項へのマッピング
5.2.3 Mapping to the STATUS clause
5.2.3 状態条項へのマッピング
5.2.4 Mapping to the DESCRIPTION clause
5.2.4 記述条項へのマッピング
5.2.5 Mapping to the REFERENCE clause
5.2.5 参照条項へのマッピング
6. Acknowledgements
6. 謝辞
7. References
7. 参考文献
8. Security Considerations
8. セキュリティの考察
9. Authors' Addresses
9. 著者のアドレス
1. Abstract
1. 要約
This memo describes a straight-forward approach toward producing
concise, yet descriptive, MIB modules. It is intended that all
future MIB modules be written in this format.
このメモは簡潔で記述的なＭＩＢモジュールを作り出すに簡単な方法を記述
します。すべての将来のＭＩＢモジュールがこのフォーマットで書かれるこ
とを意図します。
2. Historical Perspective
2. 歴史的見地
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
to 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. Consistent with the IAB directive to produce
simple, workable systems in the short-term, the list of managed
objects defined in the Internet-standard MIB was derived by taking
only those elements which are considered essential. However, the SMI
defined three extensibility mechanisms: one, the addition of new
standard objects through the definitions of new versions of the MIB;
two, the addition of widely-available but non-standard objects
through the experimental subtree; and three, the addition of private
objects through the enterprises subtree. Such additional objects can
not only be used for vendor-specific elements, but also for
experimentation as required to further the knowledge of which other
objects are essential.
１９９０年５月に、核となる文書は「推薦」状態の「標準プロトコル」に移
行しました。それで、インターネット標準ネットワーク管理フレームワーク
が以下から成り立ちます：ＲＦＣ１１５５、ＴＣＰ／ＩＰベースのインター
ネットのための管理情報の構造と識別子[3]、これは管理オブジェクトがどう
やってＭＩＢ内に含まれるかを定義します；ＲＦＣ１１５６、ＴＣＰ／ＩＰ
ベースのネットワーク管理のための管理情報ベース[4]、これは、ＭＩＢ内の
管理情報を記述します；ＲＦＣ１１５７、単純ネットワーク管理プロトコル
[5]、これはこれらのオブジェクトを管理するために使うプロトコルを定義し
ます。短期で質素で実行可能なシステムを作り出すためのＩＡＢ指令に従い、
インターネット標準ＭＩＢの管理されたオブジェクトのリストは、不可欠な
要素だけを定義しました。しかしながら、ＳＭＩは３つの拡張性メカニズム
を定義しました：第一に、ＭＩＢの新しいバージョンの定義で新しい標準オ
ブジェクトの追加を想定します；第二に、実験部分木を通しての広く使える
が非標準のオブジェクトを追加しました；第三に、企業部分木を通しての私
的オブジェクトの追加です。このような追加のオブジェクトはベンダー固有
の要素でだけ使うのではなく、他のオブジェクトが必要な知識で将来必要な
要求として実験のために使うことができます。
As more objects are defined using the second method, experience has
shown that the resulting MIB descriptions contain redundant
information. In order to provide for MIB descriptions which are more
concise, and yet as informative, an enhancement is suggested. This
enhancement allows the author of a MIB to remove the redundant
information, while retaining the important descriptive text.
第二の方法で、より多くのオブジェクトが定義される時、経験からＭＩＢ記
述が冗長な情報を含むことが示されています。より簡潔で、同じ情報がある
ＭＩＢ記述に備えるために、拡張が示唆されます。この拡張はＭＩＢの著者
が、重要な記述テキストを維持したまま、冗長情報を取り去ることを許しま
す。
Before presenting the approach, a brief presentation of columnar
object handling by the SNMP is necessary. This explains and further
motivates the value of the enhancement.
方法を示す前に、ＳＮＭＰのコラム状のオブジェクト取り扱いの短い説明が
必要です。これは拡張の価値を説明し、興味を起こさせます。
3. Columnar Objects
3. コラム状オブジェクト
The SNMP supports operations on MIB objects whose syntax is
ObjectSyntax as defined in the SMI. Informally stated, SNMP
operations apply exclusively to scalar objects. However, it is
convenient for developers of management applications to impose
imaginary, tabular structures on the ordered collection of objects
that constitute the MIB. Each such conceptual table contains zero or
more rows, and each row may contain one or more scalar objects,
termed columnar objects. Historically, this conceptualization has
been formalized by using the OBJECT-TYPE macro to define both an
object which corresponds to a table and an object which corresponds
to a row in that table. (The ACCESS clause for such objects is
"not-accessible", of course.) However, it must be emphasized that, at
the protocol level, relationships among columnar objects in the same
row is a matter of convention, not of protocol.
ＳＮＭＰは、構文がＳＭＩで定義されるObjectSyntaxであるＭＩＢオブジェ
クトの、オペレーションをサポートします。非公式に言うと、ＳＮＭＰオペ
レーションが排他的にスカラーオブジェクトに対応します。しかしながら、
管理アプリケーションの開発者にとって、ＭＩＢを形成する順序オブジェク
トの集合を概念的に表構造にするのは都合が良いです。このような概念表は
いくつかの行があるかも知れず、各行にコラム状オブジェクトと呼ぶいくつ
かのスカラーオブジェクトがあるかもしれません。歴史的に、この概念表に
対応するオブジェクトと、その表の行に対応するオブジェクトの両方を定義
する、オブジェクト型マクロを使うことによって、形式化されました。（こ
のようなオブジェクトのためのアクセス条項は、もちろん、「アクセス不可」
です。）しかしながら、プロトコルレベルで、同じ行のコラム状オブジェ
クト間の関係は、習慣であってプロトコルではないことを強調します。
Note that there are good reasons why the tabular structure is not a
matter of protocol. Consider the operation of the SNMP Get-Next-PDU
acting on the last columnar object of an instance of a conceptual
row; it returns the next column of the first conceptual row or the
first object instance occurring after the table. In contrast, if the
rows were a matter of protocol, then it would instead return an
error. By not returning an error, a single PDU exchange informs the
manager that not only has the end of the conceptual row/table been
reached, but also provides information on the next object instance,
thereby increasing the information density of the PDU exchange.
表構造がプロトコル問題ではないことの良い理由があることに注意してくだ
さい。概念行の実体の最後のコラム状オブジェクトに対する、ＳＮＭＰの次
のＰＤＵ読込みオペレーションを考えます；これは最初の概念行の次の項目
化、表の後の最初のオブジェクトの実体を返します。それと対照的に、もし
行がプロトコルの問題なら、代わりにエラーを返すでしょう。エラーを返さ
ないことで、単純ＰＤＵ交換でマネージャーに概念行／表の終わりを知らせ
るだけでなく、次のオブジェクトの実体の情報を供給し、それでＰＤＵ交換
の情報密度を増やしてます。
3.1. Row Deletion
3.1. 行削除
Nonetheless, it is highly useful to provide a means whereby a
conceptual row may be removed from a table. In MIB-II, this was
achieved by defining, for each conceptual row, an integer-valued
columnar object. If a management station sets the value of this
object to some value, usually termed "invalid", then the effect is
one of invalidating the corresponding row in the table. However, it
is an implementation-specific matter as to whether an agent removes
an invalidated entry from the table. Accordingly, management
stations must be prepared to receive tabular information from agents
that corresponds to entries not currently in use. Proper
interpretation of such entries requires examination of the columnar
object indicating the in-use status.
にもかかわらず、概念行を表から取り除く手段を供給することは大いに有用
です。ＭＩＢ−ＩＩで、これはそれぞれの概念行に整数値コラム状オブジェ
クトを定義することで成し遂げられました。もし管理装置がこのオブジェク
トの値をある、一般的に「無効」と呼ばる、値に設定するなら、効果は表の
対応する行を無効にします。しかしながら、エージェントが無効な項目を表
から取り除くかどうかは、実装固有の問題です。したがって、管理装置はエー
ジェントから現在使用中でない項目に対応する表情報を取る用意ができてい
るに違いありません。このような項目の適切な解釈は、コラム状オブジェク
トが使用中かの状態を検査する事を要求します。
3.2. Row Addition
3.2. 行追加
It is also highly useful to have a clear understanding of how a
conceptual row may be added to a table. In the SNMP, at the protocol
level, a management station issues an SNMP set operation containing
an arbitrary set of variable bindings. In the case that an agent
detects that one or more of those variable bindings refers to an
object instance not currently available in that agent, it may,
according to the rules of the SNMP, behave according to any of the
following paradigms:
どのように概念行がテーブルに加えられるかについて、明確な了解を持つこ
とは大いに有用です。ＳＮＭＰで、プロトコルレベルで、管理装置が任意の
変数結合の集合を含むオペレーションを発行します。それらの変数結合のい
くつかが、エージェントで現在利用可能でないオブジェクトの実体を参照す
るのを検出する場合、ＳＮＭＰの規則に拠れば、次の模範のどの動作もある
かもしれません：
(1) It may reject the SNMP set operation as referring to
non-existent object instances by returning a response
with the error-status field set to "noSuchName" and the
error-index field set to refer to the first vacuous
reference.
(1) エラー状態フィールドに"noSuchName"を設定し、エラーインデッ
クスフィールドに最初の空参照を指定し、実在しないオブジェ
クト実体の参照を含むＳＮＭＰ設定オペレーション全体を拒絶
するかもしれません。
(2) It may accept the SNMP set operation as requesting the
creation of new object instances corresponding to each
of the object instances named in the variable bindings.
The value of each (potentially) newly created object
instance is specified by the "value" component of the
relevant variable binding. In this case, if the request
specifies a value for a newly (or previously) created
object that it deems inappropriate by reason of value or
syntax, then it rejects the SNMP set operation by
responding with the error-status field set to badValue
and the error-index field set to refer to the first
offending variable binding.
(2) 変数結合で命名されるオブジェクトのそれぞれに対応する新し
いオブジェクト実体の生成を要求してるとして、ＳＮＭＰ設定
オペレーションを受け入れるかもしれません。それぞれの（潜
在的に）新たに作られたオブジェクトのインスタンスの値は適
切な変数結合の「値」要素で指定されます。この場合、もし要
求が新しく（あるいは以前に）生成したオブジェクトの値に、
値や構文上で不適当なものを指定するなら、エラー状態フィー
ルドにbadValue を設定し、エラーインデックスフィールドに最
初の不適当な変数結合を指定し、ＳＮＭＰ設定オペレーション
全体を拒絶するかもしれません。
(3) It may accept the SNMP set operation and create new
object instances as described in (2) above and, in
addition, at its discretion, create supplemental object
instances to complete a row in a conceptual table of
which the new object instances specified in the request
may be a part.
(3) ＳＮＭＰ設定オペレーションを受け入れ、上の(2)で記述される
ように、新しいオブジェクトのインスタンスを作り、加えて、
その裁量で、新しいオブジェクトのインスタンスが概念表の部
分であることを明示した行を完成するべき補足のオブジェクト
の実体を作るかもしれません。
It should be emphasized that all three of the above behaviors are
fully conformant to the SNMP specification and are fully acceptable,
subject to any restrictions which may be imposed by access control
and/or the definitions of the MIB objects themselves.
すべて上記の３つの行動はＳＮＭＰ仕様に完全準拠で、完全に受容できて、
アクセス制御やＭＩＢオブジェクト自身の定義のによって課されるかもしれ
ない制限の適用を受けることを強調します。
4. Defining Objects
4. オブジェクト定義
The Internet-standard SMI employs a two-level approach towards object
definition. A MIB definition consists of two parts: a textual part,
in which objects are placed into groups, and a MIB module, in which
objects are described solely in terms of the ASN.1 macro OBJECT-TYPE,
which is defined by the SMI.
インターネット標準ＳＭＩはオブジェクト定義に２レベルの方法を使用しま
す。ＭＩＢ定義が２つの部分から成り立ちます：オブジェクトをグループで
扱うテキスト部分と、オブジェクトがＳＭＩで定義されるオブジェクト型の
ＡＳＮ．１マクロで記述されるＭＩＢモジュールです。
An example of the former definition might be:
前の定義の例が以下です：
OBJECT:
-------
sysLocation { system 6 }
Syntax:
DisplayString (SIZE (0..255))
Definition:
The physical location of this node (e.g., "telephone
closet, 3rd floor").
このノードの物理位置（例、「３階電話クロゼット」）
Access:
read-only.
Status:
mandatory.
An example of the latter definition might be:
後の定義の例が以下かもしれません：
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
::= { system 6 }
In the interests of brevity and to reduce the chance of
editing errors, it would seem useful to combine the two
definitions. This can be accomplished by defining an
extension to the OBJECT-TYPE macro:
簡潔さと編集誤りを減らすために、２つの定義を結合することが有用
に思われるでしょう。これはオブジェクト型のマクロへの拡張を定義
することで達成され得ます：
IMPORTS
ObjectName
FROM RFC1155-SMI
DisplayString
FROM RFC1158-MIB;
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
-- must conform to
-- RFC1155's ObjectSyntax
"SYNTAX" type(ObjectSyntax)
"ACCESS" Access
"STATUS" Status
DescrPart
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::= value (VALUE ObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
| "deprecated"
DescrPart ::=
"DESCRIPTION" value (description DisplayString)
| empty
ReferPart ::=
"REFERENCE" value (reference DisplayString)
| empty
IndexPart ::=
"INDEX" "{" IndexTypes "}"
| empty
IndexTypes ::=
IndexType | IndexTypes "," IndexType
IndexType ::=
-- if indexobject, use the SYNTAX
-- value of the correspondent
-- OBJECT-TYPE invocation
value (indexobject ObjectName)
-- otherwise use named SMI type
-- must conform to IndexSyntax below
| type (indextype)
DefValPart ::=
"DEFVAL" "{" value (defvalue ObjectSyntax) "}"
| empty
END
IndexSyntax ::=
CHOICE {
number
INTEGER (0..MAX),
string
OCTET STRING,
object
OBJECT IDENTIFIER,
address
NetworkAddress,
ipAddress
IpAddress
}
4.1. Mapping of the OBJECT-TYPE macro
4.1. オブジェクト型マクロのマッピング
It should be noted that the expansion of the OBJECT-TYPE macro is
something which conceptually happens during implementation and not
during run-time.
オブジェクト型マクロの拡張は、実装間での概念的問題で、実行時に起こる
ものではないことを指摘します。
4.1.1. Mapping of the SYNTAX clause
4.1.1. 構文論条項のマッピング
The SYNTAX clause, which must be present, defines the abstract data
structure corresponding to that object type. The ASN.1 language [6]
is used for this purpose. However, the SMI purposely restricts the
ASN.1 constructs which may be used. These restrictions are made
expressly for simplicity.
存在しているに違いない構文論条項は、そのオブジェクト型に対応している
抽象データ構造を定義します。ＡＳＮ．１言語[6]はこの目的のために使われ
ます。しかしながら、ＳＭＩは故意に使われるかもしれないＡＳＮ．１概念
を限定します。これらの制限は単純のために特別にされます。
4.1.2. Mapping of the ACCESS clause
4.1.2. アクセス条項のマッピング
The ACCESS clause, which must be present, defines the minimum level
of support required for that object type. As a local matter,
implementations may support other access types (e.g., an
implementation may elect to permitting writing a variable marked as
read-only). Further, protocol-specific "views" (e.g., those
indirectly implied by an SNMP community) may make further
restrictions on access to a variable.
存在しているに違いないアクセス条項はそのオブジェクト型に必要とされる
サポートの最小レベルを定義します。ローカル問題として、実装が他のアク
セス種別をサポートするかもしれません（例えば、実装が読込み専用という
マークされている変数に書込みを許すかもしれません）。さらに、プロトコ
ル余裕の「ビュー」（例えば、間接的にＳＮＭＰ共同体で暗示されたもの）
が変数アクセスに追加の制限をするかもしれません。
4.1.3. Mapping of the STATUS clause
4.1.3. 状態条項のマッピング
The STATUS clause, which must be present, defines the implementation
support required for that object type.
存在しているに違いない状態条項はそのオブジェクト型に必要とされる実装
サポートを定義します。
4.1.4. Mapping of the DESCRIPTION clause
4.1.4. 記述条項のマッピング
The DESCRIPTION clause, which need not be present, contains a textual
definition of that object type which provides all semantic
definitions necessary for implementation, and should embody any
information which would otherwise be communicated in any ASN.1
commentary annotations associated with the object. 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 object type elsewhere then the DESCRIPTION clause
must be present.
さらに、もしＭＩＢモジュールが他にオブジェクト型のテキスト記述を含ん
でいないなら、記述条項が存在しているに違いないことに注意してください。
4.1.5. Mapping of the REFERENCE clause
4.1.5. 参照条項のマッピング
The REFERENCE clause, which need not be present, contains a textual
cross-reference to an object defined in some other MIB module. This
is useful when de-osifying a MIB produced by some other organization.
存在してなくてもいい参照条項は何か他のＭＩＢモジュールで定義されたオ
ブジェクトのテキストの相互参照を含んでいます。これは、何か他の組織が
作ったＭＩＢの一部を利用する時に有用です。
4.1.6. Mapping of the INDEX clause
4.1.6. インデックス条項のマッピング
The INDEX clause, which may be present only if that object type
corresponds to a conceptual row, defines instance identification
information for that object type. (Historically, each MIB definition
contained a section entitled "Identification of OBJECT instances for
use with the SNMP". By using the INDEX clause, this section need no
longer occur as this clause concisely captures the precise semantics
needed for instance identification.)
そのオブジェクト型が概念行に対応する場合に限り、存在しているかもしれ
ないインデックス条項はそのオブジェクト型の実体識別情報を定義します。
（歴史的に、それぞれのＭＩＢ定義は「ＳＮＭＰで使う場合のオブジェクト
の実体識別」と題を付けられた章を含んでいました。インデックス条項を使
うことで、この条項が簡潔に実体識別に必要とされる正確な意味を示すので、
上記の章はもう必要ありません。）
If the INDEX clause is not present, and the object type corresponds
to a non-columnar object, then instances of the object are identified
by appending a sub-identifier of zero to the name of that object.
Further, note that if the MIB module does not contain a textual
description of how instance identification information is derived for
columnar objects, then the INDEX clause must be present.
もしインデックス条項が存在せず、そしてオブジェクト型が非コラム状オブ
ジェクトに対応するなら、オブジェクトの実体がそのオブジェクトの名前に
ゼロのサブ識別子を添えることで識別されます。さらに、もしＭＩＢモジュー
ルがコラム状オブジェクトの実体識別情報を得る方法のテキスト記述を含ん
でいないなら、インデックス条項が存在しているに違いないことに注意して
ください。
To define the instance identification information, determine which
object value(s) will unambiguously distinguish a conceptual row. The
syntax of those objects indicate how to form the instance-identifier:
実体識別情報を定義するために、どのオブジェクト値が明瞭に概念行を区別
するか決定してください。オブジェクトの実態識別をどう形成するかの構文：
(1) integer-valued: a single sub-identifier taking the
integer value (this works only for non-negative
integers);
(1) 整数値：整数値（これは非負整数）の、ひとつの副識別子。；
(2) string-valued, fixed-length strings: `n' sub-identifiers,
where `n' is the length of the string (each octet of the
string is encoded in a separate sub-identifier);
(2) 文字列値、固定長文字列：「ｎ」副識別子、（それぞれの文字
列オクテットが別のサブ識別子でコード化される）；
(3) string-valued, variable-length strings: `n+1' sub-
identifiers, where `n' is the length of the string (the
first sub-identifier is `n' itself, following this, each
octet of the string is encoded in a separate sub-
identifier);
(3) 文字列値、可変長文字列：「ｎ」が文字列長の時、「ｎ＋１」
副識別子（最初の副識別子がｎ自身で、後に続くそれぞれの文
字列オクテットが別のサブ識別子でコード化される）；
(4) object identifier-valued: `n+1' sub-identifiers, where
`n' is the number of sub-identifiers in the value (the
first sub-identifier is `n' itself, following this, each
sub-identifier in the value is copied);
(4) オブジェクト識別子値：：「ｎ」が値の副識別子の数である時、
「ｎ＋１」副識別子（最初の副識別子がｎ自身で、続く副識別
子はコピーされる）；
(5) NetworkAddress-valued: `n+1' sub-identifiers, where `n'
depends on the kind of address being encoded (the first
sub-identifier indicates the kind of address, value 1
indicates an IpAddress); or,
(5) ネットワークアドレス値、「ｎ＋１」副識別子、「ｎ」はコー
ド化されるアドレスの種類に依存（最初の副識別子はアドレス
の種類を示す、値１はＩＰアドレスを示す）；
(6) IpAddress-valued: 4 sub-identifiers, in the familiar
a.b.c.d notation.
(6) ＩＰアドレス値：既知のa.b.c.d表記の４つの副識別子。
Note that if an "indextype" value is present (e.g., INTEGER rather
than ifIndex), then a DESCRIPTION clause must be present; the text
contained therein indicates the semantics of the "indextype" value.
もし「indextype」値が存在しているなら（つまりifIndexでなく整数）、そ
れから記述条項が存在しているに違いないことに注意してください；テキス
トは「indextype」値の意味を示します。
By way of example, in the context of MIB-II [7], the following INDEX
clauses might be present:
例として、ＭＩＢ−II[7]の環境で、次のインデックス条項が存在しているか
もしれません：
objects under INDEX clause
----------------- ------------
ifEntry { ifIndex }
atEntry { atNetIfIndex,
atNetAddress }
ipAddrEntry { ipAdEntAddr }
ipRouteEntry { ipRouteDest }
ipNetToMediaEntry { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
tcpConnEntry { tcpConnLocalAddress,
tcpConnLocalPort,
tcpConnRemoteAddress,
tcpConnRemotePort }
udpEntry { udpLocalAddress,
udpLocalPort }
egpNeighEntry { egpNeighAddr }
4.1.7. Mapping of the DEFVAL clause
4.1.7. DEFVAL条項のマッピング
The DEFVAL clause, which need not be present, defines an acceptable
default value which may be used when an object instance is created at
the discretion of the agent acting in conformance with the third
paradigm described in Section 4.2 above.
存在してなくてもいいDEFVAL条項は、オブジェクトの実体が上記４.２章の３
段落目の記述に従うエージェント動きの裁量で作られる時、使われるかもし
れない受容できるデフォルト値を定義します。
During conceptual row creation, if an instance of a columnar object
is not present as one of the operands in the correspondent SNMP set
operation, then the value of the DEFVAL clause, if present, indicates
an acceptable default value that the agent might use.
概念行の作成の間に、もしコラム状オブジェクトの実体が対応するＳＮＭＰ
設定オペレーションのどこかの命令に存在しないなら、DEFVAL条項の値があ
ればエージェントが使ってもいいデフォルト値を示します。
The value of the DEFVAL clause must, of course, correspond to the
SYNTAX clause for the object. Note that if an operand to the SNMP
set operation is an instance of a read-only object, then the error
noSuchName will be returned. As such, the DEFVAL clause can be used
to provide an acceptable default value that the agent might use.
DEFVALの値は、もちろん、オブジェクトの構文条項に対応しなくてはなりま
せん。もしＳＮＭＰ設定オペレーションの命令が読み込み専用オブジェクト
の実体へなら、エラーnoSuchNameが返されるであろうことに注意してくださ
い。それで、DEFVAL条項はエージェントが使うかもしれない受容できるデフォ
ルト値を供給するために使うことができます。
It is possible that no acceptable default value may exist for any of
the columnar objects in a conceptual row for which the creation of
new object instances is allowed. In this case, the objects specified
in the INDEX clause must have a corresponding ACCESS clause value of
read-write.
新しいオブジェクトの実体の作成が許される概念行のコラム状オブジェクト
で、許容できるデフォルト値が存在しないことは可能です。この場合、イン
デックス条項で指定されたオブジェクトは対応するアクセス条項で読書き可
能の値を持たなくてはなりません。
By way of example, consider the following possible DEFVAL clauses:
例えば、次のDEFVAL条項を考えてください：
ObjectSyntax DEFVAL clause
----------------- ------------
INTEGER 1 -- same for Counter, Gauge, TimeTicks
OCTET STRING 'ffffffffffff'h
DisplayString "any NVT ASCII string"
OBJECT IDENTIFIER sysDescr
OBJECT IDENTIFIER { system 2 }
NULL NULL
NetworkAddress { internet 'c0210415'h }
IpAddress 'c0210415'h -- 192.33.4.21
4.1.8. Mapping of the OBJECT-TYPE value
4.1.8. オブジェクト型のマッピング
The value of an invocation of the OBJECT-TYPE macro is the name of
the object, which is an object identifier.
オブジェクト型マクロの値はオブジェクトの名前で、これはオブジェクト識
別子です。
4.2. Usage Example
4.2. 使用例
Consider how the ipNetToMediaTable from MIB-II might be fully
described:
どのようにＭＩＢ−ＩＩからipNetToMediaTableが完全に記述されるか考え
てください：
-- the IP Address Translation tables
-- ＩＰアドレス翻訳テーブル
-- The Address Translation tables contain IpAddress to
-- "physical" address equivalences. Some interfaces do not
-- use translation tables for determining address equivalences
-- (e.g., DDN-X.25 has an algorithmic method); if all
-- interfaces are of this type, then the Address Translation
-- table is empty, i.e., has zero entries.
-- アドレス翻訳テーブルは「物理」アドレスと等価なIpAddressを含
-- んでいます。あるインタフェースがアドレスと等価な物（例えば、
-- ＸＸＮ−Ｘ.２５はアルゴリズム手法を使う）を決定する際に翻訳
-- テーブルを使いません；。もしすべてのインタフェースがこのタイ
-- プなら、アドレス翻訳テーブルは、空で、ゼロ個の項目を持ってい
-- ます。
ipNetToMediaTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpNetToMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The IP Address Translation table used for mapping
from IP addresses to physical addresses."
"ＩＰアドレスから物理アドレスへのマッピングに使わ
れるＩＰアドレス翻訳テーブル。"
::= { ip 22 }
ipNetToMediaEntry OBJECT-TYPE
SYNTAX IpNetToMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Each entry contains one IpAddress to 'physical'
address equivalence."
"「それぞれの項目が「物理」アドレスと等価な１つの
IpAddressを含んでいます。"
INDEX { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
::= { ipNetToMediaTable 1 }
IpNetToMediaEntry ::=
SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
OCTET STRING,
ipNetToMediaNetAddress
IpAddress,
ipNetoToMediaType
INTEGER
}
ipNetToMediaIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The interface on which this entry's equivalence
is effective. The interface identified by a
particular value of this index is the same
interface as identified by the same value of
ifIndex."
"この項目の等価物が有効なインタフェース。このイン
デックスの特定の値で識別されたインタフェースは
ifIndexの同じ値で識別されるものと同じインタフェー
スです。"
::= { ipNetToMediaEntry 1 }
ipNetToMediaPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The media-dependent 'physical' address."
"メディア依存の「物理」アドレス。"
::= { ipNetToMediaEntry 2 }
ipNetToMediaNetAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IpAddress corresponding to the media-
dependent 'physical' address."
"メディア依存の「物理」アドレスに対応している
IpAddress。"
::= { ipNetToMediaEntry 3 }
ipNetToMediaType OBJECT-TYPE
SYNTAX INTEGER {
other(1), -- none of the following
invalid(2), -- an invalidated mapping
dynamic(3),
static(4)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The type of mapping.
"型のマッピング。
Setting this object to the value invalid(2) has
the effect of invalidating the corresponding entry
in the ipNetToMediaTable. That is, it effectively
disassociates the interface identified with said
entry from the mapping identified with said entry.
It is an implementation-specific matter as to
whether the agent removes an invalidated entry
from the table. Accordingly, management stations
must be prepared to receive tabular information
from agents that corresponds to entries not
currently in use. Proper interpretation of such
entries requires examination of the relevant
ipNetToMediaType object."
このオブジェクトの価を無効(2)に設定するすることは、
ipNetToMediaTableの対応する項目を無効にする効果を
持っています。すなわち、当該項目で示されたマッピン
グと、当該項目で示されたインタフェースを切り離しま
す。エージェントが無効な項目をテーブルから取り除く
かどうかは実装固有の問題です。したがって、管理装置
はエージェントから現在使用中でない項目に対応する表
情報を受け取る用意ができているに違いありません。こ
のような項目の適切な解釈は適切なipNetToMediaTypeオ
ブジェクトの検査を必要とします。"
::= { ipNetToMediaEntry 4 }
5. Appendix: DE-osifying MIBs
5. 付録：流用ＭＩＢ
There has been an increasing amount of work recently on taking MIBs
defined by other organizations (e.g., the IEEE) and de-osifying them
for use with the Internet-standard network management framework. The
steps to achieve this are straight-forward, though tedious. Of
course, it is helpful to already be experienced in writing MIB
modules for use with the Internet-standard network management
framework.
他組織（例えばＩＥＥＥ）の定義したＭＩＢを使う仕事が増加しました、そ
してインターネット標準ネットワーク管理フレームワークで使用するためそ
れらが流用されました。これを成し遂げるステップは、退屈であるが、簡単
です。もちろん、すでにインターネット標準ネットワーク管理フレームワー
クで使用するためにＭＩＢモジュールを書く経験が助けになります。
The first step is to construct a skeletal MIB module, e.g.,
最初のステップ骨格ＭＩＢモジュールを組み立てる事です、例えば、
RFC1213-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, OBJECT-TYPE, Counter
FROM RFC1155-SMI;
-- contact IANA for actual number
root OBJECT IDENTIFIER ::= { experimental xx }
END
The next step is to categorize the objects into groups. For
experimental MIBs, optional objects are permitted. However, when a
MIB module is placed in the Internet-standard space, these optional
objects are either removed, or placed in a optional group, which, if
implemented, all objects in the group must be implemented. For the
first pass, it is wisest to simply ignore any optional objects in the
original MIB: experience shows it is better to define a core MIB
module first, containing only essential objects; later, if experience
demands, other objects can be added.
次のステップはオブジェクトをグループに分類することです。実験的なＭＩ
Ｂのために、任意追加のオブジェクトが認められます。ＭＩＢモジュールが
インターネット標準空間に置かれる時、これらの任意追加のオブジェクトは
除かれるか、オプショングループに置かれ、もし実装されるなら、すべてグ
ループのオブジェクトが実装実行されなくてはなりません。最初の、それは
オリジナルのＭＩＢのの任意追加のオブジェクトを単純に無視するのが最も
賢明です：経験的に、最初に不可欠なオブジェクトだけを含むコアＭＩＢモ
ジュールを定義することがもっと良いです；後で、経験的に必要なら、他の
オブジェクトが追加できます。
It must be emphasized that groups are "units of conformance" within a
MIB: everything in a group is "mandatory" and implementations do
either whole groups or none.
グループがＭＩＢの「準拠単位」であることを強調します：グループのすべ
てが「必須」で、そしてグループ全体を実装するか、まったく実装しないか
です。
5.1. Managed Object Mapping
5.1. 管理オブジェクトのマッピング
Next for each managed object class, determine whether there can exist
multiple instances of that managed object class. If not, then for
each of its attributes, use the OBJECT-TYPE macro to make an
equivalent definition.
次にそれぞれの管理オブジェクトクラスで、管理オブジェクトクラスの実体
が多数存在することができるか決定してください。もしできなければ、その
属性のそれぞれで、等価な定義をするためにオブジェクト型マクロを使って
ください。
Otherwise, if multiple instances of the managed object class can
exist, then define a conceptual table having conceptual rows each
containing a columnar object for each of the managed object class's
attributes. If the managed object class is contained within the
containment tree of another managed object class, then the assignment
of an object type is normally required for each of the "distinguished
attributes" of the containing managed object class. If they do not
already exist within the MIB module, then they can be added via the
definition of additional columnar objects in the conceptual row
corresponding to the contained managed object class.
さもなければ、もし管理オブジェクトクラスの多数の実体が存在できるなら、
管理オブジェクトクラスの属性のそれぞれのコラム状オブジェクトが概念行
に含まれる、概念表を定義してください。もし管理オブジェクトクラスが他
の管理されたオブジェクトクラスの抑制木内にあるなら、通常、管理オブジェ
クトクラスに含まれるそれぞれの「著名属性」にオブジェクト型の割り当て
が要求されます。もしそれらがＭＩＢモジュールの中に存在しないなら、含
まれる管理オブジェクトクラスに対応している概念行の追加のコラム状オブ
ジェクトの定義によって追加ができます。
In defining a conceptual row, it is useful to consider the
optimization of network management operations which will act upon its
columnar objects. In particular, it is wisest to avoid defining more
columnar objects within a conceptual row, than can fit in a single
PDU. As a rule of thumb, a conceptual row should contain no more
than approximately 20 objects. Similarly, or as a way to abide by
the "20 object guideline", columnar objects should be grouped into
tables according to the expected grouping of network management
operations upon them. As such, the content of conceptual rows should
reflect typical access scenarios, e.g., they should be organized
along functional lines such as one row for statistics and another row
for parameters, or along usage lines such as commonly-needed objects
versus rarely-needed objects.
概念的行の定義で、コラム状オブジェクトに作用するネットワーク管理オペ
レーションの最適化を考えることは有用です。特に、それはひとつのＰＤＵ
に入らないほどのコラム状オブジェクトを概念行に定義するのを避けるのは
最も賢明です。概算として、概念行がおよそ２０以上のオブジェクトを含ん
でいるべきではありません。同様に、あるいは「２０オブジェクトガイドラ
イン」に従う方法として、コラム状オブジェクトがネットワーク管理オペレー
ションの期待された組分けに従って表の中でまとめられるべきです。概念行
の内容が典型的なアクセスシナリオを反映するべきで、例えば、ある行は統
計で他の行はパラメータで、あるいは一般に必要とされたオブジェクトと稀
に必要なオブジェクトと使用法で、いったように機能的な行に沿って組織化
されるべきです。
On the other hand, the definition of conceptual rows where the number
of columnar objects used as indexes outnumbers the number used to
hold information, should also be avoided. In particular, the
splitting of a managed object class's attributes into many conceptual
tables should not be used as a way to obtain the same degree of
flexibility/complexity as is often found in MIB's with a myriad of
optionals.
他方、インデックスとして用いられたコラム状オブジェクトの数が、情報を
持つために使われた数より多いような、概念行の定義も避けられるべきです。
特に、管理オブジェクトクラスの属性を多数の表に分ける事を、無数のオプ
ションのＭＩＢでしばしば行われるのと同等の柔軟性や複雑さを得る方法と
して用いられるべきではありません。
5.1.1. Mapping to the SYNTAX clause
5.1.1. 構文条項へのマッピング
When mapping to the SYNTAX clause of the OBJECT-type macro:
オブジェクト型マクロの構文条項にマッピングする時：
(1) An object with BOOLEAN syntax becomes an INTEGER taking
either of values true(1) or false(2).
(1) 論理構文を持つオブジェクトが真(1)と偽(2)の値を持つ整数にな
ります。
(2) An object with ENUMERATED syntax becomes an INTEGER,
taking any of the values given.
(2) 列挙構文を持つオブジェクトが、与えられた値のどれでも取れる、
整数になります。
(3) An object with BIT STRING syntax containing no more than
32 bits becomes an INTEGER defined as a sum; otherwise if
more than 32 bits are present, the object becomes an
OCTET STRING, with the bits numbered from left-to-right,
in which the least significant bits of the last octet may
be "reserved for future use".
(3) ３２ビット以下のビット列構文のオブジェクトが全体で整数にな
ります；もし３２ビットより多ければ、オブジェクトは、最終オ
クテットの最下位ビットが「将来の使用のために予約」とされ、
右から左にビットに番号を付けて、オクテット列になります。
(4) An object with a character string syntax becomes either
an OCTET STRING or a DisplayString, depending on the
repertoire of the character string.
(4) キャラクタ文字列構文のオブジェクトが、文字列の種類によっ
て、オクテット列あるいは表示文字列になります。
(5) An non-tabular object with a complex syntax, such as REAL
or EXTERNAL, must be decomposed, usually into an OCTET
STRING (if sensible). As a rule, any object with a
complicated syntax should be avoided.
(5) 実数や外部型のような、複雑な構文を持つ表でないオブジェク
トは、分解されて通常オクテット列に入れられるに違いありませ
ん（もし適切なら）。規則として、複雑構文のオブジェクトは避
けるべきです。
(6) Tabular objects must be decomposed into rows of columnar
objects.
(6) 表オブジェクトはコラム状オブジェクトの行に分解されるに違
いありません。
5.1.2. Mapping to the ACCESS clause
5.1.2. アクセス条項へのマッピング
This is straight-forward.
これは簡単です。
5.1.3. Mapping to the STATUS clause
5.1.3. 状態条項へのマッピング
This is usually straight-forward; however, some osified-MIBs use the
term "recommended". In this case, a choice must be made between
"mandatory" and "optional".
これは通常簡単です；しかしながら、ある流用ＭＩＢが用語「推薦」を使い
ます。この場合、「義務」か「任意」かの選択がされなくてはなりません。
5.1.4. Mapping to the DESCRIPTION clause
5.1.4. 記述条項へのマッピング
This is straight-forward: simply copy the text, making sure that any
embedded double quotation marks are sanitized (i.e., replaced with
single-quotes or removed).
これは簡単です：ただ、どんな埋め込まれた二重引符を避けて（一重引用符
に置き換えるか削除する）、テキストをコピーしてください。
5.1.5. Mapping to the REFERENCE clause
5.1.5. 参照条項へのマッピング
This is straight-forward: simply include a textual reference to the
object being mapped, the document which defines the object, and
perhaps a page number in the document.
これは簡単です：マップされるオブジェクトと、オブジェクトを定義する文
書と、文書のページと段落番号を含む、参照のテキストを含めます。
5.1.6. Mapping to the INDEX clause
5.1.6. インデックス条項へのマッピング
Decide how instance-identifiers for columnar objects are to be formed
and define this clause accordingly.
コラム状オブジェクトの実体識別子の生成方法を決断し、相応にこの条項を
定義してください。
5.1.7. Mapping to the DEFVAL clause
5.1.7. DEFVAL条項へのマッピング
Decide if a meaningful default value can be assigned to the object
being mapped, and if so, define the DEFVAL clause accordingly.
意味があるデフォルト値がマップされるオブジェクトに割当てできるかどう
か決定し、もしそうなら、相応にDEFVAL条項を定義してください。
5.2. Action Mapping
5.2. 行動へのマッピング
Actions are modeled as read-write objects, in which writing a
particular value results in the action taking place.
行動は読書きオブジェクトで設計され、そこでの記述は特定の値が行動が起
こす結果になるということです。
5.2.1. Mapping to the SYNTAX clause
5.2.1. 構文条項へのマッピング
Usually an INTEGER syntax is used with a distinguished value provided
for each action that the object provides access to. In addition,
there is usually one other distinguished value, which is the one
returned when the object is read.
通常、オブジェクトアクセスを供給するそれぞれの行動の著名な値の、整数
構文が使われます。加えて、オブジェクトが読み込まれる時に返される、他
の著名な値があります。
5.2.2. Mapping to the ACCESS clause
5.2.2. アクセス条項へのマッピング
Always use read-write.
常に読書き可を使ってください。
5.2.3. Mapping to the STATUS clause
5.2.3. 状態条項へのマッピング
This is straight-forward.
これは簡単です。
5.2.4. Mapping to the DESCRIPTION clause
5.2.4. 記述条項へのマッピング
This is straight-forward: simply copy the text, making sure that any
embedded double quotation marks are sanitized (i.e., replaced with
single-quotes or removed).
これは簡単です：ただ、どんな埋め込まれた二重引符を避けて（一重引用符
に置き換えるか削除する）、テキストをコピーしてください。
5.2.5. Mapping to the REFERENCE clause
5.2.5. 参照条項へのマッピング
This is straight-forward: simply include a textual reference to the
action being mapped, the document which defines the action, and
perhaps a page number in the document.
これは簡単です：マップされるオブジェクトと、オブジェクトを定義する文
書と、文書のページと段落番号を含む、参照のテキストを含めます。
6. Acknowledgements
6. 謝辞
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
7. References
7. 参考文献
[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.
8. Security Considerations
8. セキュリティの考察
Security issues are not discussed in this memo.
セキュリティ問題がこの文書で論じられません。
9. Authors' Addresses
9. 著者のアドレス
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
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
1225 Charleston Road
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.com