この文書はRFC1155の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                            M. Rose
Request for Comments:  1155            Performance Systems International
Obsoletes:  RFC 1065                                       K. McCloghrie
                                                      Hughes LAN Systems
                                                                May 1990



         Structure and Identification of Management Information
                       for TCP/IP-based Internets
   TCP/IPベースのインターネットのための管理情報の構造と識別子

                           Table of Contents
                                 目次

1.  Status of this Memo
1.  この文書の状態

2.  Introduction
2.  はじめに
3.  Structure and Identification of Management Information
3.  管理情報の構造と識別子
3.1.  Names
3.1.  名前
3.1.1.  Directory
3.1.1.  ディレクトリ
3.1.2.  Mgmt
3.1.2.  管理
3.1.3.  Experimental
3.1.3.  実験
3.1.4.  Private
3.1.4.  私的
3.2.  Syntax
3.2.  構文
3.2.1.  Primitive Types
3.2.1.  基本型
3.2.1.1.  Guidelines for Enumerated INTEGERs
3.2.1.1.  列挙整数のガイドライン
3.2.2.  Constructor Types
3.2.2.  構造型
3.2.3.  Defined Types
3.2.3.  型定義
3.2.3.1.  NetworkAddress
3.2.3.1.  ネットワークアドレス
3.2.3.2.  IpAddress
3.2.3.2.  IPアドレス
3.2.3.3.  Counter
3.2.3.3.  カウンター
3.2.3.4.  Gauge
3.2.3.4.  ゲージ
3.2.3.5.  TimeTicks
3.2.3.5.  時間経過
3.2.3.6.  Opaque
3.2.3.6.  不透明
3.3.  Encodings
3.3.  コード化
4.  Managed Objects
4.  管理オブジェクト
4.1.  Guidelines for Object Names
4.1.  オブジェクト名のガイドライン
4.2.  Object Types and Instances
4.2.  オブジェクト型と実体
4.3.  Macros for Managed Objects
4.3.  管理オブジェクトのためのマクロ
5.  Extensions to the MIB
5.  MIBへの拡張
6.  Definitions
6.  定義
7.  Acknowledgements
7.  謝辞
8.  References
8.  参考文献
9.  Security Considerations
9.  セキュリティの考察
10. Authors' Addresses
10. 著者のアドレス


1.  Status of this Memo
1.  この文書の状態


   This RFC is a re-release of RFC 1065, with a changed "Status of this
   Memo", plus a few minor typographical corrections.  The technical
   content of the document is unchanged from RFC 1065.
   このRFCはRFC1065の再発行で、「この文書の状態
