RFC1065 日本語訳
1065 Structure and identification of management information forTCP/IP-based internets. K. McCloghrie, M.T. Rose. August 1988. (Format: TXT=38858 bytes) (Obsoleted by RFC1155) (Status: STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Rose
Request for Comments: 1065 K. McCloghrie
TWG
August 1988
コメントを求めるワーキンググループM.バラ要求をネットワークでつないでください: 1065 K.McCloghrie TWG1988年8月
Structure and Identification of Management Information
for TCP/IP-based internets
TCP/IPベースのインターネットのためのManagement情報の構造とIdentification
Table of Contents
目次
1. Status of this Memo ............................................. 1 2. Introduction .................................................... 2 3. Structure and Identification of Management Information........... 4 3.1 Names .......................................................... 4 3.1.1 DIRECTORY .................................................... 5 3.1.2 MGMT ......................................................... 6 3.1.3 EXPERIMENTAL ................................................. 6 3.1.4 PRIVATE ...................................................... 7 3.2 Syntax ......................................................... 7 3.2.1 Primitive Types .............................................. 7 3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7 3.2.2 Constructor Types ............................................ 8 3.2.3 Defined Types ................................................ 8 3.2.3.1 NetworkAddress ............................................. 8 3.2.3.2 IpAddress .................................................. 8 3.2.3.3 Counter .................................................... 8 3.2.3.4 Gauge ...................................................... 9 3.2.3.5 TimeTicks .................................................. 9 3.2.3.6 Opaque ..................................................... 9 3.3 Encodings ...................................................... 9 4. Managed Objects ................................................. 10 4.1 Guidelines for Object Names .................................... 10 4.2 Object Types and Instances ..................................... 10 4.3 Macros for Managed Objects ..................................... 14 5. Extensions to the MIB ........................................... 16 6. Definitions ..................................................... 17 7. Acknowledgements ................................................ 20 8. References ...................................................... 21
1. このMemoの状態… 1 2. 序論… 2 3. 経営情報の構造と識別… 4 3.1 命名します。 4 3.1 .1ディレクトリ… 5 3.1 .2管理… 6 3.1 .3 実験的… 6 3.1 .4 個人的… 7 3.2構文… 7 3.2 .1 原始のタイプ… 7 3.2 .1 列挙された整数のための.1のガイドライン… 7 3.2 .2建設者はタイプします… 8 3.2 .3はタイプを定義しました… 8 3.2 .3 .1NetworkAddress… 8 3.2 .3 .2IpAddress… 8 3.2 .3 .3 反対してください… 8 3.2 .3 .4 測ります。 9 3.2 .3 .5TimeTicks… 9 3.2 .3 .6 不透明にします。 9 3.3Encodings… 9 4. 管理オブジェクト… 10 オブジェクト名のための4.1のガイドライン… 10 4.2のオブジェクト・タイプとインスタンス… 10 管理オブジェクトのための4.3のマクロ… 14 5. MIBへの拡大… 16 6. 定義… 17 7. 承認… 20 8. 参照… 21
1. Status of this Memo
1. このMemoの状態
This memo provides the common definitions for the structure and identification of management information for TCP/IP-based internets. In particular, together with its companion memos which describe the initial management information base along with the initial network management protocol, these documents provide a simple, workable
このメモはTCP/IPベースのインターネットのための経営情報の構造と識別のための一般的な定義を提供します。 初期のネットワーク管理プロトコルに伴う初期の管理情報ベースについて説明する仲間メモと共に特に、これらのドキュメントは簡単な状態でaを提供します、実行可能です。
Rose & McCloghrie [Page 1] RFC 1065 SMI August 1988
ローズとMcCloghrie[1ページ]RFC1065SMI1988年8月
architecture and system for managing TCP/IP-based internets and in particular, the Internet.
TCP/IPベースのインターネットと特にインターネットを管理するアーキテクチャとシステム。
This memo specifies a draft standard for the Internet community. TCP/IP implementations in the Internet which are network manageable are expected to adopt and implement this specification.
このメモはインターネットコミュニティの草稿規格を指定します。 インターネットのネットワーク処理しやすいTCP/IPインプリメンテーションは、この仕様を採用して、履行すると予想されます。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
2. Introduction
2. 序論
This memo describes the common structures and identification scheme for the definition of management information used in managing TCP/IP-based internets. Included are descriptions of an object information model for network management along with a set of generic types used to describe management information. Formal descriptions of the structure are given using Abstract Syntax Notation One (ASN.1) [1].
このメモはTCP/IPベースのインターネットを管理する際に使用される経営情報の定義の一般的な構造と識別体系について説明します。 含まれているのは、経営情報について説明するのに使用される1セットのジェネリックタイプに伴うネットワークマネージメントのためのオブジェクト情報モデルの記述です。 抽象的なSyntax Notation One(ASN.1)[1]を使用することで構造の形式的記述を与えます。
This memo is largely concerned with organizational concerns and administrative policy: it neither specifies the objects which are managed, nor the protocols used to manage those objects. These concerns are addressed by two companion memos: one describing the Management Information Base (MIB) [2], and the other describing the Simple Network Management Protocol (SNMP) [3].
このメモは組織的な関心と施政方針に主に関係があります: それはどちらも管理されるオブジェクト、およびそれらのオブジェクトを管理するのに使用されるプロトコルを指定しません。 これらの関心は2つの仲間メモで扱われます: Management Information基地(MIB)の[2]について説明する1つ、およびSimple Network Managementプロトコル(SNMP)[3]について説明する他。
This memo is based in part on the work of the Internet Engineering Task Force, particularly the working note titled "Structure and Identification of Management Information for the Internet" [4]. This memo uses a skeletal structure derived from that note, but differs in one very significant way:that note focuses entirely on the use of OSI-style network management. As such, it is not suitable for use in the short-term for which a non-OSI protocol, the SNMP, has been designated as the standard.
このメモはインターネット・エンジニアリング・タスク・フォース(特に「インターネットのための経営情報の構造と識別」[4]と題をつけられた働く注意)の仕事に一部基づいています。 このメモは、その注意から得られた骨格の構造を使用しますが、1つの非常に重要な方法において異なります: その注意はOSI-スタイルネットワークマネージメントの使用に完全に焦点を合わせます。 そういうものとして、それは非OSIプロトコル(SNMP)が規格として指定された短期的における使用に適していません。
This memo attempts to achieve two goals: simplicity and extensibility. Both are motivated by a common concern: although the management of TCP/IP-based internets has been a topic of study for some time, the authors do not feel that the depth and breadth of such understanding is complete. More bluntly, we feel that previous experiences, while giving the community insight, are hardly conclusive. By fostering a simple SMI, the minimal number of constraints are imposed on future potential approaches; further, by fostering an extensible SMI, the maximal number of potential approaches are available for experimentation.
このメモは、2つの目標を達成するのを試みます: 簡単さと伸展性。 両方が共通の関心事によって動機づけられています: しばらくTCP/IPベースのインターネットの管理は研究の話題ですが、作者は、そのような理解の深さと幅が完全であると感じません。 よりつっけんどんに、私たちは、以前の経験が共同体洞察を与えている間ほとんど決定的でないと感じます。 簡単なSMIを伸ばすことによって、規制の最小量の数は今後のポテンシャル法に課されます。 さらに、広げることができるSMIを伸ばすことによって、ポテンシャル法の最大限度の数は実験に有効です。
It is believed that this memo and its two companions comply with the guidelines set forth in RFC 1052, "IAB Recommendations for the
このメモとその2人の仲間がRFC1052に詳しく説明されるガイドラインに応じると信じられている、「IAB推薦、」
Rose & McCloghrie [Page 2] RFC 1065 SMI August 1988
ローズとMcCloghrie[2ページ]RFC1065SMI1988年8月
Development of Internet Network Management Standards" [5]. In particular, we feel that this memo, along with the memo describing the initial management information base, provide a solid basis for network management of the Internet.
「インターネットネットワークマネージメント規格の開発」[5]。 特に、私たちは、このメモが初期の管理情報ベースについて説明するメモと共にインターネットのネットワークマネージメントのしっかりした基礎を提供すると感じます。
Rose & McCloghrie [Page 3] RFC 1065 SMI August 1988
ローズとMcCloghrie[3ページ]RFC1065SMI1988年8月
3. Structure and Identification of Management Information
3. 経営情報の構造と識別
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using Abstract Syntax Notation One (ASN.1) [1].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、抽象的なSyntax Notation One(ASN.1)[1]を使用することで定義されます。
Each type of object (termed an object type) has a name, a syntax, and an encoding. The name is represented uniquely as an OBJECT IDENTIFIER. An OBJECT IDENTIFIER is an administratively assigned name. The administrative policies used for assigning names are discussed later in this memo.
それぞれのタイプのオブジェクト(オブジェクト・タイプと呼ばれる)には、名前、構文、およびコード化があります。 存在という名前は唯一OBJECT IDENTIFIERを表しました。 OBJECT IDENTIFIERは行政上割り当てられた名前です。 後でこのメモで名前を割り当てるのに使用される施政方針について議論します。
The syntax for an object type defines the abstract data structure corresponding to that object type. For example, the structure of a given object type might be an INTEGER or OCTET STRING. Although in general, we should permit any ASN.1 construct to be available for use in defining the syntax of an object type, this memo purposely restricts the ASN.1 constructs which may be used. These restrictions are made solely for the sake of simplicity.
オブジェクト・タイプのための構文はそのオブジェクト・タイプにとって、対応する抽象的なデータ構造を定義します。 例えば、与えられたオブジェクト・タイプの構造は、INTEGERかOCTET STRINGであるかもしれません。 私たちは、どんなASN.1構造物もオブジェクト・タイプの構文を定義することにおける使用に利用可能であることを一般に許可するべきですが、このメモはわざわざ使用されるかもしれないASN.1構造物を制限します。 唯一簡単にするためにこれらの制限をします。
The encoding of an object type is simply how instances of that object type are represented using the object's type syntax. Implicitly tied to the notion of an object's syntax and encoding is how the object is represented when being transmitted on the network. This memo specifies the use of the basic encoding rules of ASN.1 [6].
オブジェクト・タイプのコード化は単にそのオブジェクト・タイプのインスタンスがオブジェクトのタイプ構文を使用することでどう表されるかということです。 それとなくオブジェクトの構文とコード化の概念に結ばれているのは、ネットワークで伝えられるとオブジェクトがどう表されるかということです。 このメモはASN.1[6]の基本的な符号化規則の使用を指定します。
It is beyond the scope of this memo to define either the initial MIB used for network management or the network management protocol. As mentioned earlier, these tasks are left to the companion memos. This memo attempts to minimize the restrictions placed upon its companions so as to maximize generality. However, in some cases, restrictions have been made (e.g., the syntax which may be used when defining object types in the MIB) in order to encourage a particular style of management. Future editions of this memo may remove these restrictions.
それは、ネットワークマネージメントに使用される初期のMIBかネットワーク管理プロトコルのどちらかを定義するためにこのメモの範囲を超えています。 先に述べたように、これらのタスクは仲間メモに残されます。 このメモは、一般性を最大にするために仲間に置かれた制限を最小にするのを試みます。 しかしながら、いくつかの場合、特定のスタイルの管理を奨励するために制限をしました(例えばMIBでオブジェクト・タイプを定義するとき使用されるかもしれない構文)。 このメモの将来の版はこれらの制限を取り除くかもしれません。
3.1. Names
3.1. 名前
Names are used to identify managed objects. This memo specifies names which are hierarchical in nature. The OBJECT IDENTIFIER concept is used to model this notion. An OBJECT IDENTIFIER can be used for purposes other than naming managed object types; for example, each international standard has an OBJECT IDENTIFIER assigned to it for the purposes of identification. In short, OBJECT IDENTIFIERs are a means for identifying some object, regardless of the semantics associated with the object (e.g., a network object, a standards document, etc.)
名前は、管理オブジェクトを特定するのに使用されます。 このメモは現実に階層的な名前を指定します。 OBJECT IDENTIFIER概念は、この概念をモデル化するのに使用されます。 管理オブジェクトタイプを命名するのを除いた目的にOBJECT IDENTIFIERを使用できます。 例えば、各世界規格で、識別の目的のためにOBJECT IDENTIFIERをそれに割り当てます。 要するに、OBJECT IDENTIFIERsは、オブジェクトに関連している意味論にかかわらず、あるオブジェクトを特定するための手段です。(例えば、ネットワークオブジェクト、規格文書など)
Rose & McCloghrie [Page 4] RFC 1065 SMI August 1988
ローズとMcCloghrie[4ページ]RFC1065SMI1988年8月
An OBJECT IDENTIFIER is a sequence of integers which traverse a global tree. The tree consists of a root connected to a number of labeled nodes via edges. Each node may, in turn, have children of its own which are labeled. In this case, we may term the node a subtree. This process may continue to an arbitrary level of depth. Central to the notion of the OBJECT IDENTIFIER is the understanding that administrative control of the meanings assigned to the nodes may be delegated as one traverses the tree. A label is a pairing of a brief textual description and an integer.
OBJECT IDENTIFIERはグローバルな木を横断する整数の系列です。 木は縁を通って多くのラベルされたノードに接続された根から成ります。 各ノードには、それ自身の子供が順番にいるかもしれません(ラベルされます)。 この場合私たちがそうするかもしれない、用語、ノードa下位木。 このプロセスは任意のレベルの深さへ持続するかもしれません。 OBJECT IDENTIFIERの概念に主要であるのは、1つが木を横断するときノードに割り当てられた意味の運営管理コントロールを代表として派遣するかもしれないという理解です。 ラベルは簡潔な原文の記述と整数の組み合わせです。
The root node itself is unlabeled, but has at least three children directly under it: one node is administered by the International Standards Organization, with label iso(1); another is administrated by the International Telegraph and Telephone Consultative Committee, with label ccitt(2); and the third is jointly administered by the ISO and the CCITT, joint-iso-ccitt(3).
根のノード自体には、ラベルされていないのですが、少なくとも3人の子供がそれの直接下にいます: 1つのノードがラベルiso(1)で国際Standards Organizationによって管理されます。 別のものはラベルccitt(2)で国際電信電話諮問委員会によって管理されます。 そして、3番目はISOとCCITT、共同iso-ccitt(3)によって共同で管理されます。
Under the iso(1) node, the ISO has designated one subtree for use by other (inter)national organizations, org(3). Of the children nodes present, two have been assigned to the U.S. National Bureau of Standards. One of these subtrees has been transferred by the NBS to the U.S. Department of Defense, dod(6).
iso(1)ノードの下では、ISOは他の(間)の全国的な組織、org(3)による使用のために1つの指定された下位木を持っています。 ノードが紹介する子供では、2は米国規格基準局に配属されました。 これらの下位木の1つはNBSによって米国国防総省、dod(6)に移されました。
As of this writing, the DoD has not indicated how it will manage its subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will allocate a node to the Internet community, to be administered by the Internet Activities Board (IAB) as follows:
この書くこと現在、DoDはそれがどうOBJECT IDENTIFIERsの下位木を管理するかを示していません。 このメモは、以下のインターネットActivities Board(IAB)によって管理されるようにDoDがノードをインターネットコミュニティに割り当てると仮定します:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
インターネットOBJECT IDENTIFIER:、:= iso org(3) dod(6)1
That is, the Internet subtree of OBJECT IDENTIFIERs starts with the prefix:
すなわち、OBJECT IDENTIFIERsのインターネット下位木は接頭語から始まります:
1.3.6.1.
1.3.6.1.
This memo, as an RFC approved by the IAB, now specifies the policy under which this subtree of OBJECT IDENTIFIERs is administered. Initially, four nodes are present:
RFCがIABで承認したので、このメモは現在、OBJECT IDENTIFIERsのこの下位木が管理される方針を指定します。 初めは、4つのノードが存在しています:
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
ディレクトリOBJECT IDENTIFIER:、:= インターネット1管理OBJECT IDENTIFIER:、:= インターネット2の実験的なOBJECT IDENTIFIER:、:= インターネット3の個人的なOBJECT IDENTIFIER:、:= インターネット4
3.1.1. DIRECTORY
3.1.1. ディレクトリ
The directory(1) subtree is reserved for use with a future memo that discusses how the OSI Directory may be used in the Internet.
ディレクトリ(1)下位木はOSIディレクトリがインターネットでどう使用されるかもしれないかについて議論する将来のメモによる使用のために予約されます。
Rose & McCloghrie [Page 5] RFC 1065 SMI August 1988
ローズとMcCloghrie[5ページ]RFC1065SMI1988年8月
3.1.2. MGMT
3.1.2. 管理
The mgmt(2) subtree is used to identify objects which are defined in IAB-approved documents. Administration of the mgmt(2) subtree is delegated by the IAB to the Assigned Numbers authority for the Internet. As RFCs which define new versions of the Internet-standard Management Information Base are approved, they are assigned an OBJECT IDENTIFIER by the Assigned Numbers authority for identifying the objects defined by that memo.
管理(2)下位木は、IABによって承認されたドキュメントで定義されるオブジェクトを特定するのに使用されます。 管理(2)下位木の政権はインターネットのためにIABによってAssigned民数記権威へ代表として派遣されます。 インターネット標準Management Information基地の新しいバージョンを定義するRFCsが承認されているので、OBJECT IDENTIFIERはそのメモで定義されたオブジェクトを特定するためにAssigned民数記権威によってそれらに割り当てられます。
For example, the RFC which defines the initial Internet standard MIB would be assigned management document number 1. This RFC would use the OBJECT IDENTIFIER
例えば、管理公文書番号1は初期のインターネット標準MIBを定義するRFCに割り当てられるでしょう。 このRFCはOBJECT IDENTIFIERを使用するでしょう。
{ mgmt 1 }
管理1
or
または
1.3.6.1.2.1
1.3.6.1.2.1
in defining the Internet-standard MIB.
インターネット標準MIBを定義する際に。
The generation of new versions of the Internet-standard MIB is a rigorous process. Section 5 of this memo describes the rules used when a new version is defined.
インターネット標準MIBの新しいバージョンの世代は厳しいプロセスです。 このメモのセクション5は新しいバージョンが定義されるとき使用される規則について説明します。
3.1.3. EXPERIMENTAL
3.1.3. 実験的
The experimental(3) subtree is used to identify objects used in Internet experiments. Administration of the experimental(3) subtree is delegated by the IAB to the Assigned Numbers authority of the Internet.
実験(3)下位木は、インターネット実験に使用されるオブジェクトを特定するのに使用されます。 実験(3)下位木の政権はIABによってインターネットのAssigned民数記権威へ代表として派遣されます。
For example, an experimenter might received number 17, and would have available the OBJECT IDENTIFIER
例えば、実験者力がNo.17を受け取って、利用可能な状態で受け取っただろう、OBJECT IDENTIFIER
{ experimental 17 }
実験的な17
or
または
1.3.6.1.3.17
1.3.6.1.3.17
for use.
使用のために。
As a part of the assignment process, the Assigned Numbers authority may make requirements as to how that subtree is used.
課題プロセスの一部として、その下位木がどう使用されているかに関してAssigned民数記権威は要件を作るかもしれません。
Rose & McCloghrie [Page 6] RFC 1065 SMI August 1988
ローズとMcCloghrie[6ページ]RFC1065SMI1988年8月
3.1.4. PRIVATE
3.1.4. 個人的
The private(4) subtree is used to identify objects defined unilaterally. Administration of the private(4) subtree is delegated by the IAB to the Assigned Numbers authority for the Internet. Initially, this subtree has at least one child:
個人的な(4)下位木は、一方的に定義されたオブジェクトを特定するのに使用されます。 個人的な(4)下位木の政権はインターネットのためにIABによってAssigned民数記権威へ代表として派遣されます。 初めは、この下位木には、少なくとも1人の子供がいます:
enterprises OBJECT IDENTIFIER ::= { private 1 }
企業OBJECT IDENTIFIER:、:= 個人的な1
The enterprises(1) subtree is used, among other things, to permit parties providing networking subsystems to register models of their products.
企業(1)下位木は、ネットワークサブシステムを提供するパーティーが彼らの製品のモデルを登録することを許可するのに特に使用されます。
Upon receiving a subtree, the enterprise may, for example, define new MIB objects in this subtree. In addition, it is strongly recommended that the enterprise will also register its networking subsystems under this subtree, in order to provide an unambiguous identification mechanism for use in management protocols. For example, if the "Flintstones, Inc." enterprise produced networking subsystems, then they could request a node under the enterprises subtree from the Assigned Numbers authority. Such a node might be numbered:
下位木を受けると、例えば、企業はこの下位木で新しいMIBオブジェクトを定義するかもしれません。 さらに、また、企業がこの下位木の下でネットワークサブシステムを登録することが強く勧められます、明確な同定メカニズムを管理プロトコルにおける使用に提供するために。 例えば、「フリントストーンInc.」企業がネットワークサブシステムを作成するなら、それらはAssigned民数記権威から企業下位木の下でノードを要求するかもしれないでしょうに。 そのようなノードは付番されるかもしれません:
1.3.6.1.4.1.42
1.3.6.1.4.1.42
The "Flintstones, Inc." enterprise might then register their "Fred Router" under the name of:
そして、「フリントストーンInc.」企業は以下という名でそれらの「フレッドRouter」を登録するかもしれません。
1.3.6.1.4.1.42.1.1
1.3.6.1.4.1.42.1.1
3.2. Syntax
3.2. 構文
Syntax is used to define the structure corresponding to object types. ASN.1 constructs are used to define this structure, although the full generality of ASN.1 is not permitted.
構文は、オブジェクト・タイプにとって、対応する構造を定義するのに使用されます。 ASN.1の完全な一般性は受入れられませんが、ASN.1構造物は、この構造を定義するのに使用されます。
The ASN.1 type ObjectSyntax defines the different syntaxes which may be used in defining an object type.
ASN.1タイプObjectSyntaxはオブジェクト・タイプを定義する際に使用されるかもしれない異なった構文を定義します。
3.2.1. Primitive Types
3.2.1. プリミティブ型
Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT IDENTIFIER, and NULL are permitted. These are sometimes referred to as non-aggregate types.
ASN.1プリミティブ型だけのINTEGER、OCTET STRING、OBJECT IDENTIFIER、およびNULLは受入れられます。 これらは時々非集成型と呼ばれます。
3.2.1.1. Guidelines for Enumerated INTEGERs
3.2.1.1. 列挙された整数のためのガイドライン
If an enumerated INTEGER is listed as an object type, then a named- number having the value 0 shall not be present in the list of
列挙されたINTEGERとして記載されるなら、オブジェクトはタイプされます、aが値0を持っているのが存在していない数をリストと命名したその時
Rose & McCloghrie [Page 7] RFC 1065 SMI August 1988
ローズとMcCloghrie[7ページ]RFC1065SMI1988年8月
enumerations. Use of this value is prohibited.
列挙。 この値の使用は禁止されています。
3.2.2. Constructor Types
3.2.2. 建設者タイプ
The ASN.1 constructor type SEQUENCE is permitted, providing that it is used to generate either lists or tables.
それがリストかテーブルのどちらかを生成するのに使用されるなら、ASN.1建設者タイプSEQUENCEは受入れられます。
For lists, the syntax takes the form:
繰返し要素の並びであり、構文は形を取ります:
SEQUENCE { <type1>, ..., <typeN> }
系列<type1>、…、<typeN>。
where each <type> resolves to one of the ASN.1 primitive types listed above. Further, these ASN.1 types are always present (the DEFAULT and OPTIONAL clauses do not appear in the SEQUENCE definition).
それぞれの<タイプ>が、決議するところでは、ASN.1プリミティブ型のひとりは上に記載しました。 さらに、これらのASN.1タイプはいつも出席しています(DEFAULTとOPTIONAL節はSEQUENCE定義に現れません)。
For tables, the syntax takes the form:
テーブルのために、構文は形を取ります:
SEQUENCE OF <entry>
<エントリー>の系列
where <entry> resolves to a list constructor.
<エントリー>がリストに建設者を決議するところ。
Lists and tables are sometimes referred to as aggregate types.
リストとテーブルは時々集成型と呼ばれます。
3.2.3. Defined Types
3.2.3. 定義されたタイプ
In addition, new application-wide types may be defined, so long as they resolve into an IMPLICITly defined ASN.1 primitive type, list, table, or some other application-wide type. Initially, few application-wide types are defined. Future memos will no doubt define others once a consensus is reached.
さらに、新しいアプリケーション全体のタイプは定義されるかもしれません、彼らが定義されたASN.1プリミティブ型、リスト、テーブル、またはある他のアプリケーション全体のタイプにIMPLICITlyに変える限り。 初めは、わずかなアプリケーション全体のタイプしか定義されません。 コンセンサスにいったん達していると、将来のメモは間違いなく他のものを定義するでしょう。
3.2.3.1. NetworkAddress
3.2.3.1. NetworkAddress
This CHOICE represents an address from one of possibly several protocol families. Currently, only one protocol family, the Internet family, is present in this CHOICE.
このCHOICEはことによるといくつかのプロトコルファミリーのひとりからアドレスを表します。 現在、1つのプロトコルファミリー(インターネットファミリー)だけがこのCHOICEに出席しています。
3.2.3.2. IpAddress
3.2.3.2. IpAddress
This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order.
このアプリケーション全体のタイプは32ビットのインターネットアドレスを表します。 それはネットワークバイトオーダーにおける長さ4のOCTET STRINGとして表されます。
When this ASN.1 type is encoded using the ASN.1 basic encoding rules, only the primitive encoding form shall be used.
このASN.1タイプがASN.1の基本的な符号化規則を使用することでコード化されるとき、原始のコード化フォームだけが使用されるものとします。
3.2.3.3. Counter
3.2.3.3. カウンタ
This application-wide type represents a non-negative integer which
このアプリケーション全体のタイプは非負の整数にどれを表すか。
Rose & McCloghrie [Page 8] RFC 1065 SMI August 1988
ローズとMcCloghrie[8ページ]RFC1065SMI1988年8月
monotonically increases until it reaches a maximum value, when it wraps around and starts increasing again from zero. This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for counters.
単調に巻きつけるとき、最大値に達して、再びゼロから増え始めるまで増加します。 このメモは2^32-1の最大値(4294967295小数)をカウンタに指定します。
3.2.3.4. Gauge
3.2.3.4. ゲージ
This application-wide type represents a non-negative integer, which may increase or decrease, but which latches at a maximum value. This memo specifies a maximum value of 2^32-1 (4294967295 decimal) for gauges.
このアプリケーション全体のタイプは非負の整数を表します。(増減するかもしれませんが、それは、最大値で掛け金をおろします)。 このメモは2^32-1の最大値(4294967295小数)をゲージに指定します。
3.2.3.5. TimeTicks
3.2.3.5. TimeTicks
This application-wide type represents a non-negative integer which counts the time in hundredths of a second since some epoch. When object types are defined in the MIB which use this ASN.1 type, the description of the object type identifies the reference epoch.
このアプリケーション全体のタイプはいつかの時代以来の1秒の100分の1で時間を数える非負の整数を表します。 オブジェクト・タイプがこのASN.1タイプを使用するMIBで定義されるとき、オブジェクト・タイプの記述は参照時代を特定します。
3.2.3.6. Opaque
3.2.3.6. 不透明なもの
This application-wide type supports the capability to pass arbitrary ASN.1 syntax. A value is encoded using the ASN.1 basic rules into a string of octets. This, in turn, is encoded as an OCTET STRING, in effect "double-wrapping" the original ASN.1 value.
このアプリケーション全体のタイプは任意のASN.1構文を通過する能力をサポートします。 値は、ASN.1基本的なルールを一連の八重奏に使用することでコード化されます。 事実上、元のASN.1価値を「ダブルで包装し」て、これはOCTET STRINGとして順番にコード化されます。
Note that a conforming implementation need only be able to accept and recognize opaquely-encoded data. It need not be able to unwrap the data and then interpret its contents.
従う実装が不透明にコード化されたデータを受け入れて、認識できるだけでよいことに注意してください。 それは、データを開けて、次に、コンテンツを解釈できる必要はありません。
Further note that by use of the ASN.1 EXTERNAL type, encodings other than ASN.1 may be used in opaquely-encoded data.
ASN.1EXTERNALタイプの使用で、ASN.1以外のencodingsが不透明にコード化されたデータで使用されるかもしれないことにさらに注意してください。
3.3. Encodings
3.3. Encodings
Once an instance of an object type has been identified, its value may be transmitted by applying the basic encoding rules of ASN.1 to the syntax for the object type.
オブジェクト・タイプのインスタンスがいったん特定されると、値は、オブジェクト・タイプのためにASN.1の基本的な符号化規則を構文に適用することによって、送られるかもしれません。
Rose & McCloghrie [Page 9] RFC 1065 SMI August 1988
ローズとMcCloghrie[9ページ]RFC1065SMI1988年8月
4. Managed Objects
4. 管理オブジェクト
Although it is not the purpose of this memo to define objects in the MIB, this memo specifies a format to be used by other memos which define these objects.
MIBでオブジェクトを定義するのが、このメモの目的ではありませんが、このメモは、これらのオブジェクトを定義する他のメモで使用されるために形式を指定します。
An object type definition consists of five fields:
オブジェクト型定義は5つの分野から成ります:
OBJECT:
-------
A textual name, termed the OBJECT DESCRIPTOR, for the object type,
along with its corresponding OBJECT IDENTIFIER.
オブジェクト: ------- 対応するOBJECT IDENTIFIERに伴うオブジェクト・タイプのためにOBJECT DESCRIPTORと呼ばれた原文の名前。
Syntax:
The abstract syntax for the object type. This must resolve to an
instance of the ASN.1 type ObjectSyntax (defined below).
構文: オブジェクト・タイプのための抽象構文。 これはタイプObjectSyntax(以下では、定義される)をASN.1のインスタンスに決議しなければなりません。
Definition:
A textual description of the semantics of the object type.
Implementations should ensure that their instance of the object
fulfills this definition since this MIB is intended for use in
multi-vendor environments. As such it is vital that objects have
consistent meaning across all machines.
定義: オブジェクト・タイプの意味論の原文の記述。 実装は、このMIBがマルチベンダ環境における使用のために意図するのでそれらのオブジェクトのインスタンスがこの定義を実現させるのを確実にするべきです。 そういうものとして、オブジェクトがすべてのマシンの向こう側に一貫した意味を持っているのは、重大です。
Access:
One of read-only, read-write, write-only, or not-accessible.
アクセス: 1つ、-読まれて、書き込み禁止では、書いてください、書く、-単に、アクセスしやすくはありません。
Status:
One of mandatory, optional, or obsolete.
状態: 1つ、義務的であるか、任意であるか、または時代遅れです。
Future memos may also specify other fields for the objects which they define.
また、将来のメモはそれらが定義するオブジェクトに他の分野を指定するかもしれません。
4.1. Guidelines for Object Names
4.1. オブジェクト名のためのガイドライン
No object type in the Internet-Standard MIB shall use a sub- identifier of 0 in its name. This value is reserved for use with future extensions.
インターネット標準のMIBでどんなオブジェクト・タイプも名前に0に関するサブ識別子を使用しないものとします。 この値は使用のために今後の拡大で予約されます。
Each OBJECT DESCRIPTOR corresponding to an object type in the internet-standard MIB shall be a unique, but mnemonic, printable string. This promotes a common language for humans to use when discussing the MIB and also facilitates simple table mappings for user interfaces.
インターネット標準のMIBのオブジェクト・タイプにとって、対応するそれぞれのOBJECT DESCRIPTORはしかし、ユニークで、簡略記憶の、そして、印刷可能なストリングになるでしょう。 これは、MIBについて議論するとき人間が使用する共通語を促進して、また、ユーザインタフェースのための単純分類表マッピングを容易にします。
4.2. Object Types and Instances
4.2. オブジェクト・タイプとインスタンス
An object type is a definition of a kind of managed object; it is
オブジェクト・タイプは一種の管理オブジェクトの定義です。 それはそうです。
Rose & McCloghrie [Page 10] RFC 1065 SMI August 1988
ローズとMcCloghrie[10ページ]RFC1065SMI1988年8月
declarative in nature. In contrast, an object instance is an instantiation of an object type which has been bound to a value. For example, the notion of an entry in a routing table might be defined in the MIB. Such a notion corresponds to an object type; individual entries in a particular routing table which exist at some time are object instances of that object type.
現実に宣言的です。 対照的に、オブジェクトインスタンスは値に縛られたオブジェクト・タイプの具体化です。 例えば、経路指定テーブルのエントリーの概念はMIBで定義されるかもしれません。 そのような概念はオブジェクト・タイプに文通されます。 特定の経路指定テーブルのいつか存在する個人出場者はそのオブジェクト・タイプのオブジェクトインスタンスです。
A collection of object types is defined in the MIB. Each such subject type is uniquely named by its OBJECT IDENTIFIER and also has a textual name, which is its OBJECT DESCRIPTOR. The means whereby object instances are referenced is not defined in the MIB. Reference to object instances is achieved by a protocol-specific mechanism: it is the responsibility of each management protocol adhering to the SMI to define this mechanism.
オブジェクト・タイプの収集はMIBで定義されます。 そのようなそれぞれの対象のタイプは、OBJECT IDENTIFIERによって唯一挙げられて、また、原文の名前を持っています。(それは、そのOBJECT DESCRIPTORです)。 オブジェクトインスタンスが参照をつけられる手段はMIBで定義されません。 オブジェクトインスタンスの参照はプロトコル特有のメカニズムによって達成されます: このメカニズムを定義するのは、各管理プロトコルがSMIを固く守る責任です。
An object type may be defined in the MIB such that an instance of that object type represents an aggregation of information also represented by instances of some number of "subordinate" object types. For example, suppose the following object types are defined in the MIB:
オブジェクト・タイプがMIBで定義されるかもしれないので、そのオブジェクト・タイプのインスタンスはまた、何らかの数の「下位」のオブジェクト・タイプのインスタンスによって表された情報の集合を表します。 例えば、以下のオブジェクト・タイプがMIBで定義されると仮定してください:
OBJECT:
-------
atIndex { atEntry 1 }
オブジェクト: ------- atIndexatEntry1
Syntax:
INTEGER
構文: 整数
Definition:
The interface number for the physical address.
定義: 物理アドレスのインタフェース番号。
Access:
read-write.
アクセス: -読まれて、書いてください。
Status:
mandatory.
状態: 義務的。
OBJECT:
-------
atPhysAddress { atEntry 2 }
オブジェクト: ------- atPhysAddressatEntry2
Syntax:
OCTET STRING
構文: 八重奏ストリング
Definition:
The media-dependent physical address.
定義: メディア依存する物理アドレス。
Rose & McCloghrie [Page 11] RFC 1065 SMI August 1988
ローズとMcCloghrie[11ページ]RFC1065SMI1988年8月
Access:
read-write.
アクセス: -読まれて、書いてください。
Status:
mandatory.
状態: 義務的。
OBJECT:
-------
atNetAddress { atEntry 3 }
オブジェクト: ------- atNetAddressatEntry3
Syntax:
NetworkAddress
構文: NetworkAddress
Definition:
The network address corresponding to the media-dependent physical
address.
定義: メディア依存する物理アドレスに対応するネットワーク・アドレス。
Access:
read-write.
アクセス: -読まれて、書いてください。
Status:
mandatory.
状態: 義務的。
Then, a fourth object type might also be defined in the MIB:
次に、また、4番目のオブジェクト・タイプはMIBで定義されるかもしれません:
OBJECT:
-------
atEntry { atTable 1 }
オブジェクト: ------- atEntryatTable1
Syntax:
構文:
AtEntry ::= SEQUENCE {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}
AtEntry:、:= 系列atIndex整数、atPhysAddress八重奏ストリング、atNetAddress NetworkAddress
Definition:
An entry in the address translation table.
定義: アドレス変換テーブルにおけるエントリー。
Access:
read-write.
アクセス: -読まれて、書いてください。
Rose & McCloghrie [Page 12] RFC 1065 SMI August 1988
ローズとMcCloghrie[12ページ]RFC1065SMI1988年8月
Status:
mandatory.
状態: 義務的。
Each instance of this object type comprises information represented by instances of the former three object types. An object type defined in this way is called a list.
このオブジェクト・タイプの各インスタンスは元3人のオブジェクト・タイプのインスタンスによって表された情報を包括します。 このように定義されたオブジェクト・タイプはリストと呼ばれます。
Similarly, tables can be formed by aggregations of a list type. For example, a fifth object type might also be defined in the MIB:
同様に、リストタイプの集合でテーブルを形成できます。 例えば、また、5番目のオブジェクト・タイプはMIBで定義されるかもしれません:
OBJECT:
------
atTable { at 1 }
オブジェクト: ------ atTable1
Syntax:
SEQUENCE OF AtEntry
構文: AtEntryの系列
Definition:
The address translation table.
定義: アドレス変換テーブル。
Access:
read-write.
アクセス: -読まれて、書いてください。
Status:
mandatory.
状態: 義務的。
such that each instance of the atTable object comprises information represented by the set of atEntry object types that collectively constitute a given atTable object instance, that is, a given address translation table.
atTableオブジェクトの各インスタンスが与えられたatTableオブジェクトインスタンス、すなわち、与えられたアドレス変換テーブルをまとめて構成するatEntryオブジェクト・タイプのセットによって表された情報を包括するように。
Consider how one might refer to a simple object within a table. Continuing with the previous example, one might name the object type
テーブルの中で人がどのように簡単なオブジェクトについて言及するかもしれないか考えてください。 前の例を続行して、人はオブジェクト・タイプを命名するかもしれません。
{ atPhysAddress }
atPhysAddress
and specify, using a protocol-specific mechanism, the object instance
そして、プロトコル特有のメカニズム、オブジェクトインスタンスを使用して、指定してください。
{ atNetAddress } = { internet "10.0.0.52" }
atNetAddressは等しいです。インターネット、「10.0、.0、0.52インチ、」
This pairing of object type and object instance would refer to all
instances of atPhysAddress which are part of any entry in some
address translation table for which the associated atNetAddress value
is { internet "10.0.0.52" }.
オブジェクト・タイプとオブジェクトインスタンスのこの組み合わせが関連atNetAddress値がそうである何らかのアドレス変換テーブルにおけるどんなエントリーの一部であるatPhysAddressのすべてのインスタンスについても言及するだろう、インターネット、「10.0、.0、0.52インチ、」
To continue with this example, consider how one might refer to an aggregate object (list) within a table. Naming the object type
この例を続行するには、テーブルの中で人がどのように集団オブジェクト(リスト)について言及するかもしれないか考えてください。 オブジェクト・タイプを命名します。
Rose & McCloghrie [Page 13] RFC 1065 SMI August 1988
ローズとMcCloghrie[13ページ]RFC1065SMI1988年8月
{ atEntry }
atEntry
and specifying, using a protocol-specific mechanism, the object instance
そして、プロトコル特有のメカニズム、オブジェクトインスタンスを使用して、指定すること。
{ atNetAddress } = { internet "10.0.0.52" }
atNetAddressは等しいです。インターネット、「10.0、.0、0.52インチ、」
refers to all instances of entries in the table for which the
associated atNetAddress value is { internet "10.0.0.52" }.
関連atNetAddress値がそうであるテーブルのエントリーのすべてのインスタンスについて言及する、インターネット、「10.0、.0、0.52インチ、」
Each management protocol must provide a mechanism for accessing simple (non-aggregate) object types. Each management protocol specifies whether or not it supports access to aggregate object types. Further, the protocol must specify which instances are "returned" when an object type/instance pairing refers to more than one instance of a type.
各管理プロトコルは純真な(非集合の)オブジェクト・タイプにアクセスするのにメカニズムを提供しなければなりません。 各管理プロトコルは、それがオブジェクト・タイプに集めるためにアクセスをサポートするかどうか指定します。 さらに、プロトコルは、オブジェクト・タイプ/インスタンス組み合わせがタイプの1つ以上のインスタンスについて言及するとき、どのインスタンスが「返されるか」を指定しなければなりません。
To afford support for a variety of management protocols, all information by which instances of a given object type may be usefully distinguished, one from another, is represented by instances of object types defined in the MIB.
さまざまな管理プロトコルのサポートを提供するために、与えられたオブジェクト・タイプのインスタンスが有効に区別されるかもしれないすべての情報(別のものからの1)がMIBで定義されたオブジェクト・タイプのインスタンスによって表されます。
4.3. Macros for Managed Objects
4.3. 管理オブジェクトのためのマクロ
In order to facilitate the use of tools for processing the definition of the MIB, the OBJECT-TYPE macro may be used. This macro permits the key aspects of an object type to be represented in a formal way.
ツールのMIBの定義を処理する使用を容易にするために、OBJECT-TYPEマクロは使用されるかもしれません。 このマクロは、オブジェクト・タイプの特徴が本式に表されることを許可します。
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
"ACCESS" Access
"STATUS" Status
VALUE NOTATION ::= value (VALUE ObjectName)
オブジェクト・タイプマクロ:、:= タイプ記法を始めてください:、:= "SYNTAX"は(TYPE ObjectSyntax)「アクセス」アクセス「状態」状態値記法をタイプします:、:= 値(値のObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
END
以下にアクセスしてください:= 「書き込み禁止」| 「-読まれて、書いてください」| 「書く、-単に、」| 「アクセスしやすくない」状態:、:= 「義務的です」。| 「任意です」。| 「時代遅れ」の終わり
Given the object types defined earlier, we might imagine the following definitions being present in the MIB:
より早く定義されたオブジェクト・タイプを考えて、私たちは、MIBで以下の定義が存在していると想像するかもしれません:
atIndex OBJECT-TYPE
atIndexオブジェクト・タイプ
Rose & McCloghrie [Page 14] RFC 1065 SMI August 1988
ローズとMcCloghrie[14ページ]RFC1065SMI1988年8月
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
::= { atEntry 1 }
SYNTAX INTEGER ACCESSはSTATUSに義務的な状態で読書して書きます:、:= atEntry1
atPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-write
STATUS mandatory
::= { atEntry 2 }
atPhysAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESSはSTATUSに義務的な状態で読書して書きます:、:= atEntry2
atNetAddress OBJECT-TYPE
SYNTAX NetworkAddress
ACCESS read-write
STATUS mandatory
::= { atEntry 3 }
atNetAddress OBJECT-TYPE SYNTAX NetworkAddress ACCESSはSTATUSに義務的な状態で読書して書きます:、:= atEntry3
atEntry OBJECT-TYPE
SYNTAX AtEntry
ACCESS read-write
STATUS mandatory
::= { atTable 1 }
atEntry OBJECT-TYPE SYNTAX AtEntry ACCESSはSTATUSに義務的な状態で読書して書きます:、:= atTable1
atTable OBJECT-TYPE
SYNTAX SEQUENCE OF AtEntry
ACCESS read-write
STATUS mandatory
::= { at 1 }
atTable OBJECT-TYPE SYNTAX SEQUENCE OF AtEntry ACCESSはSTATUSに義務的な状態で読書して書きます:、:= 1
AtEntry ::= SEQUENCE {
atIndex
INTEGER,
atPhysAddress
OCTET STRING,
atNetAddress
NetworkAddress
}
AtEntry:、:= 系列atIndex整数、atPhysAddress八重奏ストリング、atNetAddress NetworkAddress
The first five definitions describe object types, relating, for
example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
atEntry 1 }. In addition, the syntax of this object is defined
(INTEGER) along with the access permitted (read-write) and status
(mandatory). The sixth definition describes an ASN.1 type called
AtEntry.
最初の5つの定義がオブジェクト・タイプを説明します、例えば、関係して、OBJECT IDENTIFIER atEntry1へのOBJECT DESCRIPTOR atIndex。 さらに、このオブジェクトの構文は受入れられたアクセス(-読まれて、書く)と状態(義務的な)と共に定義されます(INTEGER)。 6番目の定義はAtEntryと呼ばれるASN.1タイプについて説明します。
Rose & McCloghrie [Page 15] RFC 1065 SMI August 1988
ローズとMcCloghrie[15ページ]RFC1065SMI1988年8月
5. Extensions to the MIB
5. MIBへの拡大
Every Internet-standard MIB document obsoletes all previous such documents. The portion of a name, termed the tail, following the OBJECT IDENTIFIER
あらゆるインターネット標準MIBドキュメントが前のそのようなものが記録するすべてを時代遅れにします。 OBJECT IDENTIFIERに続くテールと呼ばれた名前の部分
{ mgmt version-number }
管理バージョン番号
used to name objects shall remain unchanged between versions. New versions may:
使用されて、オブジェクトを命名するのはバージョンの間で変わりがないものとします。 新しいバージョンはそうするかもしれません:
(1) declare old object types obsolete (if necessary), but not
delete their names;
(1) 年取ったオブジェクト・タイプが彼らの名前を(必要なら)時代遅れにしますが、削除しないと宣言してください。
(2) augment the definition of an object type corresponding to a
list by appending non-aggregate object types to the object types
in the list; or,
(2) 非集団オブジェクトタイプをリストのオブジェクト・タイプに追加することによってリストに対応するオブジェクト・タイプの定義を増大させてください。 または
(3) define entirely new object types.
(3) 完全に新しいオブジェクト・タイプを定義してください。
New versions may not:
新しいバージョンはそうしないかもしれません:
(1) change the semantics of any previously defined object without
changing the name of that object.
(1) そのオブジェクトの名前を変えないで、どんな以前に定義されたオブジェクトの意味論も変えてください。
These rules are important because they admit easier support for multiple versions of the Internet-standard MIB. In particular, the semantics associated with the tail of a name remain constant throughout different versions of the MIB. Because multiple versions of the MIB may thus coincide in "tail-space," implementations supporting multiple versions of the MIB can be vastly simplified.
彼らがインターネット標準MIBの複数のバージョンの、より簡単なサポートを認めるので、これらの規則は重要です。 特に、名前のテールに関連している意味論はMIBの異なった見解中で一定のままで残っています。 その結果、MIBの複数のバージョンが「テールスペース」で一致するかもしれないので、広大にMIBの複数のバージョンをサポートする実装は簡素化できます。
However, as a consequence, a management agent might return an instance corresponding to a superset of the expected object type. Following the principle of robustness, in this exceptional case, a manager should ignore any additional information beyond the definition of the expected object type. However, the robustness principle requires that one exercise care with respect to control actions: if an instance does not have the same syntax as its expected object type, then those control actions must fail. In both the monitoring and control cases, the name of an object returned by an operation must be identical to the name requested by an operation.
しかしながら、結果として、管理エージェントは予想されたオブジェクト・タイプのスーパーセットに対応するインスタンスを返すかもしれません。 丈夫さの原則に従って、予想されたオブジェクト・タイプの定義を超えてこの例外的な場合では、マネージャはどんな追加情報も無視するべきです。 しかしながら、堅牢性の原則は、1つがコントロール動作に関して注意するのを必要とします: インスタンスに予想されたオブジェクト・タイプと同じ構文がないなら、それらのコントロール動作は失敗しなければなりません。 モニターとコントロールケースの両方では、操作で返されたオブジェクトの名前は操作で要求された名前と同じであるに違いありません。
Rose & McCloghrie [Page 16] RFC 1065 SMI August 1988
ローズとMcCloghrie[16ページ]RFC1065SMI1988年8月
6. Definitions
6. 定義
RFC1065-SMI DEFINITIONS ::= BEGIN
RFC1065-SMI定義:、:= 始まってください。
EXPORTS -- EVERYTHING
internet, directory, mgmt,
experimental, private, enterprises,
OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,
ApplicationSyntax, NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks, Opaque;
EXPORTS--EVERYTHINGインターネット、ディレクトリ、管理、実験的で、私設の企業、OBJECT-TYPE、ObjectName、ObjectSyntax、SimpleSyntax、ApplicationSyntax、NetworkAddress、IpAddress、Counter、Gauge、TimeTicks、Opaque。
-- the path to the root
-- 根への経路
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
インターネットOBJECT IDENTIFIER:、:= iso org(3) dod(6)1
directory OBJECT IDENTIFIER ::= { internet 1 }
ディレクトリOBJECT IDENTIFIER:、:= インターネット1
mgmt OBJECT IDENTIFIER ::= { internet 2 }
管理OBJECT IDENTIFIER:、:= インターネット2
experimental OBJECT IDENTIFIER ::= { internet 3 }
実験的なOBJECT IDENTIFIER:、:= インターネット3
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
個人的なOBJECT IDENTIFIER:、:= インターネット4企業OBJECT IDENTIFIER:、:= 個人的な1
-- definition of object types
-- オブジェクト・タイプの定義
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
"ACCESS" Access
"STATUS" Status
VALUE NOTATION ::= value (VALUE ObjectName)
オブジェクト・タイプマクロ:、:= タイプ記法を始めてください:、:= "SYNTAX"は(TYPE ObjectSyntax)「アクセス」アクセス「状態」状態値記法をタイプします:、:= 値(値のObjectName)
Access ::= "read-only"
| "read-write"
| "write-only"
| "not-accessible"
Status ::= "mandatory"
| "optional"
| "obsolete"
END
以下にアクセスしてください:= 「書き込み禁止」| 「-読まれて、書いてください」| 「書く、-単に、」| 「アクセスしやすくない」状態:、:= 「義務的です」。| 「任意です」。| 「時代遅れ」の終わり
-- names of objects in the MIB
-- MIBのオブジェクトの名前
ObjectName ::=
OBJECT IDENTIFIER
ObjectName:、:= オブジェクト識別子
Rose & McCloghrie [Page 17] RFC 1065 SMI August 1988
ローズとMcCloghrie[17ページ]RFC1065SMI1988年8月
-- syntax of objects in the MIB
-- MIBのオブジェクトの構文
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
ObjectSyntax:、:= CHOICE、簡単なSimpleSyntax
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
-- 簡単なSEQUENCEsは直接そうではありません--事態を簡単に保つためにここに言及されることに注意してください(すなわち、誤用を防いでください)。 しかしながら、--簡単な状態でコード化されたIMPLICITlyであるタイプ--アプリケーション全体のSEQUENCEsは以下のCHOICEに現れるかもしれません。
application-wide
ApplicationSyntax
}
アプリケーション全体のApplicationSyntax
SimpleSyntax ::=
CHOICE {
number
INTEGER,
SimpleSyntax:、:= CHOICE、数のINTEGER
string
OCTET STRING,
OCTET STRINGを結んでください。
object
OBJECT IDENTIFIER,
オブジェクトOBJECT IDENTIFIER
empty
NULL
}
NULLを空にしてください。
ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
ApplicationSyntax:、:= CHOICE、NetworkAddressを扱ってください。
counter
Counter,
Counterを打ち返してください。
gauge
Gauge,
Gaugeを測ってください。
ticks
TimeTicks,
カチカチする音TimeTicks
arbitrary
Opaque
任意のOpaque
Rose & McCloghrie [Page 18] RFC 1065 SMI August 1988
ローズとMcCloghrie[18ページ]RFC1065SMI1988年8月
-- other application-wide types, as they are
-- defined, will be added here
}
-- 定義されて、彼らがそうように、他のアプリケーション全体のタイプはここで加えられるでしょう。
-- application-wide types
-- アプリケーション全体のタイプ
NetworkAddress ::=
CHOICE {
internet
IpAddress
}
NetworkAddress:、:= 選択インターネットIpAddress
IpAddress ::=
[APPLICATION 0] -- in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
IpAddress:、:= [APPLICATION0]--ネットワークバイトオーダーIMPLICIT OCTET STRINGで(サイズ(4))
Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
以下を打ち返してください:= [アプリケーション1] 暗黙の整数(0..4294967295)
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
以下を測ってください:= [アプリケーション2] 暗黙の整数(0..4294967295)
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER
TimeTicks:、:= [アプリケーション3] 暗黙の整数
Opaque ::=
[APPLICATION 4] -- arbitrary ASN.1 value,
IMPLICIT OCTET STRING -- "double-wrapped"
以下について不透明にしてください:= [APPLICATION4]--任意のASN.1値、IMPLICIT OCTET STRING--「二重に包装にされる」
END
終わり
Rose & McCloghrie [Page 19] RFC 1065 SMI August 1988
ローズとMcCloghrie[19ページ]RFC1065SMI1988年8月
7. Acknowledgements
7. 承認
This memo was influenced by three sets of contributors:
このメモは3セットの貢献者によって影響を及ぼされました:
First, Lee Labarre of the MITRE Corporation, who as author of the NETMAN SMI [4], presented the basic roadmap for the SMI.
最初に、MITRE社のリーLabarre。(NETMAN SMI[4]の作者として、社はSMIのために基本的な道路地図を提示しました)。
Second, several individuals who provided valuable comments on this memo prior to its initial distribution:
2番目、初回配布の前にこのメモの貴重なコメントを提供した何人かの個人:
James Davin, Proteon
Mark S. Fedor, NYSERNet
Craig Partridge, BBN Laboratories
Martin Lee Schoffstall, Rensselaer Polytechnic Institute
Wengyik Yeong, NYSERNet
ジェームス・デーヴィン、ProteonマークS.ヒョードル、NYSERNetクレイグPartridge、BBN研究所マーチンリーSchoffstall、レンセラー工科大学Wengyik Yeong、NYSERNet
Third, the IETF MIB working group:
3番目、IETF MIBワーキンググループ:
Karl Auerbach, Epilogue Technology
K. Ramesh Babu, Excelan
Lawrence Besaw, Hewlett-Packard
Jeffrey D. Case, University of Tennessee at Knoxville
James R. Davin, Proteon
Mark S. Fedor, NYSERNet
Robb Foster, BBN
Phill Gross, The MITRE Corporation
Bent Torp Jensen, Convergent Technology
Lee Labarre, The MITRE Corporation
Dan Lynch, Advanced Computing Environments
Keith McCloghrie, The Wollongong Group
Dave Mackie, 3Com/Bridge
Craig Partridge, BBN (chair)
Jim Robertson, 3Com/Bridge
Marshall T. Rose, The Wollongong Group
Greg Satz, cisco
Martin Lee Schoffstall, Rensselaer Polytechnic Institute
Lou Steinberg, IBM
Dean Throop, Data General
Unni Warrier, Unisys
カール・アウアーバック、エピローグ技術K.Rameshインド紳士、ExcelanローレンスBesaw、ヒューレット・パッカードジェフリーD.事件、ノクスビルジェームス・R.デーヴィンのテネシー大学、ProteonはSをマークします; ヒョードル、NYSERNetロブ・フォスター、BBNフィルGross、MITRE社のBentトルプ・ジェンセン、Convergent TechnologyリーLabarre、MITRE社のダン・リンチ、Advanced Computing EnvironmentsキースMcCloghrie、ウォロンゴンGroupデーヴMackie3Com/ブリッジクレイグPartridge、BBN(いす)ジム・ロバートソン(3Com/ブリッジマーシャル・T.ローズ)・ウォロンゴンGroupグレッグSatz、コクチマスマーチンリーSchoffstall、レンセラー工科大学のルウ・スタインバーグ、IBMディーンThroop、データゼネラルUnni Warrier、ユニシス
Rose & McCloghrie [Page 20] RFC 1065 SMI August 1988
ローズとMcCloghrie[20ページ]RFC1065SMI1988年8月
8. References
8. 参照
[1] Information processing systems - Open Systems Interconnection,
"Specification of Abstract Syntax Notation One (ASN.1)",
International Organization for Standardization, International
Standard 8824, December 1987.
[1]情報処理システム--オープン・システム・インターコネクション、「抽象構文記法1(ASN.1)の仕様」、国際標準化機構、国際規格8824(1987年12月)。
[2] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1066, TWG,
August 1988.
[2]McCloghrie K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地」、RFC1066、TWG、1988年8月。
[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
Network Management Protocol", RFC 1067, University of Tennessee
at Knoxville, NYSERNet, Rensselaer Polytechnic, Proteon, August
1988.
「[3] ケース、J.、M.ヒョードル、M.Schoffstall、およびJ.デーヴィン、簡単なネットワークマネージメントは議定書を作ります」、RFC1067、ノクスビルのテネシーの大学、NYSERNet、レンセラー工芸教育です、Proteon、1988年8月。
[4] LaBarre, L., "Structure and Identification of Management
Information for the Internet", Internet Engineering Task Force
working note, Network Information Center, SRI International,
Menlo Park, California, April 1988.
[4]LaBarre、L.、「経営情報の構造と識別、Networkインフォメーション・センター、SRIインターナショナル、インターネット・エンジニアリング・タスク・フォースが注意を扱うメンローパーク(カリフォルニア)1988年インターネット」4月
[5] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, IAB, April 1988.
[5] サーフ、V.、「インターネットネットワークマネージメント規格の開発のためのIAB推薦」、RFC1052、IAB、1988年4月。
[6] Information processing systems - Open Systems Interconnection,
"Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1)", International Organization for Standardization,
International Standard 8825, December 1987.
[6]情報処理システム--オープン・システム・インターコネクション、「基本的なコード化の仕様は抽象的な記法1(ASN.1)のために統治されます」、国際標準化機構、国際規格8825、1987年12月。
Rose & McCloghrie [Page 21]
ローズとMcCloghrie[21ページ]
一覧
スポンサーリンク
