Network Working Group R. Steinberger
Request for Comments: 3201 Paradyne Networks
Category: Standards Track O. Nicklass
RAD Data Communications Ltd.
January 2002
Definitions of Managed Objects
for Circuit to Interface Translation
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo defines an extension of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existing MIB modules.
このメモはTCP / IPベースのインターネットでネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の拡張を定義します。特に、それはifTableのに面白いサーキットインタフェースの挿入を管理するためにオブジェクトを定義します。これはifEntryのを必要とする他のMIBモジュール内で使用しなければならない回路のために重要です。これは不変、既存のMIBモジュールを使用して、回路への集積回路の監視ならびにルーティングを可能にします。
Table of Contents
目次
1. The SNMP Management Framework ............................... 2
2. Conventions ................................................. 3
3. Overview .................................................... 3
3.1. Circuit Concepts .......................................... 4
3.2. Theory of Operation ....................................... 4
3.2.1. Creation Process ........................................ 4
3.2.2. Destruction Process ..................................... 5
3.2.2.1. Manual Row Destruction ................................ 5
3.2.2.2. Automatic Row Destruction ............................. 5
3.2.3. Modification Process .................................... 5
3.2.4. Persistence of Data ..................................... 5
4. Relation to Other MIB Modules ............................... 6
4.1. Frame Relay DTE MIB ....................................... 6
4.2. Frame Relay Service MIB ................................... 6
4.3. ATM MIB ................................................... 6
4.4. Interfaces Group MIB ...................................... 6
4.4.1. Interfaces Table (ifTable, ifXtable) .................... 6
4.4.2. Stack Table (ifStackTable) .............................. 9
4.5. Other MIB Modules ......................................... 11
5. Structure of the MIB Module ................................. 11
5.1. ciCircuitTable ............................................ 11
5.2. ciIfMapTable .............................................. 11
6. Object Definitions .......................................... 11
7. Acknowledgments ............................................. 19
8. References .................................................. 19
9. Security Considerations ..................................... 21
10. IANA Considerations ........................................ 21
11. Authors' Addresses ......................................... 22
12. Full Copyright Statement ................................... 23
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5つの主要コンポーネントから構成されています。
o An overall architecture, described in RFC 2571 [1].
RFC 2571に記載され、全体的なアーキテクチャ、O [1]。
o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].
管理の目的のためにオブジェクトとイベントを記述し、命名するためのメカニズムO。管理情報（SMI）のこのような構造の最初のバージョンはSTD 16、[2]でSMIv1と呼ばれ、STD 16、RFC 1155に記載され、RFC 1212 [3]及びRFC 1215 [4]。第二のSMIv2と呼ばれるバージョン、STD 58、RFC 2578に記載されている[5]、RFC 2579 [6]およびRFC 2580 [7]。
o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
管理情報を転送するためのOメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、[8]のSNMPv1と呼ばれ、STD 15、RFC 1157に記載されています。インターネット標準トラックプロトコルでないSNMPメッセージプロトコルの第2のバージョンは、SNMPv2cのと呼ばれ、RFC 1901年に記載されている[9]およびRFC 1906 [10]。メッセージプロトコルの第三のバージョンのSNMPv3と呼ばれ、RFC 1906年に記載されている[10]、RFC 2572 [11]およびRFC 2574 [12]。
o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
管理情報にアクセスするためのOプロトコル操作。プロトコル操作と関連PDU形式の第一セットは、STD 15、RFC 1157に記載されている[8]。プロトコル操作と関連PDU形式の第2のセットは、RFC 1905 [13]に記載されています。
o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].
O RFC 2573 [14]とビューベースアクセス制御メカニズムに記載の基本的なアプリケーションのセットは、RFC 2575 [15]に記載します。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16].
現在のSNMP Management Frameworkへの、より詳細な紹介は、RFC 2570 [16]に記載されています。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理対象オブジェクトが仮想情報店を介してアクセスされ、管理情報ベースまたはMIBと呼ばれます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用して定義されています。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 SMIv1に従うMIBは、適切な翻訳を介して製造することができます。得られた翻訳されたMIBには翻訳（Counter64のの使用）が可能ではないので、オブジェクトまたはイベントが省略されている場合を除いて、意味的に等価でなければなりません。 SMIv2のいくつかの機械読み取り可能な情報には、翻訳プロセスの間、SMIv1の原文の記述に変換されます。しかし、機械読み取り可能な情報のこの損失がMIBの意味論を変えると考えられません。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [21].
キーワードは、REQUIREDは、、、、彼らは、この文書に表示されたときに、RFC 2119 [21]で説明したように解釈されるべきである、MAY、推奨しません、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
This MIB module addresses the concept of inserting circuits, which are potentially virtual, into the ifTable. There are multiple reasons to allow circuits to be added to the ifTable. The most prevalent of which are the standard routing MIB tables such as the ipCidrRouteTable (IP-FORWARD-MIB) and the ipNetToMediaTable (IP-MIB) act on the ifIndex and the RMON MIBs (RMON-MIB and RMON2-MIB as defined in RFC 2819 [23] and RFC 2021 [19]) require the use of an ifIndex a DataSource.
このMIBモジュールはifTableのに、潜在的に仮想的な回路を、挿入の概念に対応しています。回路がありますifTableに追加できるようにするために、複数の理由があります。 RFCに定義されたようなipCidrRouteTable（IP-FORWARD-MIB）などの標準的なルーティングMIBテーブルとのifIndexとRMONのMIB（RMON-MIBおよびRMON2-MIBにipNetToMediaTable（IP-MIB）行為であるの最も優勢2819 [23]およびRFC 2021 [19]）のifIndexを使用するデータソースを必要とします。
There is a further need to potentially monitor or manage a circuit based on the directional flow of traffic going through it. For instance, monitoring of protocols passed on a circuit using RMON-II (RFC 2021 [19]) does not currently capture the direction of the flow. This MIB module provides the capability to define an interface based on the specific direction of the flow.
潜在的にそれを通過するトラフィックの方向の流れに基づいて回路を監視または管理することが必要とされています。例えば、RMON-II（RFC 2021 [19]）を用いて、回路に渡されるプロトコルのモニタリングは、現在、流れの方向を捕捉しません。このMIBモジュールは、流れの特定の方向に基づいてインターフェイスを定義する能力を提供します。
This section provides an overview and background of how to use this MIB module.
このセクションでは、このMIBモジュールを使用する方法の概要と背景を提供します。
There are multiple MIB modules that define circuits. Three commonly used MIB modules are FRAME-RELAY-DTE-MIB (RFC 2115) [20], FRNETSERV-MIB (RFC 2954) [18], and ATM-MIB (RFC 2515) [22]. These define management objects for frame relay DTEs, frame relay services, and ATM respectively. Each of these MIB modules contain the ability to add or delete circuits; however, none create a specific ifEntry for a circuit. The reason for this is that there are potentially multiple circuits and not every circuit needs to be managed as an individual interface. For example, not every circuit on a device needs to be monitored with RMON and not every circuit needs to be included as an individual circuit for routing. Further, the Interfaces Group MIB (RFC 2863) [17] strongly recommends that conceptual rows not be added to the ifTable for virtual circuits.
回路を定義する複数のMIBモジュールがあります。三個の一般的に使用されるMIBモジュールは、フレーム・リレー・DTE-MIB（RFC 2115）[20]、FRNETSERV-MIB（RFC 2954）[18]、およびATM-MIB（RFC 2515）[22]です。これらは、それぞれ、フレームリレーのDTE、フレームリレーサービス、およびATMの管理オブジェクトを定義します。これらのMIBモジュールの各々は、回路を追加または削除する機能が含まれています。しかし、どれも回路の特定のifEntryを作成していません。この理由は、そこに潜在的に複数の回路ではなく、すべての回路は、個々のインタフェースとして管理する必要があるということです。例えば、デバイス上のすべての回路がRMONで監視する必要がなく、すべての回路は、ルーティングのための個々の回路として含まする必要がありません。さらに、インタフェースグループMIB（RFC 2863）[17]強く概念的な行が仮想回線のためのifTableに追加されないことをお勧めします。
The rationale for creating conceptual rows in the ifTable for these circuits is that there is a need for their use in either management of routing or monitoring of data. Both of these functions require mapping to an ifIndex.
これらの回路のためのifTableの概念的な行を作成するための理論的根拠は、データのルーティングやモニタリングの管理のいずれかにおけるそれらの使用の必要性があることです。これらの機能の両方がifIndexのへのマッピングが必要です。
This MIB module is designed such that only those circuits that require an ifIndex need be added to the ifTable. This prevents over-populating the ifTable with useless or otherwise unused indices.
このMIBモジュールはifIndexのを必要とするだけの回路がifTableのに追加される必要があるように設計されています。これは、過剰投入役に立たない又はそうでなければ未使用のインデックスとifTableのを防止します。
While this document often refers to ATM and frame relay, it is not specifically designed for only those types of circuits. Any circuit that is defined in a MIB module but does not have its own ifIndex MAY be added with this MIB module.
この文書は、多くの場合、ATMとフレームリレーを指しますが、それを具体的に回路のみこれらのタイプのために設計されていません。 MIBモジュールで定義されているが、独自のifIndexを持っていない任意の回路は、このMIBモジュールを添加してもよいです。
In some cases, devices will automatically populate the rows of ciCircuitTable as circuits are created or discovered. However, in many cases, it may be necessary for a network manager to manually create rows.
いくつかのケースでは、デバイスが自動的に回線を作成または発見されているようciCircuitTableの行を移入します。しかし、多くの場合、それは手動で行を作成するために、ネットワーク管理者のために必要であってもよいです。
Manual creation of rows requires the following steps:
行の手動作成は、次の手順を実行する必要があります
1) Locate or create the circuit that is to be added on the device.
1）の位置またはデバイスに追加される回路を作成します。
2) Create a row in ciCircuitTable for each flow type that is required.
2）必要とされる各フロータイプにciCircuitTableの行を作成します。
The first step above requires some knowledge of the circuits that exist on a device. Typically, logical ports have entries in the ifTable. If, for example, the ifType for the logical port is frameRelay(32), the circuits can be located in the frCircuitTable of the Frame Relay DTE MIB (FRAME-RELAY-DTE-MIB) [18]. If, as another example, the ifType for the logical port is frameRelayService(44), the circuits can be located in the frPVCEndptTable of the Frame Relay Service MIB (FRNETSERV-MIB) [20]. If, as a final example, the ifType for the logical port is aal5(49), the circuits can be located in the aal5VccTable of the ATM MIB (ATM-MIB) [22]. An entry describing the circuit MUST exist in some table prior to creating a row in ciCircuitTable. The object identifier that MUST be used in the circuit definition is the lexicographically smallest accessible OID that fully describes the the circuit.
最初のステップは、上記デバイス上に存在する回路のいくつかの知識を必要とします。典型的には、論理ポートはifTableのエントリを持ちます。例えば、論理ポート用のifTypeはフレームリレー（32）であれば、回路は、フレームリレーDTE MIB（フレームリレーDTE-MIB）[18]のfrCircuitTableに配置することができます。別の例として、論理ポート用のifTypeがframeRelayService（44）である場合、回路は、フレームリレーサービスMIB（FRNETSERV-MIB）[20]のfrPVCEndptTableに配置することができます。 、最後の例として、論理ポート用のifTypeがAAL5（49）であれば、回路は、ATM MIB（ATM-MIB）[22]のaal5VccTableに配置することができます。回路を記述するエントリは、先行ciCircuitTableの行を作成するために、いくつかのテーブルに存在しなければなりません。回路の定義で使用しなければならないオブジェクト識別子は、完全回路を記述する辞書最小アクセスOIDです。
Manual row destruction is straight forward. Any row can be destroyed and the resources allocated to it are freed by setting the value of its status object (ciCircuitStatus) to destroy(6). It should be noted that when ciCircuitStatus is set to destroy(6) all associated rows in the ifTable and in ciIfMapTable will also be destroyed. This process MAY trigger further row destruction in other tables as well.
マニュアル行の破壊は単純です。任意の行が破壊されることができ、それに割り当てられたリソースは、（6）を破壊するために、そのステータスオブジェクト（ciCircuitStatus）の値を設定することによって解放されます。 ciCircuitStatusを破壊するために設定されている場合（6）ifTableのとciIfMapTableに関連するすべての行も破壊されることに留意すべきです。このプロセスは、他のテーブルにさらに行破壊をトリガすることができます。
Rows in the tables MAY be destroyed automatically based on the existence of the circuit on which they rely. When a circuit no longer exists in the device, the data in the tables has no relation to anything known on the network. For this reason, rows MUST be removed from this table as soon as it is discovered that the associated circuits no longer exist. The effects of automatic row destruction are the same as manual row destruction.
表の行は、彼らが依存していた回路の有無に基づいて自動的に破壊されることがあります。回路はもはやデバイスに存在する場合、テーブル内のデータがネットワーク上で知られているものとは関係ありません。このため、行は、すぐにそれが発見されると、関連する回路はもはや存在しないことをこの表から削除する必要があります。自動行破壊の効果は、手動行の破壊と同様です。
Since no objects in the MIB module can be changed once rows are active, there are no modification caveats.
行がアクティブである後MIBモジュールにはオブジェクトが変更できないので、何の変更警告はありません。
Each row in the tables of this MIB module relies on information from other MIB modules. The rules for persistence of the data SHOULD follow the same rules as those of the underlying MIB module. For example, if the circuit defined by ciCircuitObject would normally be stored in non-volatile memory, then the ciCircuitEntry SHOULD also be non-volatile.
このMIBモジュールのテーブルの各行は、他のMIBモジュールからの情報に依存しています。データの永続性のためのルールは、基礎となるMIBモジュールのものと同じ規則に従うべきです。 ciCircuitObjectによって定義された回路は、通常、不揮発性メモリに記憶される場合、例えば、次にciCircuitEntryは、非揮発性であるべきです。
There is no required relation to the Frame Relay DTE MIB beyond the fact that rows in the frCircuitTable MAY be referenced. However, if frCircuitLogicalIfIndex is being used to represent the same information as a ciCircuitEntry with a value of ciCircuitFlow equal to both(3), the implementation MAY use the same ifIndex.
frCircuitTableの行が参照される可能性があるという事実を超えたフレームリレーDTE MIBへの必要な関係はありません。 frCircuitLogicalIfIndex（3）の両方に等しいciCircuitFlowの値とciCircuitEntryと同じ情報を表すために使用されている場合は、実装が同じのifIndexを使用するかもしれません。
There is no explicit relation to the Frame Relay Service MIB beyond the fact that a rows in the frPVCEndptTable MAY be referenced.
frPVCEndptTableの行が参照される可能性があるという事実を超えたフレームリレーサービスMIBへの明示的な関係はありません。
There is no explicit relation to the ATM MIB beyond the fact that rows in multiple tables may be referenced.
複数のテーブルの行を参照することができるという事実を超えたATM MIBへの明示的な関係はありません。
The following specifies how the Interfaces Group defined in the IF-MIB will be used for the management of interfaces created by this MIB module.
以下は、IF-MIBで定義されたインタフェースのグループがこのMIBモジュールによって作成されたインタフェースの管理に使用される方法を指定します。
Values of specific ifTable objects for circuit interfaces are as follows:
次のように回路インターフェイスの特定のifTableオブジェクトの値は次のとおりです。
Object Name Value of Object
=========== =====================================================
ifIndex Each entry in the circuit table is represented by an ifEntry. The value of ifIndex is defined by the agent such that it complies with any internal numbering scheme.
回路テーブルのifIndexの各エントリはますifEntryによって表されます。 ifIndexの値は、それが任意の内部ナンバリングスキームに準拠するようにエージェントによって定義されます。
ifType The value of ifType is specific to the type of circuit desired. For example, the value for frame relay virtual circuits is frDlciEndPt(193) and the value for ATM virtual circuits is atmVciEndPt(194). If the circuit is to be used in RMON, propVirtual(53) SHOULD NOT be used.
ifTypeのifTypeの値は、所望の回路のタイプに特異的です。例えば、フレームリレー仮想回線の値はfrDlciEndPt（193）であり、ATM仮想回線の値はatmVciEndPt（194）です。回路は、RMON、propVirtual（53）で使用される場合に使用されるべきではありません。
ifMtu Set to the size in octets of the largest packet, frame or PDU supported on the circuit. If this is not known to the ifMtu object shall be set to zero. If the circuit is not modeled as a packet-oriented interface, this object SHOULD NOT be supported and result in noSuchInstance.
回路上でサポートされる最大パケット、フレームまたはPDUのオクテットでサイズに設定ifMtu。これはifMtuオブジェクトに知られていない場合はゼロに設定されなければなりません。回路は、パケット指向のインタフェースとしてモデル化されていない場合、このオブジェクトはサポートされており、noSuchInstanceになるべきではありません。
ifSpeed The peak bandwidth in bits per second available for use. This will equal either the ifSpeed of the logical link if policing is not enforced or the maximum information rate otherwise. If neither is known, the ifSpeed object shall be set to zero.
使用するために秒あたりのビット数のピーク帯域幅が利用できるのifSpeed。これは、そうでなければ、論理リンクのifSpeedポリシングが適用されていない場合、または最大情報レートのいずれかに等しくなります。どちらも知られている場合は、のifSpeedオブジェクトはゼロに設定されなければなりません。
ifPhysAddress This will always be an octet string of zero length.
ますifPhysAddressこれは常にゼロ長さのオクテット文字列になります。
ifInOctets The number of octets received by the network (ingress) for this circuit. This counter should count only octets included the header information and user data. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
この回路のネットワーク（入力）によって受信されたオクテットの数のifInOctets。唯一のオクテットを数える必要があります。このカウンタは、ヘッダ情報とユーザデータが含まれています。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifInUcastPkts The unerrored number of frames, packets or PDUs received by the network (ingress) for this circuit. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
この回路のネットワーク（入力）によって受信されたフレーム、パケットまたはPDUのunerrored数ifInUcastPkts。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifInDiscards The number of received frames, packets or PDUs for this circuit discarded due to ingress buffer congestion and traffic policing. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
ifInDiscardsによる入力バッファの輻輳とトラフィックポリシングに廃棄この回路の受信されたフレーム、パケットまたはPDUの数。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifInErrors The number of received frames, packets or PDUs for this circuit that are discarded because of an error. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
ifInErrorsエラーのために廃棄されるこの回路の受信されたフレーム、パケットまたはPDUの数。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifOutOctets The number of octets sent by the network (egress) for this circuit. This counter should count only octets included the header information and user data. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
この回路のネットワーク（出口）によって送信されたオクテットの数をifOutOctets。唯一のオクテットを数える必要があります。このカウンタは、ヘッダ情報とユーザデータが含まれています。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifOutUcastpkts The number of unerrored frames, packets or PDUs sent by the network (egress) for this circuit. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
この回路のネットワーク（出口）によって送らunerroredフレーム、パケットまたはPDUの数をifOutUcastpkts。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifOutDiscards The number of frames, packets or PDUs discarded in the egress direction for this circuit. Possible reasons are as follows: policing, congestion. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
フレーム、パケット又はこの回路の出力方向で廃棄されたPDUの数をifOutDiscards。ポリシング、輻輳を次のように考えられる理由があります。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifOutErrors The number of frames, packets or PDUs discarded for this circuit in the egress direction because of an error. If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
エラーのために出力方向に、この回路のために廃棄されたフレーム、パケットまたはPDUの数をifOutErrors。デバイスは、回路の統計情報をサポートしていない場合、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifInBroadcastPkts If the device does not support statistics on the circuit, this object MUST NOT be supported and result in noSuchInstance.
デバイスは、回路の統計情報をサポートしていない場合ifInBroadcastPktsは、このオブジェクトはサポートされており、noSuchInstanceにつながるしてはなりません。
ifOutBroadcastPkts If the device does not support Broadcast packets on the circuit, this object should not be supported and result in noSuchInstance.
デバイスは、回路上のブロードキャストパケットをサポートしていない場合はifOutBroadcastPktsは、このオブジェクトはサポートされており、noSuchInstanceになるべきではありません。
ifLinkUpDownTrapEnable Set to false(2). Circuits often have a predefined notification mechanism. In such instances, the number of notification sent would be doubled if this were enabled.
falseには、ifLinkUpDownTrapEnableセット（2）。回路は、多くの場合、事前に定義された通知メカニズムを持っています。これが有効になった場合にそのような例では、送信される通知の数を2倍にすることになります。
ifPromiscuousMode Set to false(2). If the circuit is not modeled as a packet-oriented interface, this object SHOULD NOT be supported and result in noSuchInstance.
（2）は、falseに設定しifPromiscuousMode。回路は、パケット指向のインタフェースとしてモデル化されていない場合、このオブジェクトはサポートされており、noSuchInstanceになるべきではありません。
ifConnectorPresent Set to false(2).
falseにifConnectorPresentセット（2）。
All other values are supported as stated in the IF-MIB documentation.
IF-MIBのドキュメントに記載されているように他のすべての値がサポートされています。
This section describes by example how to use ifStackTable to represent the relationship between circuit and logical link interfaces.
このセクションでは、回路及び論理リンクインターフェイスとの間の関係を表現するためのifStackTableを使用する方法の例で説明しています。
Example 1: Circuits (C) on a frame relay logical link.
実施例1：フレームリレー論理リンク上の回路（C）。
+---+ +---+ +---+
| C | | C | | C |
+-+-+ +-+-+ +-+-+
| | |
+---+------+------+---+
| Frame Relay Service |
+----------+----------+
|
+----------+----------+
| Physical Layer |
+---------------------+
The assignment of the index values could for example be (for a V35 physical interface):
インデックス値の割り当ては、例えば、（V35物理インターフェイスの場合）とすることができます。
ifIndex Description
======= ===========
1 frDlciEndPt (type 193)
2 frDlciEndPt (type 193)
3 frDlciEndPt (type 193)
4 frameRelayService (type 44)
5 v35 (type 33)
The ifStackTable is then used to show the relationships between each interface.
ifStackTableには、各インタフェースの関係を示すために使用されます。
HigherLayer LowerLayer
=========== ==========
0 1
0 2
0 3
1 4
2 4
3 4
4 5
5 0
In the above example the frame relay logical link could just as easily be of type frameRelay(32) instead.
上記の例では、フレームリレー論理リンクは、同じように簡単に代わり型フレームリレー（32）であってもよいです。
Example 2: Circuits (C) on a AAL5 logical link.
実施例2：AAL5論理リンク上の回路（C）。
+---+ +---+ +---+
| C | | C | | C |
+-+-+ +-+-+ +-+-+
| | |
+---+------+------+---+
| AAL5 Layer |
+----------+----------+
|
+----------+----------+
| ATM Layer |
+---------------------+
|
+----------+----------+
| Physical Layer |
+---------------------+
The assignment of the index values could for example be (for a DS3 physical interface):
インデックス値の割り当ては、例えば、（DS3物理インターフェイスの場合）とすることができます。
ifIndex Description
======= ===========
1 atmVciEndPt (type 194)
2 atmVciEndPt (type 194)
3 atmVciEndPt (type 194)
4 aal5 (type 49)
5 atm (type 37)
6 ds3 (type 30)
The ifStackTable is then used to show the relationships between each interface.
ifStackTableには、各インタフェースの関係を示すために使用されます。
HigherLayer LowerLayer
=========== ==========
0 1
0 2
0 3
1 4
2 4
3 4
4 5
5 6
6 0
There is no explicit relation to any other media specific MIB module beyond the fact that rows in multiple tables may be referenced.
複数のテーブルの行を参照することができるという事実を越える他のメディアの特定のMIBモジュールへの明示的な関係はありません。
The CIRCUIT-IF-MIB consists of the following components:
CIRCUIT-IF-MIBは、次のコンポーネントで構成されています。
o ciCircuitTable
O ciCircuitTable
o ciIfMapTable
O ciIfMapTable
Refer to the compliance statement defined within for a definition of what objects MUST be implemented.
オブジェクトが実装しなければならないものの定義については、内に定義されたコンプライアンス声明を参照してください。
The ciCircuitTable is the central control table for operations of the Circuit Interfaces MIB. It provides a means of mapping a circuit to its ifIndex as well as forcing the insertion of an ifIndex into the ifTable. The agent is responsible for managing the ifIndex itself such that no device dependent indexing scheme is violated.
ciCircuitTable回路インターフェイスMIBの操作のための中央制御テーブルです。それはifIndexのに回路をマッピング並びにのifTableへのifIndexの挿入を強制する手段を提供します。エージェントには、デバイスに依存するインデックススキームが破られていないようなのifIndex自体を管理する責任があります。
A row in this table MUST exist in order for a row to exist in any other table in this MIB module.
この表の行は、このMIBモジュール内の他のテーブルに存在する行のために存在する必要があります。
This table maps the ifIndex back to the circuit that it is associated with.
このテーブルには戻って、それが関連付けられている回路へのifIndexをマッピングします。
CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Gauge32 FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, TimeStamp, RowPointer, StorageType FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF ifIndex, InterfaceIndex FROM IF-MIB;
IF- FROMのSNMPv2-CONFのifIndex、InterfaceIndexのFROMのSNMPv2-TCのMODULE-COMPLIANCE FROMのSNMPv2-SMIテキストの表記法、RowStatusのタイムスタンプ、RowPointer、StorageTypeからの輸入MODULE-IDENTITY、OBJECT-TYPE、MIB-2、Gauge32、オブジェクト・グループMIB;
circuitIfMIB MODULE-IDENTITY
LAST-UPDATED "200201030000Z" -- January 3, 2002
ORGANIZATION "IETF Frame Relay Service MIB Working Group"
CONTACT-INFO
"IETF Frame Relay Service MIB (frnetmib) Working Group
「IETFフレームリレーサービスMIB（frnetmib）ワーキンググループ
WG Charter: http://www.ietf.org/html.charters/ frnetmib-charter.html WG-email: frnetmib@sunroof.eng.sun.com Subscribe: frnetmib-request@sunroof.eng.sun.com Email Archive: ftp://ftp.ietf.org/ietf-mail-archive/frnetmib
WG憲章：http://www.ietf.org/html.charters/ frnetmib-charter.html WG-メール：frnetmib@sunroof.eng.sun.com購読：frnetmib-request@sunroof.eng.sun.comメールアーカイブ：ftp://ftp.ietf.org/ietf-mail-archive/frnetmib
Chair: Andy Malis Vivace Networks Email: Andy.Malis@vivacenetworks.com
司会：アンディMalisヴィヴァーチェネットワークEメール：Andy.Malis@vivacenetworks.com
WG editor: Robert Steinberger Paradyne Networks and Fujitsu Network Communications Email: robert.steinberger@fnc.fujitsu.com
WGエディタ：ロバート・シュタインパラダインネットワークと富士通ネットワークコミュニケーションズEメール：robert.steinberger@fnc.fujitsu.com
Co-author: Orly Nicklass
RAD Data Communications Ltd.
EMail: Orly_n@rad.co.il"
DESCRIPTION
"The MIB module to allow insertion of selected circuit into
the ifTable."
REVISION "200201030000Z" -- January 3, 2002
DESCRIPTION
"Initial version, published as RFC 3201"
::= { mib-2 94 }
-- Textual Conventions
- テキストの表記法
CiFlowDirection ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The direction of data flow thru a circuit.
transmit(1) - Only transmitted data
receive(2) - Only received data
both(3) - Both transmitted and received data."
SYNTAX INTEGER {
transmit(1),
receive(2),
both(3)
}
ciObjects OBJECT IDENTIFIER ::= { circuitIfMIB 1 }
ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 }
ciConformance OBJECT IDENTIFIER ::= { circuitIfMIB 3 }
-- The Circuit Interface Circuit Table -- -- This table is used to define and display the circuits that -- are added to the ifTable. It maps circuits to their respective -- ifIndex values.
- 回線インタフェース回路表 - - のifTableに追加される - このテーブルは、回路を定義し、表示するために使用されます。 ifIndex値 - それは、それぞれに回路をマッピングします。
ciCircuitTable OBJECT-TYPE
SYNTAX SEQUENCE OF CiCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Circuit Interface Circuit Table."
::= { ciObjects 1 }
ciCircuitEntry OBJECT-TYPE
SYNTAX CiCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Circuit Interface Circuit Table."
INDEX { ciCircuitObject, ciCircuitFlow }
::= { ciCircuitTable 1 }
CiCircuitEntry ::=
SEQUENCE {
--
-- Index Control Variables
--
ciCircuitObject RowPointer,
ciCircuitFlow CiFlowDirection,
ciCircuitStatus RowStatus,
--
-- Data variables
--
ciCircuitIfIndex InterfaceIndex,
ciCircuitCreateTime TimeStamp,
--
-- Data Persistence
--
ciCircuitStorageType StorageType
}
ciCircuitObject OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value contains the RowPointer that uniquely
ciCircuitObject OBJECT-TYPE SYNTAX RowPointer MAX-ACCESSステータス現在の説明は「この値は一意にRowPointerが含まれています
describes the circuit that is to be added to this table.
Any RowPointer that will force the size of OBJECT
IDENTIFIER of the row to grow beyond the legal limit
MUST be rejected.
The purpose of this object is to point a network manager to the table in which the circuit was created as well as define the circuit on which the interface is defined.
このオブジェクトの目的は、回路の作成ならびにインタフェースが定義されている回路を定義したテーブルにネットワークマネージャを指すようになります。
Valid tables for this object include the frCircuitTable
from the Frame Relay DTE MIB(FRAME-RELAY-DTE-MIB), the
frPVCEndptTable from the Frame Relay Service MIB
(FRNETSERV-MIB), and the aal5VccTable from the ATM MIB
(ATM MIB). However, including circuits from other MIB
tables IS NOT prohibited."
::= { ciCircuitEntry 1 }
ciCircuitFlow OBJECT-TYPE SYNTAX CiFlowDirection MAX-ACCESS not-accessible STATUS current DESCRIPTION "The direction of data flow through the circuit for which the virtual interface is defined. The following define the information that the virtual interface will report.
ciCircuitFlow OBJECT-TYPE構文CiFlowDirection MAX-ACCESSステータス現在の説明は「仮想インタフェースが定義されている回路を通るデータフローの方向。以下では、仮想インタフェースが報告されている情報を定義します。
transmit(1) - Only transmitted frames
receive(2) - Only received frames
both(3) - Both transmitted and received frames.
It is recommended that the ifDescr of the circuit
interfaces that are not both(3) SHOULD have text warning
the operators that the particular interface represents
only half the traffic on the circuit."
::= { ciCircuitEntry 2 }
ciCircuitStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the current row. This object is used to add, delete, and disable rows in this table. When the status changes to active(1), a row will also be added to the interface map table below and a row will be added to the ifTable. These rows SHOULD not be removed until the status is changed from active(1). The value of ifIndex for the row that is added to the ifTable is determined by the agent and MUST follow the rules of the ifTable. The value of ifType for that interface will be frDlciEndPt(193) for a frame relay circuit, atmVciEndPt(194) for an ATM circuit, or another ifType defining the circuit type for any other circuit.
ciCircuitStatusのOBJECT-TYPE構文RowStatus MAX-ACCESSはリード作成ステータス現在の説明「現在の行のステータス。このオブジェクトは、このテーブルの行を追加、削除、および無効化するために使用される。アクティブ（1）の場合のステータス変化を行は、以下のインターフェース・マップ・テーブルに追加され、行はifTableのに追加されます。状態は、（1）アクティブに変更されるまで、これらの行が削除されるべきではない。に追加された行のifIndexの値ifTableのエージェントによって決定されますifTableの規則に従わなければならない。そのインターフェイスのためのifTypeの値は、フレームリレー回路のfrDlciEndPt（193）、atmVciEndPt（194）ATM回路のための、または回路のタイプを定義する別のifTypeであろう他の回路のため。
When this object is set to destroy(6), the associated
row in the interface map table will be removed and the
ifIndex will be removed from the ifTable. Removing
the ifIndex MAY initiate a chain of events that causes
changes to other tables as well.
The rows added to this table MUST have a valid object identifier for ciCircuitObject. This means that the referenced object must exist and it must be in a table that supports circuits.
この表に追加された行はciCircuitObjectのための有効なオブジェクト識別子を持たなければなりません。これは、参照されるオブジェクトが存在しなければならないことを意味し、それは回線をサポートし、テーブル内になければなりません。
The object referenced by ciCircuitObject MUST exist prior to transitioning a row to active(1). If at any point the object referenced by ciCircuitObject does not exist or the row containing it is not in the active(1) state, the status SHOULD either age out the row or report notReady(3). The effects transitioning from active(1) to notReady(3) are the same as those caused by setting the status to destroy(6).
ciCircuitObjectによって参照されるオブジェクトは、従来のアクティブ（1）に行を移行に存在しなければなりません。任意の時点でciCircuitObjectによって参照されるオブジェクトが存在しないか、それを含む行が、アクティブ（1）状態でない場合、ステータスは、行アウト年齢またはいずれかが準備中に報告しなければならない（3）。アクティブから遷移効果は、（1）準備中に（3）（6）を破壊するためにステータスを設定することによって引き起こされたものと同じです。
Each row in this table relies on information from other
MIB modules. The rules persistence of data SHOULD follow
the same rules as those of the underlying MIB module.
For example, if the circuit defined by ciCircuitObject
would normally be stored in non-volatile memory, then
the row SHOULD also be non-volatile."
::= { ciCircuitEntry 3 }
ciCircuitIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex that the agent assigns to this row."
::= { ciCircuitEntry 4 }
ciCircuitCreateTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION
ciCircuitCreateTimeのOBJECT-TYPE構文タイムスタンプMAX-ACCESS read-onlyステータス現在の説明
"This object returns the value of sysUpTime at the time
the value of ciCircuitStatus last transitioned to
active(1). If ciCircuitStatus has never been active(1),
this object SHOULD return 0."
::= { ciCircuitEntry 5 }
ciCircuitStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type used for this row."
::= { ciCircuitEntry 6 }
-- The Circuit Interface Map Table -- -- This table maps the ifIndex values that are assigned to -- rows in the circuit table back to the objects that define -- the circuits.
- 回線インタフェースマップ表 - - 回路 - 定義オブジェクトにバック回路テーブルの行 - この表はに割り当てられたifIndex値をマッピングします。
ciIfMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF CiIfMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Circuit Interface Map Table."
::= { ciObjects 2 }
ciIfMapEntry OBJECT-TYPE
SYNTAX CiIfMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry in the Circuit Interface Map Table."
INDEX { ifIndex }
::= { ciIfMapTable 1 }
CiIfMapEntry ::=
SEQUENCE {
--
-- Mapped Object Variables
--
ciIfMapObject RowPointer,
ciIfMapFlow CiFlowDirection
}
ciIfMapObject OBJECT-TYPE SYNTAX RowPointer
ciIfMapObjectのOBJECT-TYPE SYNTAX RowPointer
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value contains the value of RowPointer that
corresponds to the current ifIndex."
::= { ciIfMapEntry 1 }
ciIfMapFlow OBJECT-TYPE
SYNTAX CiFlowDirection
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value contains the value of ciCircuitFlow that
corresponds to the current ifIndex."
::= { ciIfMapEntry 2 }
-- Change tracking metrics
- 変更の追跡指標
ciIfLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the most recent change to
ciCircuitStatus for any row in ciCircuitTable."
::= { ciObjects 3 }
ciIfNumActive OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of active rows in ciCircuitTable."
::= { ciObjects 4 }
-- Conformance Information
- 適合情報
ciMIBGroups OBJECT IDENTIFIER ::= { ciConformance 1 }
ciMIBCompliances OBJECT IDENTIFIER ::= { ciConformance 2 }
-- -- Compliance Statements --
- - コンプライアンスステートメント -
ciCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities
ciCompliance MODULE-COMPLIANCEステータス現在の説明「SNMPエンティティのための準拠宣言
which support of the Circuit Interfaces MIB module.
This group defines the minimum level of support
required for compliance."
MODULE -- this module
MANDATORY-GROUPS { ciCircuitGroup,
ciIfMapGroup,
ciStatsGroup }
OBJECT ciCircuitStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Row creation can be done outside of the scope of
the SNMP protocol. If this object is implemented with
max-access of read-only, then the only value that MUST
be returned is active(1)."
OBJECT ciCircuitStorageType MIN-ACCESS read-only DESCRIPTION "It is legal to support ciCircuitStorageType as read-only as long as the value reported in consistent with the actual storage mechanism employed within the agent."
OBJECT ciCircuitStorageType MIN-ACCESS読み取り専用説明は「読み取り専用限り値はエージェント内で使用される実際のストレージ・メカニズムと一致して報告されてciCircuitStorageTypeをサポートするために合法です。」
::= { ciMIBCompliances 1 }
--
-- Units of Conformance
--
ciCircuitGroup OBJECT-GROUP
OBJECTS {
ciCircuitStatus,
ciCircuitIfIndex,
ciCircuitCreateTime,
ciCircuitStorageType
}
STATUS current
DESCRIPTION
"A collection of required objects providing
information from the circuit table."
::= { ciMIBGroups 1 }
ciIfMapGroup OBJECT-GROUP OBJECTS { ciIfMapObject, ciIfMapFlow }
ciIfMapGroupオブジェクト・グループオブジェクト{ciIfMapObject、ciIfMapFlow}
STATUS current
DESCRIPTION
"A collection of required objects providing
information from the interface map table."
::= { ciMIBGroups 2 }
ciStatsGroup OBJECT-GROUP
OBJECTS {
ciIfLastChange,
ciIfNumActive
}
STATUS current
DESCRIPTION
"A collection of statistical metrics used to help manage
the ciCircuitTable."
::= { ciMIBGroups 3 }
END
This document was produced by the Frame Relay Service MIB Working Group.
この文書は、フレームリレーサービスMIBワーキンググループによって作成されました。
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1]ハリントン、D.、PresuhnとR.とB. Wijnen、、RFC 2571、1999年4月 "SNMP管理フレームワークを記述するためのアーキテクチャ"。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[2]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月を。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[3]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[4]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[5] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "経営情報バージョン2（SMIv2）の構造"、STD 58、RFC 2578、 1999年4月。
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[6] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[7] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、STD 58、RFC 2580、1999年4月 "SMIv2のための順応文"。
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[8]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン、 "簡単なネットワーク管理プロトコル"、STD 15、RFC 1157、1990年5月。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[9]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "コミュニティベースのSNMPv2の概要"、RFC 1901、1996年1月。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS. Waldbusser、RFC 1906 "簡易ネットワーク管理プロトコル（SNMPv2）のバージョン2のための交通マッピング"、1996年1月。
[11] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[11]ケース、J.、ハリントン、D.、PresuhnとR.とB. Wijnen、 "メッセージ処理と簡単なネットワーク管理プロトコル（SNMP）のための派遣"、RFC 2572、1999年4月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[12]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、RFC 2574、1999年4月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[13]ケース、J.、McCloghrie、K.、ローズ、M.およびS. Waldbusser、 "簡単なネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[14]レビ、D.、マイヤー、P.およびB.スチュワート、 "SNMPv3のアプリケーション"、RFC 2573、1999年4月。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[15] Wijnenの、B.、Presuhn、R.とK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、RFC 2575、1999年4月。
[16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[16]ケース、J.、マンディ、R.、パーテイン、D.とB.スチュワート、 "インターネット標準ネットワーク管理フレームワークのバージョン3への序論"、RFC 2570、1999年4月。
[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[17] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
[18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for Frame Relay Service", RFC 2954, October 2000.
[18] Rehbehn、K.、およびD.ファウラー、 "フレームリレーサービスのための管理オブジェクトの定義"、RFC 2954、2000年10月。
[19] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[19] Waldbusser、S.、 "SMIv2のを使用してリモートネットワーク監視管理情報ベースバージョン2"、RFC 2021、1997年1月。
[20] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997.
[20]ブラウン、C.およびF.ベイカー、 "SMIv2のを使用してフレームリレーのDTEのための管理情報ベース"、RFC 2115、1997年9月。
[21] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[21]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[22] Tesink, K., "Definitions of Managed Objects for ATM Management", RFC 2515, February 1999.
[22] Tesink、K.、RFC 2515、1999年2月、 "ATMの管理のための管理オブジェクトの定義"。
[23] Waldbusser, S., "Remote Network Monitoring Management Information Base", RFC 2819, May 2000.
[23] Waldbusser、S.、 "管理情報ベースのリモートネットワーク監視"、RFC 2819、2000年5月。
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
読み書きおよび/またはリード作成のMAX-ACCESS節を持っているこのMIBで定義された管理オブジェクトの数があります。そのようなオブジェクトは、いくつかのネットワーク環境に敏感又は脆弱と考えることができます。適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響を与える可能性があります。
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.
それ自体でSNMPv1が安全な環境ではありません。ネットワーク自体が（IPSecを使用することにより、例えば）安全であっても、その後も、安全なネットワーク上で/ SETにアクセスし、GETだれに許容されているかのように何の制御（読み取り/変更/作成/削除）この内のオブジェクトが存在しませんMIB。
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2274 [12] and the View-based Access Control Model RFC 2275 [15] is recommended.
SNMPv3フレームワークで提供するように実装は、セキュリティ機能を検討することをお勧めします。具体的には、ユーザベースセキュリティモデルのRFC 2274 [12]とビューベースアクセス制御モデルRFC 2275 [15]の使用が推奨されます。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
このMIBのインスタンスへのアクセスを与えるSNMP実体が、適切にのみプリンシパル（ユーザ）にオブジェクトへのアクセスを提供するように設定されていることを確認するために、顧客/ユーザーの責任実際にGETまたはSET（変化への正当な権利を有することです/）/削除、それらを作成します。
New ifTypes defined specifically for use in this MIB module SHOULD be in the form of ***EndPt. This is similar to frDlciEndPt(193) and atmVciEndPt(194) which are already defined.
このMIBモジュールで使用するために特別に定義された新ifTypesはENDPT ***の形式でなければなりません。これは、既に定義されているfrDlciEndPt（193）とatmVciEndPt（194）と同様です。
Robert Steinberger Fujitsu Network Communications 2801 Telecom Parkway Richardson, TX 75082
ロバート・シュタイン富士通ネットワークコミュニケーションズ2801テレコムパークウェイ・リチャードソン、TX 75082
Phone: 1-972-479-4739 EMail: robert.steinberger@fnc.fujitsu.com
電話：1-972-479-4739 Eメール：robert.steinberger@fnc.fujitsu.com
Orly Nicklass, Ph.D RAD Data Communications Ltd. 12 Hanechoshet Street Tel Aviv, Israel 69710
オルリーNicklass、博士RADデータ・コミュニケーションズ（株）12 Hanechoshetストリートテルアビブ、イスラエル69710
Phone: 972 3 7659969 EMail: Orly_n@rad.co.il
電話：972 3 7659969 Eメール：Orly_n@rad.co.il
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。