」と少々の印刷
   上の訂正です。文書の技術的な内容はRFC1065から変化していません。

   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
   management information base along with the network management
   protocol, these documents provide a simple, workable architecture and
   system for managing TCP/IP-based internets and in particular, the
   Internet.
   この文書はTCP/IPベースのインターネットのための管理情報の構造と
   識別子の共通の定義を提供します。特に、ネットワーク管理プロトコルとと
   もに管理情報ベースを記述する関連文書と共に、これらの文書はTCP/I
   Pベースのインターネット、特にインターネット、を管理することに対して
   単純で実行可能な体系とシステムを供給します。

   This memo specifies a Standard Protocol for the Internet community.
   Its status is "Recommended".  TCP/IP implementations in the Internet
   which are network manageable are expected to adopt and implement this
   specification.
   この文書はインターネット共同体のための標準プロトコルを指定します。そ
   の状態は「推薦」です。ネットワークで管理できるインターネットのTCP
   /IP実装がこの仕様書を採用し、実装することを期待されます。

   The Internet Activities Board recommends that all IP and TCP
   implementations be network manageable.  This implies implementation
   of the Internet MIB (RFC-1156) and at least one of the two
   recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
   It should be noted that, at this time, SNMP is a full Internet
   standard and CMOT is a draft standard.  See also the Host and Gateway
   Requirements RFCs for more specific information on the applicability
   of this standard.
   インターネット活動委員会はすべてのIPとTCP実装がネットワーク管理
   可能であることを勧めます。これはインターネットMIB(RFC1156)
   と、2つの推薦された管理プロトコル、SNMP(RFC1157)かCM
   OT(RFC1095)のうちの少なくとも1つの実装を暗示します。現在
   SNMPが完全インターネット標準で、CMOTがドラフトの標準であるこ
   とを指摘します。この標準の適用性についてのより特定の情報は、ホストと
   ゲートウェイ要求条件RFCを見てください。

   Please refer to the latest edition of the "IAB Official Protocol
   Standards" RFC for current information on the state and status of
   standard Internet protocols.
   標準インターネット・プロトコルの状態と状態にについての現在の情報につ
   いて、どうか「IAB公式のプロトコル標準」RFCの最新版を参照してく
   ださい。

   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(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つの関連文書で扱われます:1つは管
   理情報ベース(MIB)[2]を記述し、他方は単純ネットワーク管理プロトコ
   ル(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
   with SNMP.
   この文書はインターネット技術標準化タスクフォースの仕事に基づき、特に
   題名が「インターネットの管理情報の構造と識別子」の文書[4]に基づいてい
   ます。この文書は上記文書から得られた骨格構造を使いますが、1つの非常
   に重要な違いがあります:上記文書は完全に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
   Development of Internet Network Management Standards" [5] and RFC
   1109, "Report of the Second Ad Hoc Network Management Review Group"
   [6].  In particular, we feel that this memo, along with the memo
   describing the management information base, provide a solid basis for
   network management of the Internet.
   この文書と2つの関連文書がRFC1052「インターネットネットワーク
   管理標準の開発のIAB推薦」[5]とRFC1109「第2アドホックネット
   ワーク管理レビューグループ報告」[6]で明らかにされてガイドラインに従
   うと信じられます。特に、我々はこのメモが、管理情報ベースを記述してい
   るメモとともに、インターネットのネットワーク管理の堅実な基礎を提供す
   ると感じます。

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].
   管理されたオブジェクトが、管理情報ベースあるいはMIBと呼ばれる、仮
   想情報記憶装置によってアクセスされます。MIBのオブジェクトが抽象構
   文論表記法1(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.
   それぞれのオブジェクトの種別(オブジェクト型と呼ばれる)は名前と構文
   とコーディングを持っています。名前はオブジェクト識別子として一意に表
   されます。オブジェクト識別子は管理的に割り当てられた名前です。

   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.
   名前を割り当てるために使われた管理上のポリシはこの文書の後で論じられ
   ます。オブジェクト型の構文はオブジェクト型に対応している抽象データ構
   造を定義します。例えば、あるオブジェクト型の構造は整数あるいはオクテッ
   トストリングかもしれません。一般にどんな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 [7].
   オブジェクト型のコーディングは、オブジェクト型構文を使って、そのオブ
   ジェクト型の実体を表す方法です。暗黙で、オブジェクトの構文とコーディ
   ングの表記の結びつきは、ネットワークの上に伝達される時オブジェクトが
   表される方法です。このメモはASN.1[7]の基本コーディング規則の使
   用を指定します。

   It is beyond the scope of this memo to define either the MIB used for
   network management or the network management protocol.  As mentioned
   earlier, these tasks are left to 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.)
   名前が管理されたオブジェクトを識別するために使われます。このメモは自
   然な階層的な名前を指定します。オブジェクト識別子の概念はこの考えを設
   計するために使われます。オブジェクト識別子が管理オブジェクトの命名以
   外の目的で使えます;例えば、それぞれの国際規格が識別の目的で割り当て
   られたオブジェクト識別子を持っています。要するに、オブジェクト識別子
   は、オブジェクトの意味にかかわらず、オブジェクトを識別する手段です
   (例えば、ネットワークオブジェクト、標準文書など)。

   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.
   オブジェクト識別子はグローバルな木を横断する整数の列です。木は1つの
   ルートと、エッジを通して多くのラベルをはられたノードから成り立ちます。
   それぞれのノードが、さらに、ラベルをはられた子を持っているかもしれま
   せん。この場合、我々はノードを部分木と呼ぶかもしれません。この手順は
   任意のレベルの深さまで継続するかもしれません。オブジェクト識別子の重
   要な考えは、ノードに割り当てられた意味の管理上の制御が、木を横断する
   につれて、委任されるかもしれないという理解です。ラベルは短いテキスト
   の記述と整数の組合せです。

   The root node itself is unlabeled, but has at least three children
   directly under it:  one node is administered by the International
   Organization for Standardization, with label iso(1); another is
   administrated by the International Telegraph and Telephone
   Consultative Committee, with label ccitt(0); and the third is jointly
   administered by the ISO and the CCITT, joint-iso-ccitt(2).
   ルートノード自身はラベルがありませんが、直下に少なくとも3つの子を持
   ちます:1つのノードが、ラベルiso(1)で、国際標準化機構で管理されます;
   もう1つは、ラベルccitt(0)で、国際電信電話諮問委員会で管理されます;
   3つめがjoint-iso-ccitt(2)で、ISOとCCITTの共同管理で運営され
   ます。

   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 Institutes of
   Standards and Technology.  One of these subtrees has been transferred
   by the NIST to the U.S. Department of Defense, dod(6).
   iso(1)ノード下で、ISOは他の国際国内組織で使用するために部分木を指
   定しました、org(3)。子ノードで、2つがアメリカ合衆国国立標準規格技術
   研究所に割り当てられました。これらの部分木の1つがNISTからアメリ
   カ合衆国国防省に移されました、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はどのようにオブジェクト識別子の部分木を管理する
   か示していませんでした。この文書はDoDが、インターネット活動委員会
   (IAB)で運営されるために、インターネット共同体に次のようにノード
   を割り当てると想定します:

      internet    OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

   That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
   prefix:
   すなわち、オブジェクト識別子のインターネット部分木はは次のプレフィッ
   クスで始まります:

      1.3.6.1.

   This memo, as a standard approved by the IAB, now specifies the
   policy under which this subtree of OBJECT IDENTIFIERs is
   administered.  Initially, four nodes are present:
   この文書は、IABによって承認された標準として、今、このオブジェクト
   識別子を管理するポリシを指定します。初めに、4つのノードが存在してい
   ます:

      directory     OBJECT IDENTIFIER ::= { internet 1 }
      mgmt          OBJECT IDENTIFIER ::= { internet 2 }
      experimental  OBJECT IDENTIFIER ::= { internet 3 }
      private       OBJECT IDENTIFIER ::= { internet 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.
   directory(1)部分木はどのようにOSIディレクトリがインターネットで使
   われるかを論じる将来の文書で使用するために確保されます。

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 Internet 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 Internet Assigned Numbers Authority for
   identifying the objects defined by that memo.
   mgmt(2)部分木はIABによって承認された文書で定義されるオブジェクトを
   識別するために使われます。インターネットのためにmgmt(2)部分木の管理が
   インターネット番号割当当局にIABから委任されます。インターネット標
   準管理情報ベースの新しいバージョンを定義するRFCが承認される時、文
   書で定義されたオブジェクトを識別するためインターネット番号割当当局は
   オブジェクト識別子を割り当てます。

   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
   例えば、最初のインターネット標準MIBを定義するRFCは管理文書番号
   1を割り当てられます。このRFCはインターネット標準MIBを定義する
   ためにオブジェクト識別子

      { mgmt 1 }

   or


      1.3.6.1.2.1

   in defining the Internet-standard 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 Internet Assigned Numbers Authority of
   the Internet.
   experimental(3)部分木はインターネット実験で使われたオブジェクトを識
   別するために使われます。experimental(3)部分木の管理がIABからイン
   ターネットのインターネット番号割当当局に委任されます。

   For example, an experimenter might received number 17, and would have
   available the OBJECT IDENTIFIER
   例えば、実験者が17番を得て、オブジェクト識別子

      { experimental 17 }

   or
   あるいは

      1.3.6.1.3.17

   for use.
   を利用可能にするでしょう。

   As a part of the assignment process, the Internet Assigned Numbers
   Authority may make requirements as to how that subtree is used.
   割当て手順の一部として、インターネット番号割当当局は、どのようにその
   部分木が使われるかについて、必要条件を作ってもよいです。

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 Internet Assigned Numbers Authority for the
   Internet.  Initially, this subtree has at least one child:
   private(4)部分木は一方的に定義されたオブジェクトを識別するために使わ
   れます。private(4)部分木の管理がIBAからがインターネットのインター
   ネット番号割当当局に委任されます。初めに、この部分木は少なくとも1の
   子を持っています:

      enterprises   OBJECT IDENTIFIER ::= { private 1 }

   The enterprises(1) subtree is used, among other things, to permit
   parties providing networking subsystems to register models of their
   products.
   enterprises(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
   Internet Assigned Numbers Authority.  Such a node might be numbered:
   部分木を得たら、企業は、例えば、この部分木で新しいMIBオブジェクト
   を定義するかもしれません。加えて、企業が管理プロトコルで使用際の明確
   な識別メカニズムを提供するためにこの部分木の下にネットワーキングサブ
   システムを登録することが強く推薦されています。例えば、もし「フリンス
   トン社」がネットワーキングサブシステムを作るなら、彼らがインターネッ
   ト番号割当当局にenterprises部分木下のノードを求めることができます。
   このようなノードは下記の番号を付けられるかもしれません:

      1.3.6.1.4.1.42

   The "Flintstones, Inc." enterprise might then register their "Fred
   Router" under the name of:
   「フリンストン社」が下記の名前下で「フレッドルータ」を登録するかもし
   れません:

      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基本型の整数とオクテット列とオブジェクト識別子とヌルだけが
   認められます。これらは時々非総計型と述べられます。

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
   enumerations.  Use of this value is prohibited.
   もし列挙整数がオブジェクト型として規定されるなら、値0の命名された数
   が列挙リストで存在するべきではありません。この値の使用が禁止されます。

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構造型シーケンスは、リストかテーブルを生成するために使われ
   るなら、認められます。

   For lists, the syntax takes the form:
   リストで、構文は次の書式をとります:。

      SEQUENCE { <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).
   ここで、各<type>は上でリストアップされたASN.1基本型の1つです。
   さらに、これらのASN.1型は常に存在しています(デフォルトとオプ
   ション項はシーケンス定義で現われません)。

   For tables, the syntax takes the form:
   テーブルで、構文は以下の書式をとります:

      SEQUENCE OF <entry>

   where <entry> resolves to a list constructor.
   ここで<entry>リスト構造の要素です。

   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基本型やリストやテーブルや他のアプ
   リケーション範囲の型になければ、新しいアプリケーション範囲の型が定義
   されるかもしれません。初めに、ほとんどアプリケーション範囲の型が定義
   されません。将来の文書が、意見の一致に達せれば、他を定義するでしょう。

3.2.3.1.  NetworkAddress
3.2.3.1.  ネットワークアドレス

   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.
   これは、プロトコルファミリのどれか1つのアドレス表現を表します。現在、
   ただ1つのプロトコルファミリ、インターネットファミリ、だけがあります。

3.2.3.2.  IpAddress
3.2.3.2.  IPアドレス

   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オクテットで、ネットワークバイト順でのオクテット文字
   列として描かれます。

   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
   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の10進数)
   を指定します。

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の10進数)を指定します。

3.2.3.5.  TimeTicks
3.2.3.5.  時間経過

   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.
   このアプリケーション範囲の型はある時点からの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値で
   「二重に包み」にされます。

   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.1外部型の使用により、ASN.1以外のコード化が不透明
   にコード化されたデータで使われるかもしれないことに注意してください。

3.3.  Encodings
3.3.  コード化

   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基本コーディング規則を構文に適用することで伝達されるかもしれません。


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.
      オブジェクト型の、オブジェクトディスクプリタと呼ばれる、テキスト名、
      と対応するオブジェクト識別子。

   Syntax:
   構文:
      The abstract syntax for the object type.  This must resolve to an
      instance of the ASN.1 type ObjectSyntax (defined below).
      オブジェクト型の抽象構文。これは(下に定義された)ASN.1型
      ObjectSyntaxの実体に変換しなくてはなりません。

   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.
      読込み専用、読み書き、書き込み専用、アクセス不可、のどれか。

   Status:
   状態:
      One of mandatory, optional, or obsolete.
      必須、任意、時代遅れ、のどれか。

   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でオブジェクト型に対応しているオブ
   ジェクト記述子が一意で、かつ記憶しやすく、印刷可能文字列であるべきで
   す。これは人がMIBを論じる時使うべき共通語を促進し、そしてユーザ・
   インタフェースでの単純なテーブルのマッピングを容易にします。

4.2.  Object Types and Instances
4.2.  オブジェクト型と実体

   An object type is a definition of a kind of managed object; it is
   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で定義されます。これらのオブジェクト型の
   それぞれがオブジェクト識別子で一意に命名され、またオブジェクト記述子
   のテキスト名を持ちます。オブジェクトの実体が参照される手段は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 }

   Syntax:
      INTEGER

   Definition:
      The interface number for the physical address.
      物理アドレスのインターフェース番号

   Access:
      read-write.

   Status:
      mandatory.


   OBJECT:
   -------
      atPhysAddress { atEntry 2 }

   Syntax:
      OCTET STRING

   Definition:
      The media-dependent physical address.
      メディア依存の物理アドレス

   Access:
      read-write.

   Status:
      mandatory.


   OBJECT:
   -------
      atNetAddress { atEntry 3 }

   Syntax:
      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:
   で、MIBで第4のオブジェクト型が定義されます

   OBJECT:
   -------
      atEntry { atTable 1 }

   Syntax:

      AtEntry ::= SEQUENCE {
            atIndex
            INTEGER,
            atPhysAddress
            OCTET STRING,
            atNetAddress
            NetworkAddress
            }

   Definition:
      An entry in the address translation table.
      アドレス変換テーブルの項目

   Access:
      read-write.

   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 }

   Syntax:
      SEQUENCE OF 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オブジェクトの実体がatEntryオブジェクトの実体、アド
   レス変換テーブル、の集合である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 }

   and specify, using a protocol-specific mechanism, the object instance
   と命名し、プロトコル固有のメカニズムを使い、オブジェクト実体を次のよ
   うに指定するかもしれません。

      { atNetAddress } = { internet "10.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
   値が{ internet "10.0.0.52" }であるアドレス翻訳テーブルの項目の一部で
   あるatPhysAddressの実体を参照するでしょう。

   To continue with this example, consider how one might refer to an
   aggregate object (list) within a table.  Naming the object type
   この例で、テーブルの中の総数オブジェクトをどう参照するか考えてくださ
   い。オブジェクトをタイプ

      { atEntry }

   and specifying, using a protocol-specific mechanism, the object
   instance
   と命名し、プロトコル固有のメカニズムを使って、オブジェクトの実体

      { atNetAddress } = { internet "10.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値が{ internet "10.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.
   それぞれの管理プロトコルが単純な(非総計)オブジェクト型にアクセスす
   るメカニズムを供給しなくてはなりません。それぞれの管理プロトコルが総
   計オブジェクト型にアクセスをサポートするかどうか明示します。さらに、
   プロトコルは、オブジェクト型/実体の組合せが複数の型の実体を参照する
   時、どの実体が「返される」か明示しなくてはなりません。

   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.
   いろいろな管理プロトコルに対するサポートを許すために、与えられたオブ
   ジェクト型の実体を区別する全ての情報が、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 MACRO ::=
      BEGIN
          TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
                            "ACCESS" Access
                            "STATUS" Status
          VALUE NOTATION ::= value (VALUE 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
                          SYNTAX  INTEGER
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atEntry 1 }

                  atPhysAddress OBJECT-TYPE
                          SYNTAX  OCTET STRING
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atEntry 2 }

                  atNetAddress OBJECT-TYPE
                          SYNTAX  NetworkAddress
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atEntry 3 }

                  atEntry OBJECT-TYPE
                          SYNTAX  AtEntry
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { atTable 1 }

                  atTable OBJECT-TYPE
                          SYNTAX  SEQUENCE OF AtEntry
                          ACCESS  read-write
                          STATUS  mandatory
                          ::= { at 1 }

                  AtEntry ::= SEQUENCE {
                      atIndex
                          INTEGER,
                      atPhysAddress
                          OCTET STRING,
                      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つの定義は、、例えば、オブジェクト記述子atIndexをオブジェクト
   識別子{ atEntry 1 }に関連づける、オブジェクト型を記述します。加えて、
   オブジェクトの構文が(INTEGER)とアクセス許可(読み書き)と状態(必須)
   で定義されます。6番目の定義はAtEntryと呼ばれるASN.1型を記述しま
   す。

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文書が以前の同様の文書を時代遅れにし
   ます。名前オブジェクトに使った、オブジェクト識別子

      { 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の多数のバージョンに対するよ
   り容易なサポートを認めるために、重要です。特に、名前の尻尾の意味はM
   IBの異なったバージョンで変わりません。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.
   しかしながら、結果として、管理エージェントが予想されるオブジェクト型
   のスーパーセットに対応している実体を返すかもしれません。強靭の原則に
   従って、この例外的な場合に、管理者は予想されるオブジェクト型の定義を
   越えた、追加情報を無視するべきです。しかしながら、強靭の原則は制御行
   動に関して慎重さを必要とします:もし実体が予想されるオブジェクト型と
   同じ構文を持っていないなら、それらの制御行動は失敗しなくてはなりませ
   ん。モニタリングと制御の両方の場合で、オペレーションによって返された
   オブジェクトの名前はオペレーションによって求められた名前とまったく同
   じであるに違いありません。

6.  Definitions
6.  定義

           RFC1155-SMI DEFINITIONS ::= BEGIN

           EXPORTS -- EVERYTHING
                   internet, directory, mgmt,
                   experimental, private, enterprises,
                   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 }

            directory     OBJECT IDENTIFIER ::= { internet 1 }

            mgmt          OBJECT IDENTIFIER ::= { internet 2 }

            experimental  OBJECT IDENTIFIER ::= { internet 3 }

            private       OBJECT IDENTIFIER ::= { internet 4 }
            enterprises   OBJECT IDENTIFIER ::= { private 1 }

            -- definition of object types
            -- オブジェクト型の定義

            OBJECT-TYPE MACRO ::=
            BEGIN
                TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
                                  "ACCESS" Access
                                  "STATUS" Status
                VALUE NOTATION ::= value (VALUE 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

               -- syntax of objects in the MIB
               -- MIB内のオブジェクトの構文

               ObjectSyntax ::=
                   CHOICE {
                       simple
                           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
               -- 単純化のため、単純シーケンスがここで直接参照
               -- されないことに注意してください(すなわち、誤
               -- 用に注意)。しかしながら、アプリケーション範
               -- 囲の型で、暗黙でコード化された単純シーケンス
               -- が、次の選択に現われるかもしれません。

                       application-wide
                           ApplicationSyntax
                   }

                  SimpleSyntax ::=
                      CHOICE {
                          number
                              INTEGER,

                          string
                              OCTET STRING,

                          object
                              OBJECT IDENTIFIER,

                          empty
                              NULL
                      }

                  ApplicationSyntax ::=
                      CHOICE {
                          address
                              NetworkAddress,

                          counter
                              Counter,

                          gauge
                              Gauge,

                          ticks
                              TimeTicks,

                          arbitrary
                              Opaque

                  -- other application-wide types, as they are
                  -- defined, will be added here
                  -- 他のアプリケーション範囲の型が、定義される
                  -- 時に、ここに加えられるでしょう。
                      }


                  -- application-wide types
                  -- アプリケーション範囲の型。

                  NetworkAddress ::=
                      CHOICE {
                          internet
                              IpAddress
                      }

                  IpAddress ::=
                      [APPLICATION 0]          -- in network-byte order
                                               -- ネットワークバイト順
                          IMPLICIT OCTET STRING (SIZE (4))

                  Counter ::=
                      [APPLICATION 1]
                          IMPLICIT INTEGER (0..4294967295)

                  Gauge ::=
                      [APPLICATION 2]
                          IMPLICIT INTEGER (0..4294967295)

                  TimeTicks ::=
                      [APPLICATION 3]
                          IMPLICIT INTEGER (0..4294967295)

                  Opaque ::=
                      [APPLICATION 4]          -- arbitrary ASN.1 value,
                                               -- ASN.1値属性
                          IMPLICIT OCTET STRING   --   "double-wrapped"
                                                  -- 2重カプセル化

                  END


7.  Acknowledgements
7.  謝辞

   This memo was influenced by three sets of contributors to earlier
   drafts:
   この文書は前のドラフトで3種類の貢献の影響を受けました:

   First, Lee Labarre of the MITRE Corporation, who as author of the
   NETMAN SMI [4], presented the basic roadmap for the SMI.
   最初に、NETMAN SMI[4]の著者のMITRE社のLee Labarreは、
   SMIの基本ロードマップを提出しました。

   Second, several individuals who provided valuable comments on this
   memo prior to its initial distribution:
   次に、この文書のその最初の配布で、何人かの個人が貴重なコメントを供給
   しました:

         James R. Davin, Proteon
         Mark S. Fedor, NYSERNet
         Craig Partridge, BBN Laboratories
         Martin Lee Schoffstall, Rensselaer Polytechnic Institute
         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


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.

   [2] McCloghrie K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based Internets", RFC 1156,
       Performance Systems International and Hughes LAN Systems, May
       1990.

   [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
       Network Management Protocol", RFC 1157, University of Tennessee
       at Knoxville, Performance Systems International, Performance
       Systems International, and the MIT Laboratory for Computer
       Science, May 1990.

   [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.

   [5] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, IAB, April 1988.

   [6] Cerf, V., "Report of the Second Ad Hoc Network Management Review
       Group", RFC 1109, IAB, August 1989.

   [7] 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.

Security Considerations
セキュリティの考察

   Security issues are not discussed in this memo.
   セキュリティ問題がこの文書で論じられません。


Authors' Addresses
著者のアドレス

   Marshall T. Rose
   PSI, Inc.
   PSI California Office
   P.O. Box 391776
   Mountain View, CA 94039

   Phone: (415) 961-3380

   EMail: mrose@PSI.COM


   Keith McCloghrie
   The Wollongong Group
   1129 San Antonio Road
   Palo Alto, CA 04303

   Phone: (415) 962-7160

   EMail: sytek!kzm@HPLABS.HP.COM

Japanese translation by Ishida So