RFC3201 日本語訳
3201 Definitions of Managed Objects for Circuit to InterfaceTranslation. R. Steinberger, O. Nicklass. January 2002. (Format: TXT=45583 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Steinberger
Request for Comments: 3201 Paradyne Networks
Category: Standards Track O. Nicklass
RAD Data Communications Ltd.
January 2002
コメントを求めるワーキンググループR.シュタインバーガーの要求をネットワークでつないでください: 3201Paradyneはカテゴリをネットワークでつなぎます: 規格はデータ通信株式会社2002年1月にO.Nicklass radを追跡します。
Definitions of Managed Objects
for Circuit to Interface Translation
回路が翻訳を連結する管理オブジェクトの定義
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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ベースのインターネットで使用のためのManagement Information基地(MIB)の拡大を定義します。 特に、それは、おもしろいCircuit Interfacesの挿入を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
1. SNMP管理フレームワーク… 2 2. コンベンション… 3 3. 概要… 3 3.1. 回路概念… 4 3.2. 操作の理論… 4 3.2.1. 作成プロセス… 4 3.2.2. 破壊プロセス… 5 3.2.2.1. 手動の通りの破壊… 5 3.2.2.2. 自動通りの破壊… 5 3.2.3. 変更プロセス… 5 3.2.4. データの固執… 5 4. 他のMIBモジュールとの関係… 6 4.1. フレームリレーDTE MIB… 6
Steinberger & Nicklass Standards Track [Page 1] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[1ページ]RFC3201回路
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
4.2. フレームリレーサービスMIB… 6 4.3. 気圧MIB… 6 4.4. インタフェースはMIBを分類します… 6 4.4.1. インタフェースは(ifTable、ifXtable)をテーブルの上に置きます… 6 4.4.2. テーブル(ifStackTable)を積み重ねてください… 9 4.5. 他のMIBモジュール… 11 5. MIBモジュールの構造… 11 5.1ciCircuitTable… 11 5.2ciIfMapTable… 11 6. オブジェクト定義… 11 7. 承認… 19 8. 参照… 19 9. セキュリティ問題… 21 10. IANA問題… 21 11. 作者のアドレス… 22 12. 完全な著作権宣言文… 23
1. The SNMP Management Framework
1. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [1].
o RFC2571[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 オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[2]、STD16、RFC1212[3]、およびRFC1215[4]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[5]、RFC2579[6]、およびRFC2580[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メッセージプロトコルの最初のバージョンは、STD15、RFC1157[8]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[9]とRFC1906[10]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[10]、RFC2572[11]、およびRFC2574[12]でSNMPv3と呼ばれて、説明されます。
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形式の第一セットはSTD15、RFC1157[8]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[13]で説明されます。
Steinberger & Nicklass Standards Track [Page 2] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[2ページ]RFC3201回路
o A set of fundamental applications described in RFC 2573 [14] and
the view-based access control mechanism described in RFC 2575
[15].
o 1セットの基礎的応用はRFCで2573[14]について説明しました、そして、視点ベースのアクセス管理機構はRFCで2575[15]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16].
RFC2570[16]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
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.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店か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は生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
2. Conventions
2. コンベンション
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].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[21]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. Overview
3. 概要
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に加えられるのを許容する複数の理由があります。 どれで最も一般的であるかは、ipCidrRouteTableなどの標準のルーティングMIBテーブル(IP-FORWARD-MIB)とifIndexとRMON MIBsの上のipNetToMediaTable(IP-MIB)条例です。(RFC2819[23]とRFC2021[19])で定義されるRMON-MIBとRMON2-MIBはifIndex a DataSourceの使用を必要とします。
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を使用することで回路を伝えました。(RFC2021[19])は現在、流れの方向を得ません。 このMIBモジュールは流れの特定の方向に基づくインタフェースを定義する能力を提供します。
This section provides an overview and background of how to use this MIB module.
このセクションはどうこのMIBモジュールを使用するかに関する概要とバックグラウンドを提供します。
Steinberger & Nicklass Standards Track [Page 3] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[3ページ]RFC3201回路
3.1. Circuit Concepts
3.1. 回路概念
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モジュールがあります。 3つの一般的に使用されたMIBモジュールが、FRAME-RELAY-DTE-MIB(RFC2115)[20]と、FRNETSERV- MIB(RFC2954)[18]と、ATM-MIB(RFC2515)[22]です。 これらはフレームリレーDTEs、フレームリレーサービス、およびATMのためにそれぞれ管理オブジェクトを定義します。 それぞれのこれらのMIBモジュールは回路を加えるか、または削除する能力を含んでいます。 しかしながら、特定のifEntryを回路になにも作成しません。 この理由は潜在的に複数の回路があって、あらゆる回路が、個々のインタフェースとして管理される必要があるというわけではないということです。 例えば、デバイスの上のあらゆる回路が、RMONと共にモニターされる必要があるというわけではありません、そして、あらゆる回路がルーティングのための個々の回路として含まれる必要があるというわけではありません。 さらに、Interfaces Group MIB(RFC2863)[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モジュールで加えられるかもしれません。
3.2. Theory of Operation
3.2. 動作理論
3.2.1. Creation Process
3.2.1. 作成プロセス
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
上の第一歩はデバイスに存在する回路に関する何らかの知識を必要とします。 論理的なポートには、通常、エントリーがあります。
Steinberger & Nicklass Standards Track [Page 4] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[4ページ]RFC3201回路
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がframeRelay(32)であるなら、回路はFrame Relay DTE MIB(FRAME-RELAY-DTE-MIB)[18]のfrCircuitTableに位置できます。 論理的なポートへのifTypeが別の例としてframeRelayService(44)であるなら、回路はFrame Relay Service MIB(FRNETSERV-MIB)[20]のfrPVCEndptTableに位置できます。 論理的なポートへのifTypeが最終的な例としてaal5(49)であるなら、回路はATM MIB(ATM-MIB)[22]のaal5VccTableに位置できます。 ciCircuitTableの行を作成する前に、回路について説明するエントリーはあるテーブルに存在しなければなりません。 回路定義に使用しなければならないオブジェクト識別子は回路について完全に説明する辞書編集に最も小さいアクセスしやすいOIDです。
3.2.2. Destruction Process
3.2.2. 破壊プロセス
3.2.2.1. Manual Row Destruction
3.2.2.1. 手動の通りの破壊
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.
手動の行破壊は前方でまっすぐです。 どんな行も破壊できます、そして、状態オブジェクト(ciCircuitStatus)の値に(6)を破壊するように設定することによって、それに割り当てられたリソースは解放されます。 ciCircuitStatusがいつかが(6) ifTableのすべての関連行を破壊するためにセットして、また、ciIfMapTableで破壊されることに注意されるべきです。 このプロセスはまた、他のテーブルでさらなる行破壊の引き金となるかもしれません。
3.2.2.2. Automatic Row Destruction
3.2.2.2. 自動通りの破壊
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.
テーブルの通りは彼らが当てにする回路の存在に基づいて自動的に破壊されるかもしれません。 回路がもうデバイスに存在していない場合、テーブルのデータはネットワークで知られているものは何にも関係がありません。 この理由で、関連回路がもう存在しないと発見されるとすぐに、このテーブルから行を取り除かなければなりません。 自動行破壊の効果は手動の行破壊と同じです。
3.2.3. Modification Process
3.2.3. 変更プロセス
Since no objects in the MIB module can be changed once rows are active, there are no modification caveats.
行がいったんアクティブになるとMIBモジュールによるオブジェクトを全く変えることができないので、変更警告が全くありません。
3.2.4. Persistence of Data
3.2.4. データの固執
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モジュールからの情報を当てにします。 データSHOULDの固執のための規則は基本的なMIBモジュールのものと同じ規則に従います。 例えば、ciCircuitObjectによって定義された回路が通常そうするなら、次に、非揮発性メモリー、ciCircuitEntry SHOULDに保存されてください、そして、また、非揮発性になってください。
Steinberger & Nicklass Standards Track [Page 5] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[5ページ]RFC3201回路
4. Relation to Other MIB Modules
4. 他のMIBモジュールとの関係
4.1. Frame Relay DTE MIB
4.1. フレームリレーDTE MIB
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.
Frame Relay DTE MIBとのどんな必要な関係もfrCircuitTableの行が参照をつけられるかもしれないという事実を超えていません。 しかしながら、frCircuitLogicalIfIndexが両方と等しいciCircuitFlowの値でciCircuitEntryと同じ情報を表すのに使用されているなら、(3)、実装は同じifIndexを使用するかもしれません。
4.2. Frame Relay Service MIB
4.2. フレームリレーサービスMIB
There is no explicit relation to the Frame Relay Service MIB beyond the fact that a rows in the frPVCEndptTable MAY be referenced.
Frame Relay Service MIBとのどんな明白な関係もfrPVCEndptTableの行が参照をつけられるかもしれないという事実を超えていません。
4.3. ATM MIB
4.3. 気圧MIB
There is no explicit relation to the ATM MIB beyond the fact that rows in multiple tables may be referenced.
ATM MIBとのどんな明白な関係も複数のテーブルの行が参照をつけられるかもしれないという事実を超えていません。
4.4. Interfaces Group MIB
4.4. グループMIBを連結します。
4.4.1. Interfaces Table (ifTable, ifXtable)
4.4.1. テーブルを連結します。(ifTable、ifXtable)
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.
以下がInterfaces Groupがどうコネを定義したかを指定する、-、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 Eachエントリーは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) SHOULDで使用されるには、使用されないでください。
Steinberger & Nicklass Standards Track [Page 6] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[6ページ]RFC3201回路
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 Set。 これがifMtuにおいて知られていないなら、オブジェクトはゼロに設定されるものとします。 回路がパケット指向のインタフェースとしてモデル化されないなら、このオブジェクトSHOULD NOTはサポートされて、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.
使用に利用可能なbpsにおけるピーク帯域幅をifSpeedしました。 これはそうでなければ、取り締まりが実施されていなくて最大の情報レートであるなら論理的なリンクのifSpeedと等しいでしょう。 どちらも知られていないなら、ifSpeedオブジェクトはゼロに設定されるものとします。
ifPhysAddress This will always be an octet string of zero length.
ifPhysAddress Thisはいつもゼロ・レングスの八重奏ストリングになるでしょう。
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.
ネットワーク(イングレス)でフレーム、パケットまたはPDUsの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.
この回路への容認されたフレーム、パケットまたはPDUsの数がイングレスのため捨てたifInDiscardsは混雑とトラフィックの取り締まりをバッファリングします。 デバイスが回路における統計をサポートしないなら、このオブジェクトは、サポートされて、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、この回路への誤りのために捨てられる容認されたフレーム、パケットまたはPDUsの数。 デバイスが回路における統計をサポートしないなら、このオブジェクトは、サポートされて、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をもたらしてはいけません。
Steinberger & Nicklass Standards Track [Page 7] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[7ページ]RFC3201回路
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フレーム、パケットまたはPDUsの数が送った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.
フレーム、パケットまたはPDUsの数がこの回路のために出口の方向に捨てた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.
フレーム、パケットまたはPDUsの数が誤りのために出口の方向でこの回路に捨てたifOutErrors。 デバイスが回路における統計をサポートしないなら、このオブジェクトは、サポートされて、noSuchInstanceをもたらしてはいけません。
ifInBroadcastPkts
If the device does not support statistics on the
circuit, this object MUST NOT be supported and result
in noSuchInstance.
デバイスがするifInBroadcastPkts Ifが回路における統計をサポートしないで、このオブジェクトは、サポートされて、noSuchInstanceをもたらしてはいけません。
ifOutBroadcastPkts
If the device does not support Broadcast packets on
the circuit, this object should not be supported and
result in noSuchInstance.
デバイスがするifOutBroadcastPkts Ifが回路の上にBroadcastにパケットをサポートしないで、このオブジェクトは、サポートされて、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.
誤った(2)へのifLinkUpDownTrapEnable Set。 回路には、事前に定義された通知メカニズムがしばしばあります。 そういった場合には、これが可能にされるなら、送られた通知の数は倍にされるでしょうに。
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)へのifPromiscuousMode Set。 回路がパケット指向のインタフェースとしてモデル化されないなら、このオブジェクトSHOULD NOTはサポートされて、noSuchInstanceをもたらします。
ifConnectorPresent
Set to false(2).
誤った(2)へのifConnectorPresent Set。
All other values are supported as stated in the IF-MIB documentation.
他のすべての値が中で述べられるとしてサポートされる、-、MIB、ドキュメンテーション。
Steinberger & Nicklass Standards Track [Page 8] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[8ページ]RFC3201回路
4.4.2. Stack Table (ifStackTable)
4.4.2. スタックテーブル(ifStackTable)
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 |
+---------------------+
+---+ +---+ +---+ | C| | C| | C| +-+-+ +-+-+ +-+-+ | | | +---+------+------+---+ | フレームリレーサービス| +----------+----------+ | +----------+----------+ | 物理的な層| +---------------------+
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)
ifIndex記述======= =========== 1 frDlciEndPt(193をタイプする)2frDlciEndPt(193をタイプする)3frDlciEndPt(193をタイプする)4frameRelayService(44をタイプする)5v35(タイプ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
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.
上記の例には、タイプframeRelay(32)にはフレームリレーの論理的なリンクが代わりにただ同じくらい容易にあるかもしれません。
Steinberger & Nicklass Standards Track [Page 9] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[9ページ]RFC3201回路
Example 2: Circuits (C) on a AAL5 logical link.
例2: AAL5で論理的な回路(C)はリンクされます。
+---+ +---+ +---+
| C | | C | | C |
+-+-+ +-+-+ +-+-+
| | |
+---+------+------+---+
| AAL5 Layer |
+----------+----------+
|
+----------+----------+
| ATM Layer |
+---------------------+
|
+----------+----------+
| Physical Layer |
+---------------------+
+---+ +---+ +---+ | C| | C| | C| +-+-+ +-+-+ +-+-+ | | | +---+------+------+---+ | AAL5層| +----------+----------+ | +----------+----------+ | 気圧層| +---------------------+ | +----------+----------+ | 物理的な層| +---------------------+
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)
ifIndex記述======= =========== 1 atmVciEndPt(194をタイプする)2atmVciEndPt(194をタイプする)3atmVciEndPt(194をタイプする)4aal5(49をタイプする)5気圧(37をタイプする)6ds3(タイプ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
HigherLayer LowerLayer=========== ========== 0 1 0 2 0 3 1 4 2 4 3 4 4 5 5 6 6 0
Steinberger & Nicklass Standards Track [Page 10] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[10ページ]RFC3201回路
4.5. Other MIB Modules
4.5. 他のMIBモジュール
There is no explicit relation to any other media specific MIB module beyond the fact that rows in multiple tables may be referenced.
参照をつけられて、複数のテーブルで船をこぐ事実を超えた特定のMIBモジュールがそうするいかなる他のメディアとのどんな明白な関係もありません。
5. Structure of the MIB Module
5. MIBモジュールの構造
The CIRCUIT-IF-MIB consists of the following components:
CIRCUIT、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.
どんなオブジェクトを実装しなければならないかに関する定義のために中で定義されていた状態で承諾声明を参照してください。
5.1. ciCircuitTable
5.1. ciCircuitTable
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はCircuit Interfaces MIBの操作のための集中管理テーブルです。 それは回路をifIndexに写像して、ifIndexの挿入をifTableに力づくで押す手段を提供します。 エージェントはifIndex自身を管理するのに責任があるので、どんなデバイスに依存するインデックス体系も違反されません。
A row in this table MUST exist in order for a row to exist in any other table in this MIB module.
このテーブルの行は、行がいかなる他のテーブルにもこのMIBモジュールで存在するように存在しなければなりません。
5.2. ciIfMapTable
5.2. ciIfMapTable
This table maps the ifIndex back to the circuit that it is associated with.
このテーブルはそれが関連して戻っている回路にifIndexを写像します。
6. Object Definitions
6. オブジェクト定義
CIRCUIT-IF-MIB DEFINITIONS ::= BEGIN
回路、MIBである、定義:、:= 始まってください。
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;
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、-、MIB、。
circuitIfMIB MODULE-IDENTITY
LAST-UPDATED "200201030000Z" -- January 3, 2002
ORGANIZATION "IETF Frame Relay Service MIB Working Group"
CONTACT-INFO
circuitIfMIBモジュールアイデンティティ最終更新日の"200201030000Z"--2002年1月3日組織「IETFフレームリレーサービスMIB作業部会」コンタクトインフォメーション
Steinberger & Nicklass Standards Track [Page 11] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[11ページ]RFC3201回路
"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: Andy.Malis@vivacenetworks.com
WG editor: Robert Steinberger
Paradyne Networks and
Fujitsu Network Communications
Email: robert.steinberger@fnc.fujitsu.com
WGエディタ: ロバートシュタインバーガーParadyneネットワークと富士通ネットワークコミュニケーションズはメールされます: 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 }
以下について共同執筆してください。 データ通信株式会社がメールするオルリーNicklass rad: " Orly_n@rad.co.il "記述、「挿入を許容するMIBモジュールは回路をifTableに選択しました」。 REVISION"200201030000Z"--「初期のバージョンであって、RFC3201として発行された」2002年1月3日記述:、:= mib-2 94
-- Textual Conventions
-- 原文のコンベンション
CiFlowDirection ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The direction of data flow thru a circuit.
CiFlowDirection:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「回路を通したデータフローの方向。」
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)
}
「(1)を伝えてください--伝えられたデータだけが(2)を受けます--データの両方を受け取るだけである、伝えられたものと(3)--同様に受信されたデータ、」 構文整数ともに(1)を送信してくださいといって、(2)を受けてください、(3)
ciObjects OBJECT IDENTIFIER ::= { circuitIfMIB 1 }
ciCapabilities OBJECT IDENTIFIER ::= { circuitIfMIB 2 }
ciConformance OBJECT IDENTIFIER ::= { circuitIfMIB 3 }
ciObjectsオブジェクト識別子:、:= circuitIfMIB1ciCapabilitiesオブジェクト識別子:、:= circuitIfMIB2ciConformanceオブジェクト識別子:、:= circuitIfMIB3
Steinberger & Nicklass Standards Track [Page 12] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[12ページ]RFC3201回路
-- 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.
-- このテーブルは回路を定義して、表示するのが使用されます。Circuit Interface Circuit Table--、--、それ--ifTableに言い足されます。 回路を写像する、それら、それぞれの--ifIndex値。
ciCircuitTable OBJECT-TYPE
SYNTAX SEQUENCE OF CiCircuitEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Circuit Interface Circuit Table."
::= { ciObjects 1 }
「回路インタフェース回路はテーブルの上に置く」ciCircuitTable OBJECT-TYPE SYNTAX SEQUENCE OF CiCircuitEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= ciObjects1
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 OBJECT-TYPE SYNTAX CiCircuitEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「Circuit Interface Circuit Tableのエントリー。」 ciCircuitObject、ciCircuitFlowに索引をつけてください:、:= ciCircuitTable1
CiCircuitEntry ::=
SEQUENCE {
--
-- Index Control Variables
--
ciCircuitObject RowPointer,
ciCircuitFlow CiFlowDirection,
ciCircuitStatus RowStatus,
--
-- Data variables
--
ciCircuitIfIndex InterfaceIndex,
ciCircuitCreateTime TimeStamp,
--
-- Data Persistence
--
ciCircuitStorageType StorageType
}
CiCircuitEntry:、:= 系列--、--インデックスControl Variables(ciCircuitObject RowPointer、ciCircuitFlow CiFlowDirection、ciCircuitStatus RowStatus)--与件変数(ciCircuitIfIndex InterfaceIndex、ciCircuitCreateTime TimeStamp)--データ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のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「そんなに唯一RowPointerを含これが評価するしています」。
Steinberger & Nicklass Standards Track [Page 13] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[13ページ]RFC3201回路
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.
このテーブルに加えられることになっている回路について説明します。 行のOBJECT IDENTIFIERのサイズがやむを得ず法的な限界を超えたところまで成長するどんなRowPointerも拒絶しなければなりません。
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 }
このオブジェクトのための有効なテーブルはFrame Relay DTE MIBからのfrCircuitTable(FRAME-RELAY-DTE-MIB)、Frame Relay Service MIBからのfrPVCEndptTable(FRNETSERV-MIB)、およびATM MIBからのaal5VccTable(ATM MIB)を含んでいます。 「しかしながら、他のMIBテーブルからの回路を含んでいるのは禁止されていません。」 ::= ciCircuitEntry1
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 SYNTAX CiFlowDirectionのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「仮想インターフェースが定義される回路を通したデータフローの方向。」 以下は仮想インターフェースが報告するという情報を定義します。
transmit(1) - Only transmitted frames
receive(2) - Only received frames
both(3) - Both transmitted and received frames.
(1)を伝えてください--伝えられたフレームだけが(2)を受けます--フレームの両方を受けるだけです。(3)--両方が、送信して、フレーム搬入しました。
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 }
「それがそれに推薦される、テキストが回路の上にトラフィックの半分だけを表すと事項が連結するオペレータに警告する(3)SHOULDにはある両方でない回路インタフェースのifDescr、」 ::= ciCircuitEntry2
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
ciCircuitStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは「電流の状態はこぐ」STATUSの現在の記述を読書して作成します。 このオブジェクトは、このテーブルの行を加えて、削除して、無効にするのに使用されます。 また、状態がアクティブな(1)に変化するとき、行は以下のインタフェース地図テーブルに加えられるでしょう、そして、行はifTableに加えられるでしょう。 これらはSHOULDを船をこいで運びます。アクティブな(1)から状態を変えるまで取り外されません。 行のためのifIndexの値、それ
Steinberger & Nicklass Standards Track [Page 14] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[14ページ]RFC3201回路
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.
加えられて、ifTableがエージェントによって決定されるということであり、ifTableの規則に従わなければなりません。 そのインタフェースへのifTypeの値は、フレームリレーサーキットのためのfrDlciEndPt(193)か、ATM回路へのatmVciEndPt(194)か、別の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.
(6)を破壊するようにこのオブジェクトを設定するとき、インタフェース地図テーブルの関連行を取り除くでしょう、そして、ifTableからifIndexを取り外すでしょう。 ifIndexを取り外すと、また、他のテーブルへの変化を引き起こす一連の出来事は開始するかもしれません。
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によって参照をつけられたオブジェクトは移行a行の前にアクティブな(1)に存在しなければなりません。 任意な点では、ciCircuitObjectによって参照をつけられたオブジェクトが存在していないか、またはそれを含む行が活動的な(1)状態にないなら、状態SHOULDは外で行の年をとるか、またはnotReady(3)を報告します。 アクティブな(1)からnotReady(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 }
このテーブルの各行は他のMIBモジュールからの情報を当てにします。 データSHOULDの規則固執は基本的なMIBモジュールのものと同じ規則に従います。 「例えば、ciCircuitObjectによって定義された回路が通常そうするなら、非揮発性メモリー、次に、行SHOULDに保存されてください、そして、また、非揮発性になってください。」 ::= ciCircuitEntry3
ciCircuitIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The ifIndex that the agent assigns to this row."
::= { ciCircuitEntry 4 }
ciCircuitIfIndex OBJECT-TYPE SYNTAX InterfaceIndexのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「エージェントがこれに割り当てるifIndexは船をこぎます」。 ::= ciCircuitEntry4
ciCircuitCreateTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
ciCircuitCreateTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Steinberger & Nicklass Standards Track [Page 15] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[15ページ]RFC3201回路
"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 }
「ciCircuitStatusの値が最後にアクティブな(1)に移行したとき、このオブジェクトはsysUpTimeの値を返します。」 「ciCircuitStatusが一度もアクティブな(1)であったことがないなら、このオブジェクトSHOULDは0を返します。」 ::= ciCircuitEntry5
ciCircuitStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type used for this row."
::= { ciCircuitEntry 6 }
ciCircuitStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「ストレージタイプはこの行に使用した」STATUSの現在の記述を読書して作成します。 ::= ciCircuitEntry6
-- 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.
-- Circuit Interface Map Table----このテーブルは--それが定義するオブジェクトへの回路テーブルの行--回路に割り当てられるifIndex値を写像します。
ciIfMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF CiIfMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The Circuit Interface Map Table."
::= { ciObjects 2 }
「回路インタフェース地図はテーブルの上に置く」ciIfMapTable OBJECT-TYPE SYNTAX SEQUENCE OF CiIfMapEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ::= ciObjects2
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 OBJECT-TYPE SYNTAX CiIfMapEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「Circuit Interface Map Tableのエントリー。」 ifIndexに索引をつけてください:、:= ciIfMapTable1
CiIfMapEntry ::=
SEQUENCE {
--
-- Mapped Object Variables
--
ciIfMapObject RowPointer,
ciIfMapFlow CiFlowDirection
}
CiIfMapEntry:、:= 系列--、ciIfMapObject RowPointer、--写像しているオブジェクト変数--ciIfMapFlow CiFlowDirection
ciIfMapObject OBJECT-TYPE
SYNTAX RowPointer
ciIfMapObjectオブジェクト・タイプ構文RowPointer
Steinberger & Nicklass Standards Track [Page 16] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[16ページ]RFC3201回路
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value contains the value of RowPointer that
corresponds to the current ifIndex."
::= { ciIfMapEntry 1 }
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「現在のifIndexに対応するRowPointerの値を含これが評価するしています」。 ::= ciIfMapEntry1
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 }
ciIfMapFlow OBJECT-TYPE SYNTAX CiFlowDirectionのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「値は現在のifIndexに対応するciCircuitFlowの値を含んでいます」。 ::= ciIfMapEntry2
-- 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 }
「いずれのためのciCircuitStatusへの最新の変化のsysUpTimeの値はciCircuitTableでこぐ」ciIfLastChange OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ciObjects3
ciIfNumActive OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of active rows in ciCircuitTable."
::= { ciObjects 4 }
「アクティブの数はciCircuitTableでこぐ」ciIfNumActive OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= ciObjects4
-- Conformance Information
-- 順応情報
ciMIBGroups OBJECT IDENTIFIER ::= { ciConformance 1 }
ciMIBCompliances OBJECT IDENTIFIER ::= { ciConformance 2 }
ciMIBGroupsオブジェクト識別子:、:= ciConformance1ciMIBCompliancesオブジェクト識別子:、:= ciConformance2
--
-- Compliance Statements
--
-- -- 承諾声明--
ciCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities
ciCompliance MODULE-COMPLIANCE STATUSの現在の記述は「SNMP実体のための承諾声明」です。
Steinberger & Nicklass Standards Track [Page 17] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[17ページ]RFC3201回路
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 }
Circuit Interfaces MIBモジュールのどのサポート。 「このグループは承諾に必要である最小のサポート水準を定義します。」 MODULE--このモジュールMANDATORY-GROUPSciCircuitGroup、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 ciCircuitStatus SYNTAX INTEGERのアクティブな(1)--「SNMPプロトコルの範囲の外で通りの作成ができる」RowStatus MIN-ACCESS書き込み禁止記述の部分集合。 「このオブジェクトが書き込み禁止の最大アクセスで実装されるなら、返さなければならない唯一の値がアクティブな(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 }
::= ciMIBCompliances1
--
-- 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 }
-- -- ユニットのConformance--、ciCircuitGroup OBJECT-GROUP OBJECTS、ciCircuitStatus、ciCircuitIfIndex、ciCircuitCreateTime、ciCircuitStorageType、「必要なオブジェクトが回路から情報を提供する収集はテーブルの上に置く」STATUSの現在の記述。 ::= ciMIBGroups1
ciIfMapGroup OBJECT-GROUP
OBJECTS {
ciIfMapObject,
ciIfMapFlow
}
ciIfMapGroupオブジェクト群対象ciIfMapObject、ciIfMapFlow
Steinberger & Nicklass Standards Track [Page 18] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[18ページ]RFC3201回路
STATUS current
DESCRIPTION
"A collection of required objects providing
information from the interface map table."
::= { ciMIBGroups 2 }
「必要なオブジェクトがインタフェース地図から情報を提供する収集はテーブルの上に置く」STATUSの現在の記述。 ::= ciMIBGroups2
ciStatsGroup OBJECT-GROUP
OBJECTS {
ciIfLastChange,
ciIfNumActive
}
STATUS current
DESCRIPTION
"A collection of statistical metrics used to help manage
the ciCircuitTable."
::= { ciMIBGroups 3 }
END
ciStatsGroup OBJECT-GROUP OBJECTS、ciIfLastChange、ciIfNumActive、「統計的な測定基準の収集はciCircuitTableを管理するのを助けるのに使用した」STATUSの現在の記述。 ::= ciMIBGroups3は終わります。
7. Acknowledgments
7. 承認
This document was produced by the Frame Relay Service MIB Working Group.
このドキュメントはFrame Relay Service MIB作業部会によって製作されました。
8. References
8. 参照
[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、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[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ベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[3] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[4] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[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)の構造」、STD58、RFC2578(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"、STD58、RFC2579、1999年4月の原文のコンベンション。」
Steinberger & Nicklass Standards Track [Page 19] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[19ページ]RFC3201回路
[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、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[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.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[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"への紹介、RFC1901、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、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、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)について議定書の中で述べます」、RFC2572、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、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、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)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.
[14] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、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)について議定書の中で述べます」、RFC2575、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への序論」RFC2570(1999年4月)。
[17] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[17]McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[18] Rehbehn, K. and D. Fowler, "Definitions of Managed Objects for
Frame Relay Service", RFC 2954, October 2000.
[18]RehbehnとK.とD.野鳥捕獲者、「フレームリレーサービスのための管理オブジェクトの定義」、RFC2954、2000年10月。
[19] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[19]Waldbusser、S.、「1997年1月にSMIv2"、RFC2021を使用するリモートネットワーク監視管理情報ベースバージョン2。」
Steinberger & Nicklass Standards Track [Page 20] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[20ページ]RFC3201回路
[20] Brown, C. and F. Baker, "Management Information Base for Frame
Relay DTEs Using SMIv2", RFC 2115, September 1997.
[20] ブラウンとC.とF.ベイカー、「1997年9月にSMIv2"、RFC2115を使用するフレームリレーDTEsのための管理情報ベース。」
[21] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[21] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[22] Tesink, K., "Definitions of Managed Objects for ATM Management",
RFC 2515, February 1999.
[22]Tesink、K.、「気圧管理のための管理オブジェクトの定義」、RFC2515、1999年2月。
[23] Waldbusser, S., "Remote Network Monitoring Management
Information Base", RFC 2819, May 2000.
[23] Waldbusser(S.、「リモートネットワーク監視管理情報ベース」、RFC2819)は2000がそうするかもしれません。
9. Security Considerations
9. セキュリティ問題
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.
aがあります。読書して書くことのマックス-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を使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトがこの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.
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは、お勧めです。 明確に、UserベースのSecurity Model RFC2274[12]とViewベースのAccess Control Model RFC2275[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.
そして、本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために構成されて、それはこのMIBのインスタンスへのアクセスを与えるSNMP実体が適切にそうであることを保証する顧客/ユーザ責任です。
10. IANA Considerations
10. IANA問題
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モジュールSHOULDにおける使用が特にそうので***EndPtについて定義された新しいifTypes。 これは既に定義されるfrDlciEndPt(193)とatmVciEndPt(194)と同様です。
Steinberger & Nicklass Standards Track [Page 21] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[21ページ]RFC3201回路
11. Authors' Addresses
11. 作者のアドレス
Robert Steinberger Fujitsu Network Communications 2801 Telecom Parkway Richardson, TX 75082
パークウェイのリチャードソン、ロバートシュタインバーガー富士通ネットワークコミュニケーションズ2801テレコムテキサス 75082
Phone: 1-972-479-4739 EMail: robert.steinberger@fnc.fujitsu.com
以下に電話をしてください。 1-972-479-4739 メールしてください: robert.steinberger@fnc.fujitsu.com
Orly Nicklass, Ph.D RAD Data Communications Ltd. 12 Hanechoshet Street Tel Aviv, Israel 69710
Nicklass、博士号RADデータ通信株式会社12Hanechoshet通りテルアビブ、オルリーイスラエル69710
Phone: 972 3 7659969 EMail: Orly_n@rad.co.il
以下に電話をしてください。 972 3 7659969 メール: Orly_n@rad.co.il
Steinberger & Nicklass Standards Track [Page 22] RFC 3201 Circuit to Interface MIB January 2002
MIB2002年1月に連結するシュタインバーガーとNicklass標準化過程[22ページ]RFC3201回路
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Steinberger & Nicklass Standards Track [Page 23]
シュタインバーガーとNicklass標準化過程[23ページ]
一覧
スポンサーリンク
