RFC1212 日本語訳
1212 Concise MIB definitions. M.T. Rose, K. McCloghrie. March 1991. (Format: TXT=43579 bytes) (Also STD0016) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose
Request for Comments: 1212 Performance Systems International
K. McCloghrie
Hughes LAN Systems
Editors
March 1991
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 1991年のK.McCloghrieヒューズのLANシステムエディターズ行進の国際の1212個の言語運用機構
Concise MIB Definitions
Status of this Memo
このMemoの簡潔なMIB Definitions Status
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.
このメモは、MIBモジュールを作成するために書式を定義します。 このRFCはIAB標準化過程ドキュメントをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Abstract.............................................. 2 2. Historical Perspective ............................... 2 3. Columnar Objects ..................................... 3 3.1 Row Deletion ........................................ 4 3.2 Row Addition ........................................ 4 4. Defining Objects ..................................... 5 4.1 Mapping of the OBJECT-TYPE macro .................... 7 4.1.1 Mapping of the SYNTAX clause ...................... 7 4.1.2 Mapping of the ACCESS clause ...................... 8 4.1.3 Mapping of the STATUS clause ...................... 8 4.1.4 Mapping of the DESCRIPTION clause ................. 8 4.1.5 Mapping of the REFERENCE clause ................... 8 4.1.6 Mapping of the INDEX clause ....................... 8 4.1.7 Mapping of the DEFVAL clause ...................... 10 4.1.8 Mapping of the OBJECT-TYPE value .................. 11 4.2 Usage Example ....................................... 11 5. Appendix: DE-osifying MIBs ........................... 13 5.1 Managed Object Mapping .............................. 14 5.1.1 Mapping to the SYNTAX clause ...................... 15 5.1.2 Mapping to the ACCESS clause ...................... 15 5.1.3 Mapping to the STATUS clause ...................... 15 5.1.4 Mapping to the DESCRIPTION clause ................. 15 5.1.5 Mapping to the REFERENCE clause ................... 16 5.1.6 Mapping to the INDEX clause ....................... 16 5.1.7 Mapping to the DEFVAL clause ...................... 16 5.2 Action Mapping ...................................... 16 5.2.1 Mapping to the SYNTAX clause ...................... 16 5.2.2 Mapping to the ACCESS clause ...................... 16
1. 要約… 2 2. 歴史的な見解… 2 3. 円柱状のオブジェクト… 3 3.1 削除をこいでください… 4 3.2 追加をこいでください… 4 4. オブジェクトを定義します… 5 OBJECT-TYPEマクロに関する4.1マッピング… 7 4.1 SYNTAX節に関する.1マッピング… 7 4.1 ACCESS節に関する.2マッピング… 8 4.1 STATUS節に関する.3マッピング… 8 4.1 記述節に関する.4マッピング… 8 4.1 REFERENCE節に関する.5マッピング… 8 4.1 INDEX節に関する.6マッピング… 8 4.1 DEFVAL節に関する.7マッピング… 10 4.1 OBJECT-TYPE価値に関する.8マッピング… 11 4.2使用例… 11 5. 付録: 反-osifying MIBs… 13 5.1管理オブジェクトマッピング… 14 5.1 .1 SYNTAX節に写像します。 15 5.1 .2 ACCESS節に写像します。 15 5.1 .3 STATUS節に写像します。 15 5.1 .4 記述節に写像します。 15 5.1 .5 REFERENCE節に写像します。 16 5.1 .6 INDEX節に写像します。 16 5.1 .7 DEFVAL節に写像します。 16 5.2動作マッピング… 16 5.2 .1 SYNTAX節に写像します。 16 5.2 .2 ACCESS節に写像します。 16
SNMP Working Group [Page 1] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[1ページ]RFC1212
5.2.3 Mapping to the STATUS clause ...................... 16 5.2.4 Mapping to the DESCRIPTION clause ................. 16 5.2.5 Mapping to the REFERENCE clause ................... 16 6. Acknowledgements ..................................... 17 7. References ........................................... 18 8. Security Considerations............................... 19 9. Authors' Addresses.................................... 19
5.2.3 STATUS節へのマッピング… 16 5.2 .4 記述節に写像します。 16 5.2 .5 REFERENCE節に写像します。 16 6. 承認… 17 7. 参照… 18 8. セキュリティ問題… 19 9. 作者のアドレス… 19
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.
簡潔で、しかし、描写的であるMIBモジュールを作成することに向かってこのメモは簡単なアプローチを説明します。 すべての将来のMIBモジュールがこの形式で書かれていることを意図します。
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.
RFC1052、インターネットNetwork Management Standards[1]のDevelopmentのためのIAB Recommendationsで報告されるように、TCP/IPベースのインターネットのネットワークマネージメントのための2歯の戦略は引き受けられました。 短期的では、RFC1067で定義されたSimple Network Managementプロトコル(SNMP)はインターネットコミュニティでノードを管理するのに使用されることでした。 長期では、OSIネットワークマネージメントフレームワークの使用は調べられることでした。 2通のドキュメントが経営情報を定義するために製作されました: (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
1990年5月に、コアドキュメントは「お勧め」の状態で「標準プロトコル」に登用されました。 そういうものとして、インターネット標準ネットワークマネージメントフレームワークは以下から成ります。 TCP/IPベースのインターネットのためのManagement情報、RFC1155[3]の構造とIdentification。([3]は管理オブジェクトがどうコネを含んだかを説明します)。
SNMP Working Group [Page 2] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[2ページ]RFC1212
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.
MIBは定義されます。 TCP/IPベースのインターネットのNetwork Managementのための管理Information基地(Network ManagementはMIB、RFC1156[4]に含まれた管理オブジェクトについて説明します)。 そして、以前はよくSimple Network Managementプロトコル、プロトコルを定義するRFC1157[5]をこれらのオブジェクトを管理していました。 短期的で簡単で、実行可能なシステムを作成するIAB指示と一致しています、インターネット標準MIBで定義された管理オブジェクトのリストは、不可欠であると考えられるそれらの要素だけを取ることによって、引き出されました。 しかしながら、SMIは3つの伸展性メカニズムを定義しました: 1、MIBの新しいバージョンの定義による新しい標準のオブジェクトの追加。 2、実験下位木を通した広く利用可能な、しかし、標準的でないオブジェクトの追加。 3、企業下位木を通した個人的なオブジェクトの追加。 ベンダー特有の要素にそのような追加オブジェクトを使用できるだけではありませんが、実験において、どれについて知識を促進するかに、必要に応じて、他のオブジェクトは、また不可欠でもあります。
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.
より多くのオブジェクトが2番目のメソッドを使用することで定義されるとき、経験は、結果として起こるMIB記述が余分な情報を含むのを示しました。 より簡潔なMIB記述にもかかわらず、有益であるとして提供するために、増進は示されます。 この増進で、MIBの作者は重要な説明文を保有している間、余分な情報を取り除くことができます。
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.
アプローチを提示する前に、SNMPによる円柱状のオブジェクト取り扱いの簡潔なプレゼンテーションが必要です。 これは、増進の値を説明して、さらに、動機づけます。
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.
SNMPは構文がSMIで定義されるようにObjectSyntaxであるMIBオブジェクトの上に操作をサポートします。 非公式に述べられたSNMP操作は排他的にスカラのオブジェクトに適用されます。 しかしながら、管理アプリケーションの開発者にとって、MIBを構成するオブジェクトの規則正しい収集に想像して、表の構造を課すのは都合がよいです。 以上は船をこぎます、そして、そのようなそれぞれの概念的なテーブルがゼロを含んでいるか、または各行は1個以上のスカラのオブジェクト(呼ばれた円柱状のオブジェクト)を含むかもしれません。 歴史的に、この概念化は、テーブルに対応するオブジェクトとそのテーブルの行に対応するオブジェクトの両方を定義するのにOBJECT-TYPEマクロを使用することによって、正式にされました。 (そのようなオブジェクトのためのACCESS節が「アクセスしやすくない」、もちろん。) しかしながら、同じ行の円柱状のオブジェクトの中の関係がプロトコルレベルにおいて、プロトコルではなく、コンベンションの物質であると強調しなければなりません。
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
表構造が外交儀礼の問題でない十分な理由があることに注意してください。 操作を考える、SNMP Get次PDU、a概念的のインスタンスの最後の円柱状のオブジェクトに影響すること。
SNMP Working Group [Page 3] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[3ページ]RFC1212
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.
船をこいでください。 それは最初の概念的な行かテーブルの後に起こる最初のオブジェクトインスタンスに関する次のコラムを返します。 対照的に、行が外交儀礼の問題であるなら、それは代わりに誤りを返すでしょうに。 誤りを返さないことによって、ただ一つのPDU交換は達した概念的な行/テーブルの端を持っているだけではなく、次のオブジェクトインスタンスの情報を提供もするマネージャに知らせます、その結果、PDU交換の情報密度を増強します。
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.
それにもかかわらず、概念的な行がテーブルから取り除かれるかもしれない手段を提供するのは非常に役に立ちます。 MIB-IIでは、これは、それぞれの概念的な行のために整数で評価された円柱状のオブジェクトを定義することによって、達成されました。 管理局が通常、「病人」と呼ばれた何らかの値にこのオブジェクトの値を設定するなら、効果はテーブルの対応する行を無効にするものです。 しかしながら、それはエージェントがテーブルから無効にされたエントリーを取り除くかどうかに関する実装特有の問題です。 それに従って、エージェントからの現在使用中でないエントリーに対応する表情報を受け取るように管理局を準備しなければなりません。 そのようなエントリーの適切な解釈は使用中である状態を示す円柱状のオブジェクトの試験を必要とします。
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:
また、概念的な行がどうテーブルに加えられるかもしれないかに関する明確な理解を持っているのも非常に役に立ちます。 SNMPでは、プロトコルレベルでは、管理局は任意の変項束縛を含むSNMP集合演算を発行します。 SNMPの規則では、エージェントがそれを検出して、それらの変項束縛のより多くのひとりは現在そのエージェントで利用可能でないオブジェクトインスタンスについて言及して、以下のパラダイムのどれかに従って、反応するかもしれません:
(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"に設定されたエラー状況分野で実在しないオブジェクトインスタンスについて言及するとしての集合演算と誤りインデックス部が最初の空虚な参照を示すように設定するSNMPを拒絶するかもしれません。
(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
(2) それは変項束縛で指定されたそれぞれのオブジェクトインスタンスに対応する新しいオブジェクトインスタンスの作成を要求するとSNMP集合演算を認めるかもしれません。 それぞれの(潜在的に)新たに作成されたオブジェクトインスタンスの値は関連変項束縛の「値」コンポーネントによって指定されます。 または要求が指定するならこの場合aのための値が新たに、それが価値の理由で不適当であると考えるオブジェクトを作成した、(以前に)。
SNMP Working Group [Page 4] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[4ページ]RFC1212
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.
構文、そして、それはエラー状況分野セットでbadValueに応じるのによる集合演算と誤りインデックス部が最初の怒っている変項束縛について言及するように設定するSNMPを拒絶します。
(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) それは、SNMP集合演算を受け入れて、上で(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.
すべての3つの上の振舞いがSNMP仕様に完全にconformantで、アクセスコントロールで課されるどんな制限、そして/または、MIBオブジェクト自体の定義を条件として完全に許容できると強調されるべきです。
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.
インターネット標準SMIはオブジェクト定義に向かった2レベルのアプローチを使います。 MIB定義は2つの部品から成ります: (そこでは、オブジェクトがグループに置かれます)。原文の部分、およびMIBモジュールはどのオブジェクトで唯一ASN.1マクロOBJECT-TYPEで説明されるか。(OBJECT-TYPEはSMIによって定義されます)。
An example of the former definition might be:
前の定義に関する例は以下の通りです。
OBJECT:
-------
sysLocation { system 6 }
オブジェクト: ------- sysLocationシステム6
Syntax:
DisplayString (SIZE (0..255))
構文: DisplayString(サイズ(0 .255))
Definition:
The physical location of this node (e.g., "telephone
closet, 3rd floor").
定義: このノード(例えば、「電話クロゼット、3階」)の物理的な位置。
Access:
read-only.
アクセス: 書き込み禁止。
Status:
mandatory.
状態: 義務的。
An example of the latter definition might be:
後者の定義に関する例は以下の通りです。
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
sysLocationオブジェクト・タイプ構文DisplayString(サイズ(0 .255))
SNMP Working Group [Page 5] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[5ページ]RFC1212
ACCESS read-only
STATUS mandatory
::= { system 6 }
ACCESS書き込み禁止STATUS義務的:、:= システム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:
簡潔さの関心であり誤りを編集するという機会であり減少するために、中では、それは役に立つように見えるでしょう。2つの定義を結合するために。 OBJECT-TYPEマクロと拡大を定義することによって、これを達成できます:
IMPORTS
ObjectName
FROM RFC1155-SMI
DisplayString
FROM RFC1158-MIB;
RFC1155-SMI DisplayStringからRFC1158-MIBからObjectNameをインポートします。
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)
オブジェクト・タイプマクロ:、:= タイプ記法を始めてください:、:= -- 従わなければならない、--RFC1155のObjectSyntax「構文」タイプ(ObjectSyntax)「アクセス」アクセス「状態」状態DescrPart ReferPart IndexPart DefValPartは記法を評価します:、:= 値(値のObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
| "deprecated"
以下にアクセスしてください:= 「書き込み禁止」| 「-読まれて、書いてください」| 「書く、-単に、」| 「アクセスしやすくない」状態:、:= 「義務的です」。| 「任意です」。| 「時代遅れです」。| 「推奨しないです」。
DescrPart ::=
"DESCRIPTION" value (description DisplayString)
| empty
DescrPart:、:= 「記述」値(記述DisplayString)| 空になってください。
ReferPart ::=
"REFERENCE" value (reference DisplayString)
| empty
ReferPart:、:= "REFERENCE"値(参照DisplayString)| 空になってください。
IndexPart ::=
"INDEX" "{" IndexTypes "}"
IndexPart:、:= 「索引をつけてください」、「「IndexTypes」、」
SNMP Working Group [Page 6] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[6ページ]RFC1212
| 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)
| IndexTypesを空にしてください:、:= IndexType| 」 「IndexTypes」、IndexType IndexType:、:= -- indexobject、OBJECT-TYPE実施の価値(indexobject ObjectName)(そうでなければSMIタイプという使用)が以下のIndexSyntaxに従わせなければならないSYNTAX(通信員の値)を使用してくださいなら| タイプ(indextype)
DefValPart ::=
"DEFVAL" "{" value (defvalue ObjectSyntax) "}"
| empty
DefValPart:、:= "DEFVAL"「「値(defvalue ObjectSyntax)」」| 空になってください。
END
終わり
IndexSyntax ::=
CHOICE {
number
INTEGER (0..MAX),
string
OCTET STRING,
object
OBJECT IDENTIFIER,
address
NetworkAddress,
ipAddress
IpAddress
}
IndexSyntax:、:= 選択数のINTEGER(0..MAX)(ストリングOCTET STRING、オブジェクトOBJECT IDENTIFIER)はNetworkAddress、ipAddress IpAddressを扱います。
4.1. Mapping of the OBJECT-TYPE macro
4.1. OBJECT-TYPEマクロに関するマッピング
It should be noted that the expansion of the OBJECT-TYPE macro is something which conceptually happens during implementation and not during run-time.
OBJECT-TYPEマクロの拡張がランタイムの間、起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
4.1.1. Mapping of the SYNTAX clause
4.1.1. SYNTAX節に関するマッピング
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.
SYNTAX節(存在していなければならない)はそのオブジェクト・タイプにとって、対応する抽象的なデータ構造を定義します。 ASN.1言語[6]はこのために使用されます。 しかしながら、SMIはわざわざ使用されるかもしれないASN.1構造物を制限します。 簡単さのために明白にこれらの制限をします。
SNMP Working Group [Page 7] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[7ページ]RFC1212
4.1.2. Mapping of the ACCESS clause
4.1.2. ACCESS節に関するマッピング
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.
ACCESS節(存在していなければならない)はそのオブジェクト・タイプに必要である最小のサポート水準を定義します。 地域にかかわる事柄として、実装は他のアクセス型をサポートするかもしれません(書くことを許可するのに例えば、実装は書き込み禁止としてマークされた変数を選出するかもしれません)。 さらに、プロトコル特有の「視点」(例えばSNMP共同体によって間接的に含意されたもの)は変数へのアクセスのときにさらなる制限をするかもしれません。
4.1.3. Mapping of the STATUS clause
4.1.3. STATUS節に関するマッピング
The STATUS clause, which must be present, defines the implementation support required for that object type.
STATUS節(存在していなければならない)はそのオブジェクト・タイプに必要である実装サポートを定義します。
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.
記述節(存在している必要はない)は、実装に必要なすべての意味定義を提供するそのオブジェクト・タイプの原文の定義を含んでいて、そうでなければオブジェクトに関連しているどんなASN.1論評注釈でも伝えられるどんな情報も具体化するべきです。 ASN.1構文に従うためにダブル・クォーテーション・マークにこの節の全体の値を同封しなければならないことに注意してください、値はマルチ系列であるかもしれないのにもかかわらず。
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.
さらに、MIBモジュールがほかの場所にオブジェクト・タイプの原文の記述を含んでいないなら記述節が存在していなければならないことに注意してください。
4.1.5. Mapping of the REFERENCE clause
4.1.5. REFERENCE節に関するマッピング
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.
REFERENCE節(存在している必要はない)はある他のMIBモジュールで定義されたオブジェクトに原文の相互参照を含んでいます。 反-ある他の組織によって生産されたMIBをosifyingするとき、これは役に立ちます。
4.1.6. Mapping of the INDEX clause
4.1.6. INDEX節に関するマッピング
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.)
INDEX節(そのオブジェクト・タイプが概念的な行に文通する場合にだけ、存在しているかもしれない)はそのオブジェクト・タイプのためにインスタンス識別情報を定義します。 歴史的に、それぞれのMIB定義は「SNMPとの使用のためのOBJECTインスタンスの識別」の権利を与えられたセクションを含みました。(INDEX節を使用することによって、この節が意味論が必要とした正確に例えば識別を簡潔に得るとき、このセクションはもう現れる必要はありません。)
If the INDEX clause is not present, and the object type corresponds to a non-columnar object, then instances of the object are identified
INDEX節が存在していなくて、オブジェクト・タイプが非円柱状のオブジェクトに文通するなら、オブジェクトのインスタンスは特定されます。
SNMP Working Group [Page 8] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[8ページ]RFC1212
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.
ゼロに関するサブ識別子をその名前に追加することによって、反対してください。 さらに、MIBモジュールがインスタンス識別情報が円柱状のオブジェクトのためにどう引き出されるかに関する原文の記述を含んでいないならINDEX節が存在していなければならないことに注意してください。
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) ストリングで評価されて、可変長のストリング: '+1 'サブ識別子、どこ、'ストリング('最初のサブ識別子はそうです、そして、これに続くストリングの各八重奏自体は別々のサブ識別子でコード化される)の長さはそうであるか。
(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) 識別子によって評価されていた状態で、反対してください: '+1 'サブ識別子、どこ、'値('最初のサブ識別子はそうです、そして、値におけるこれに続くそれぞれのサブ識別子自体はコピーされる)における、サブ識別子の数はそうであるか。
(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)はNetworkAddress評価しました: '+1 'サブ識別子、どこ、'コード化される(最初のサブ識別子はアドレスの種類を示して、値1はIpAddressを示します)アドレスの種類に依存します。 または
(6) IpAddress-valued: 4 sub-identifiers, in the familiar
a.b.c.d notation.
(6)はIpAddress評価しました: 4 身近な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よりむしろINTEGER)記述節が存在していなければならないことに注意してください。 そこに含まれたテキストは"indextype"価値の意味論を示します。
SNMP Working Group [Page 9] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[9ページ]RFC1212
By way of example, in the context of MIB-II [7], the following INDEX clauses might be present:
一例として、MIB-II[7]の文脈では、以下のINDEX節は存在しているかもしれません:
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 }
INDEX節の下におけるオブジェクト----------------- ------------ ifEntry ifIndex、atEntry、atNetIfIndex、atNetAddress、ipAddrEntry ipAdEntAddr、ipRouteEntry ipRouteDest、ipNetToMediaEntry、ipNetToMediaIfIndex、ipNetToMediaNetAddress、tcpConnEntry、tcpConnLocalAddress、tcpConnLocalPort、tcpConnRemoteAddress、tcpConnRemotePort、udpEntry、udpLocalAddress、udpLocalPort、egpNeighEntryegpNeighAddr
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節(存在している必要はない)はオブジェクトインスタンスが上の3番目のパラダイムがセクション4.2で説明されていた状態で順応で行動しているエージェントの裁量で作成されるとき使用されるかもしれない許容できるデフォルト値を定義します。
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.
概念的な行作成の間、存在していて、通信員SNMPのオペランドの1つが操作を設定したので円柱状のオブジェクトのインスタンスが存在していないなら、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節の値はもちろんオブジェクトのためのSYNTAX節に対応しなければなりません。 誤りnoSuchNameがSNMP集合演算へのオペランドが書き込み禁止オブジェクトのインスタンスであるなら返されることに注意してください。 そういうものとして、エージェントが使用するかもしれない許容できるデフォルト値を提供するのに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.
どんな許容できるデフォルト値も円柱状のオブジェクトのいずれのためにも新しいオブジェクトインスタンスの作成が許容されている概念的な行で存在しないのは、可能です。 この場合、INDEX節で指定されたオブジェクトは読書して書くことの対応するACCESS節価値を持たなければなりません。
SNMP Working Group [Page 10] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[10ページ]RFC1212
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
ObjectSyntax DEFVAL節----------------- ------------ INTEGER1--Counter、Gauge、TimeTicks OCTET STRING'ffffffffffff'h DisplayString「どんなNVT ASCIIストリングも」OBJECT IDENTIFIER sysDescr OBJECT IDENTIFIERシステム2NULL NULL NetworkAddressインターネット'c0210415'h IpAddress'c0210415'hのための同じこと--192.33.4、.21'
4.1.8. Mapping of the OBJECT-TYPE value
4.1.8. OBJECT-TYPE価値に関するマッピング
The value of an invocation of the OBJECT-TYPE macro is the name of the object, which is an object identifier.
OBJECT-TYPEマクロの実施の値はオブジェクトの名前です。(その名前はオブジェクト識別子です)。
4.2. Usage Example
4.2. 使用例
Consider how the ipNetToMediaTable from MIB-II might be fully described:
MIB-IIからのipNetToMediaTableがどのように完全に説明されるかもしれないか考えてください:
-- the IP Address Translation tables
-- IP Address Translationテーブル
-- 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を含むAddress Translation--「物理的な」アドレスの等価性。 いくつかのインタフェースはそうしません(例えば、DDN-X.25には、アルゴリズムのメソッドがあります)(アドレスの等価性を決定するのに変換テーブルを使用してください)。 インタフェースが次に、このタイプ、Address Translationのそうであるというすべてであるなら、テーブルはすなわち、空になることです。エントリーを全く持っていません。
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 }
「IP Address TranslationテーブルはアドレスをIPから物理アドレスに写像するのに使用した」ipNetToMediaTable OBJECT-TYPEのSYNTAX SEQUENCE OF IpNetToMediaEntry ACCESSのアクセスしやすくないSTATUS義務的な記述。 ::= ip22
ipNetToMediaEntry OBJECT-TYPE
SYNTAX IpNetToMediaEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Each entry contains one IpAddress to 'physical'
「各エントリーは1IpAddressを含む'ipNetToMediaEntry OBJECT-TYPE SYNTAX IpNetToMediaEntry ACCESSのアクセスしやすくないSTATUS義務的な記述、物理的である、'、」
SNMP Working Group [Page 11] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[11ページ]RFC1212
address equivalence."
INDEX { ipNetToMediaIfIndex,
ipNetToMediaNetAddress }
::= { ipNetToMediaTable 1 }
「等価性を扱ってください。」 ipNetToMediaIfIndex、ipNetToMediaNetAddressに索引をつけてください:、:= ipNetToMediaTable1
IpNetToMediaEntry ::=
SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
OCTET STRING,
ipNetToMediaNetAddress
IpAddress,
ipNetoToMediaType
INTEGER
}
IpNetToMediaEntry:、:= 系列ipNetToMediaIfIndex整数、ipNetToMediaPhysAddress八重奏ストリング、ipNetToMediaNetAddress IpAddress、ipNetoToMediaType整数
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."
::= { ipNetToMediaEntry 1 }
ipNetToMediaIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESSは「このエントリーの等価性が有効であるインタフェース」をSTATUSの義務的な記述に読書して書きます。 「このインデックスの特定の値によって特定されたインタフェースはifIndexの同じ値によって特定されるように同じインタフェースです。」 ::= ipNetToMediaEntry1
ipNetToMediaPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The media-dependent 'physical' address."
::= { ipNetToMediaEntry 2 }
ipNetToMediaPhysAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESSは「メディア依存する'物理的な'アドレス」をSTATUSの義務的な記述に読書して書きます。 ::= ipNetToMediaEntry2
ipNetToMediaNetAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The IpAddress corresponding to the media-
dependent 'physical' address."
::= { ipNetToMediaEntry 3 }
ipNetToMediaNetAddress OBJECT-TYPE SYNTAX IpAddress ACCESSは「メディア扶養家族にとって、対応するIpAddress'という義務的な記述物理的な'アドレス」をSTATUSに読書して書きます。 ::= ipNetToMediaEntry3
ipNetToMediaType OBJECT-TYPE
SYNTAX INTEGER {
ipNetToMediaTypeオブジェクト・タイプ構文整数
SNMP Working Group [Page 12] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[12ページ]RFC1212
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.
他の(1)--以下の病人(2)のだれも--でない無効にされたマッピング動力(3)、静電気(4) ACCESSは「マッピングのタイプ」をSTATUSの義務的な記述に読書して書きます。
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."
::= { ipNetToMediaEntry 4 }
値の病人(2)にこのオブジェクトを設定するのにおいて、ipNetToMediaTableで対応するエントリーを無効にするという効果があります。 事実上、すなわち、それは前述のエントリーと同一視されたマッピングから前述のエントリーと同一視されたインタフェースを分離します。 それはエージェントがテーブルから無効にされたエントリーを取り除くかどうかに関する実装特有の問題です。 それに従って、エージェントからの現在使用中でないエントリーに対応する表情報を受け取るように管理局を準備しなければなりません。 「そのようなエントリーの適切な解釈は関連ipNetToMediaTypeオブジェクトの試験を必要とします。」 ::= ipNetToMediaEntry4
5. Appendix: DE-osifying MIBs
5. 付録: 反-osifying MIBs
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.
他の組織(例えば、IEEE)によって定義されたMIBsを取って、使用のためにインターネット標準ネットワークマネージメントフレームワークで反-それらをosifyingするとき、最近、増加する量の仕事がありました。 これを達成するステップは、簡単であって、もっとも、退屈です。 もちろん、インターネット標準ネットワークマネージメントフレームワークで使用のためのモジュールをMIBに書く際に既に経験されるのは役立っています。
The first step is to construct a skeletal MIB module, e.g.,
第一歩は例えば骨格のMIBモジュールを構成することです。
RFC1213-MIB DEFINITIONS ::= BEGIN
RFC1213-MIB定義:、:= 始まってください。
IMPORTS
experimental, OBJECT-TYPE, Counter
FROM RFC1155-SMI;
IMPORTS実験的である、OBJECT-TYPE、Counter FROM RFC1155-SMI。
-- contact IANA for actual number
root OBJECT IDENTIFIER ::= { experimental xx }
-- 実数根のOBJECT IDENTIFIERのためにIANAに連絡してください:、:= 実験的なxx
END
終わり
SNMP Working Group [Page 13] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[13ページ]RFC1212
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.
次のステップはオブジェクトをグループに分類することです。 実験的なMIBsに関しては、任意のオブジェクトは受入れられます。 しかしながら、MIBモジュールがインターネット標準スペースに置かれるとき、これらの任意のオブジェクトは、任意のグループに移されるか、または置かれて、実装されるならどれがグループですべて反対するか実装しなければなりません。 最初のパスに関しては、単にオリジナルのMIBのどんな任意のオブジェクトも無視するのは最も賢明です: 不可欠のオブジェクトだけを含んでいて、経験は、最初にコアMIBモジュールを定義しているほうがよいのを示します。 その後、経験要求であるなら、他のオブジェクトを加えることができます。
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.
グループがMIBの中の「ユニットの順応」であると強調しなければなりません: グループにおけるすべてが「義務的です」、そして、実装は全体のグループかなにものどちらかしません。
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.
それぞれの管理オブジェクトのクラスに次であることで、その管理オブジェクトのクラスの複数のインスタンスが存在できるかどうか決定してください。 そうでなければ、そして、それぞれの属性には、同等な定義をするOBJECT-TYPEマクロを使用してください。
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.
さもなければ、管理オブジェクトのクラスの複数のインスタンスが存在できるなら、それぞれの管理オブジェクトのクラスsの属性のためにそれぞれ円柱状のオブジェクトを含む概念的な行を持っている概念的なテーブルを定義してください。 管理オブジェクトのクラスがもう1人の管理オブジェクトのクラスの封じ込め木の中に含まれているなら、通常、オブジェクト・タイプの課題がそれぞれの含んでいる管理オブジェクトのクラスの「顕著な属性」に必要です。 MIBモジュールの中に既に存在していないなら、含まれた管理オブジェクトのクラスに対応する概念的な行との追加円柱状のオブジェクトの定義でそれらを加えることができます。
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.
概念的な行を定義する際に、円柱状のオブジェクトに作用するネットワークマネージメント操作の最適化を考えるのは役に立ちます。 概念的な行の中で、より円柱状のオブジェクトを定義するのを避けるのは特に、最も賢明です、独身のPDUをうまくはめ込むことができるより。 原則として、親指では、概念的な行はおよそ20個未満のオブジェクトを含むべきです。 同様か「20オブジェクトガイドライン」を守る方法として、それらのネットワークマネージメント操作の予想された組分けによると、円柱状のオブジェクトはテーブルに分類されるべきです。 そういうものとして、概念的な行の内容は典型的なアクセスシナリオを反映するべきです、例えば、それらが統計のための1つの行やパラメタのための別の行などの機能的な系列に沿って、または、一般的に必要なオブジェクトなどの用法系列で対めったに必要でないオブジェクトに沿って組織化されるべきです。
On the other hand, the definition of conceptual rows where the number of columnar objects used as indexes outnumbers the number used to
他方では、インデックスとして使用される円柱状のオブジェクトの数が数に数でまさる概念的な行の定義は以前はよくそうしていました。
SNMP Working Group [Page 14] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[14ページ]RFC1212
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.
情報を保持してください、そして、また、避けられるべきです。 特に、そのままでMIBのところでしばしば選択科目の無数で見つけられた状態で同じ度合いの柔軟性/複雑さを得る方法として多くの概念的なテーブルへの管理オブジェクトのクラスsの属性の分かれることを使用するべきではありません。
5.1.1. Mapping to the SYNTAX clause
5.1.1. SYNTAX節へのマッピング
When mapping to the SYNTAX clause of the OBJECT-type macro:
OBJECT-タイプマクロのSYNTAX節に写像するとき:
(1) An object with BOOLEAN syntax becomes an INTEGER taking
either of values true(1) or false(2).
(1) ブール構文があるオブジェクトは値本当の(1)か誤った(2)のどちらかを取るINTEGERになります。
(2) An object with ENUMERATED syntax becomes an INTEGER,
taking any of the values given.
(2) 与えられた値のどれかで取って、ENUMERATED構文があるオブジェクトはINTEGERになります。
(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) BIT STRING構文が32ビット未満を含んでいるオブジェクトは合計と定義されたINTEGERになります。 さもなければ、32ビット以上が存在しているなら、オブジェクトはOCTET STRINGになります、左から右で付番されたビットで。そこでは、最後の八重奏の最下位ビットが「今後の使用のために、予約されるかもしれません」。
(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) 文字列構文があるオブジェクトはOCTET STRINGかDisplayStringのどちらかになります、文字列のレパートリーによって。
(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) レアルかEXTERNALなどの複雑な構文がある非表のオブジェクトを分解しなければなりません、通常OCTET STRINGに、ことです(分別があるなら)。 原則として、複雑な構文があるどんなオブジェクトも避けられるべきです。
(6) Tabular objects must be decomposed into rows of columnar
objects.
(6) 円柱状のオブジェクトの行に表オブジェクトを分解しなければなりません。
5.1.2. Mapping to the ACCESS clause
5.1.2. ACCESS節へのマッピング
This is straight-forward.
これは簡単です。
5.1.3. Mapping to the STATUS clause
5.1.3. STATUS節へのマッピング
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".
通常、これは簡単です。 しかしながら、いくつかのosified-MIBsが「お勧め」という用語を使用します。 この場合、「義務的で」「任意であること」の間で選択をしなければなりません。
5.1.4. Mapping to the DESCRIPTION clause
5.1.4. 記述節へのマッピング
This is straight-forward: simply copy the text, making sure that any
これは簡単です: 確実にそれをいずれにもして、単にテキストをコピーしてください。
SNMP Working Group [Page 15] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[15ページ]RFC1212
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. REFERENCE節へのマッピング
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. INDEX節へのマッピング
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. SYNTAX節へのマッピング
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.
通常、INTEGER構文はオブジェクトがアクセスを提供する各動作に提供する顕著な値と共に使用されます。 さらに、通常、他の1つの顕著な値があります。(それは、オブジェクトが読まれるとき返されたものです)。
5.2.2. Mapping to the ACCESS clause
5.2.2. ACCESS節へのマッピング
Always use read-write.
いつも使用は読書して書きます。
5.2.3. Mapping to the STATUS clause
5.2.3. STATUS節へのマッピング
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. REFERENCE節へのマッピング
This is straight-forward: simply include a textual reference to the
これは簡単です: 単に、原文の指示するものを含んでいます。
SNMP Working Group [Page 16] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[16ページ]RFC1212
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:
このドキュメントは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
Jim Kinder, Fibercom
Alex Koifman, BBN
Christopher Kolb, PSI
Cheryl Krupczak, NCR
Paul Langille, DEC
Peter Lin, Vitalink
John Lunny, TWG
アン・アンブラー、Spiderカール・アウアーバック、Sunのフレッド・ベイカー、ACCケンBrinkerhoff Ron Broersma、NOSCジャック・ブラウン、米国の陸軍のセオドア・ブルンナー、BellcoreジェフリーBuffum、HPジョン・バレス、WellfleetジェフリーD.Case、ノクスビルクリスChiptasso、スパルタカスポールCiarfella、12月のボブ・Colletション・クック、ChipcomトレーシーCox、Bellcoreのジェームス・R.デーヴィン、MIT-LCSエリックDecker、カート・ドビンズ、Cabletron Nadya El-Afandi、コクチマスNetwork Systemsゲーリー・エリス(HPフレッド・エングル・マイク・ErlingerマークS)のテネシー大学; ヒョードル、ψリチャードフォックス、SynopticsカレンFrisa、12月のフレッド・ハリス、ノクスビルケン・ヒバートのテネシー大学、Xylogics Oleジェイコブセン、Interopケン・ジョーンズ・サティシュ・ジョーシー、SynopticsフランクKastenholz、Racal-Interlan Shimshonコーフマン、スパルタカスケンKey、ノクスビルジム・キンダー、FibercomアレックスKoifman、BBNクリストファー・コールブ、ψシェリルKrupczak、NCRポールLangille、12月のピーター・リンVitalinkジョンLunny、TWGのテネシー大学の米カーネギーメロン大学のクリス砲手
SNMP Working Group [Page 17] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[17ページ]RFC1212
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
カール・マラマッド・ランディ・メイヒュー、ノクスビルキースMcCloghrie、ヒューズ・LAN Systemsドナ・マクマスター、デヴィッドSystemsリンモンサント、Sunのデーヴ・パーキンス、3COMジムReinstedler、Ungerman Bass Anil Rijsinghani、12月のキャシー・ラインハート、アーノルド・AFB Karyロバートソン・マーシャル・T.ローズ、PSI(いす)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、ψジェフ・ヤング、クレイリサーチ
7. References
7. 参照
[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
[3] ローズM.、およびK.McCloghrie、「構造と識別、」
SNMP Working Group [Page 18] RFC 1212 Concise MIB Definitions March 1991
1991年のMIB定義行進のときに簡潔なSNMP作業部会[18ページ]RFC1212
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
「TCP/IPベースのインターネットのための管理情報」、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月。
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
3106サンタクララ、マーシャルT.バラ言語運用機構国際5201グレート・アメリカ公園道路Suiteカリフォルニア 95054
Phone: +1 408 562 6222 EMail: mrose@psi.com X.500: rose, psi, us
以下に電話をしてください。 +1 6222年の408 562メール: mrose@psi.com X.500: バラ、psi、私たち
Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 1225 Charleston Road Mountain View, CA 94043
キースMcCloghrieヒューズLANシステム1225チャールストンRoadマウンテンビュー、カリフォルニア94043 1225チャールストンRoadマウンテンビュー、カリフォルニア 94043
Phone: (415) 966-7934 EMail: kzm@hls.com
以下に電話をしてください。 (415) 966-7934 メールしてください: kzm@hls.com
SNMP Working Group [Page 19]
SNMP作業部会[19ページ]
一覧
スポンサーリンク
