RFC3781 日本語訳
3781 Next Generation Structure of Management Information (SMIng)Mappings to the Simple Network Management Protocol (SNMP). F.Strauss, J. Schoenwaelder. May 2004. (Format: TXT=112267 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Strauss
Request for Comments: 3781 TU Braunschweig
Category: Experimental J. Schoenwaelder
International University Bremen
May 2004
ストラウスがコメントのために要求するワーキンググループF.をネットワークでつないでください: 3781年のTUブラウンシュバイクカテゴリ: 大学ブレーメン2004年5月の国際の実験的なJ.Schoenwaelder
Next Generation Structure of Management Information (SMIng)
Mappings to the Simple Network Management Protocol (SNMP)
簡単なネットワーク管理プロトコルへの経営情報(SMIng)マッピングの次世代構造(SNMP)
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
SMIng (Structure of Management Information, Next Generation) (RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework.
SMIng(Management情報、Next Generationの構造)(RFC3780)、プロトコルから独立しているデータ定義言語は経営情報のためのものですか? このメモはノードのひたむきな定義、スカラのオブジェクト、テーブル、円柱状のオブジェクト、および通知にアイデンティティ、クラス、それらの属性、およびイベントのSMIng定義に関するマッピングを指定するSMIng言語拡張を定義します、SNMP管理フレームワークへのアプリケーションのために。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SNMP Based Internet Management . . . . . . . . . . . . . . . . 3
2.1. Kinds of Nodes. . . . . . . . . . . . . . . . . . . . . 4
2.2. Scalar and Columnar Object Instances. . . . . . . . . . 5
2.3. Object Identifier Hierarchy . . . . . . . . . . . . . . 7
3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . . . 8
3.1. ASN.1 Definitions . . . . . . . . . . . . . . . . . . . 9
4. The snmp Extension Statement . . . . . . . . . . . . . . . . . 10
4.1. The oid Statement . . . . . . . . . . . . . . . . . . . 10
4.2. The node Statement. . . . . . . . . . . . . . . . . . . 10
4.2.1. The node's oid Statement . . . . . . . . . . . . 10
4.2.2. The node's represents Statement. . . . . . . . . 10
4.2.3. The node's status Statement. . . . . . . . . . . 11
4.2.4. The node's description Statement . . . . . . . . 11
4.2.5. The node's reference Statement . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 SNMPはインターネット管理. . . . . . . . . . . . . . . . 3 2.1を基礎づけました。 ノードの種類。 . . . . . . . . . . . . . . . . . . . . 4 2.2. スカラの、そして、円柱状のオブジェクトインスタンス。 . . . . . . . . . 5 2.3. オブジェクト識別子階層構造. . . . . . . . . . . . . . 7 3。 SMIngデータ型マッピング. . . . . . . . . . . . . . . . . . . 8 3.1。 ASN.1定義. . . . . . . . . . . . . . . . . . . 9 4。 snmp Extension Statement. . . . . . . . . . . . . . . . . 10 4.1。 oid Statement. . . . . . . . . . . . . . . . . . . 10 4.2。 ノードStatement。 . . . . . . . . . . . . . . . . . . 10 4.2.1. ノードのoid Statement. . . . . . . . . . . . 10 4.2.2。 ノードのものはStatementを表します。 . . . . . . . . 10 4.2.3. ノードの状態Statement。 . . . . . . . . . . 11 4.2.4. ノードの記述Statement. . . . . . . . 11 4.2.5。 ノードの参照Statement. . . . . . . . . 11
Strauss & Schoenwaelder Experimental [Page 1] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[1ページ]RFC3781SMIngマッピング
4.2.6. Usage Examples . . . . . . . . . . . . . . . . . 11
4.3. The scalars Statement . . . . . . . . . . . . . . . . . 11
4.3.1. The scalars' oid Statement . . . . . . . . . . . 12
4.3.2. The scalars' object Statement . . . . . . . . . 12
4.3.3. The scalars' status Statement . . . . . . . . . 13
4.3.4. The scalars' description Statement . . . . . . . 14
4.3.5. The scalars' reference Statement . . . . . . . . 14
4.3.6. Usage Example. . . . . . . . . . . . . . . . . . 14
4.4. The table Statement . . . . . . . . . . . . . . . . . . 14
4.4.1. The table's oid Statement. . . . . . . . . . . . 15
4.4.2. Table Indexing Statements. . . . . . . . . . . . 15
4.4.3. The table's create Statement . . . . . . . . . . 17
4.4.4. The table's object Statement . . . . . . . . . . 17
4.4.5. The table's status Statement . . . . . . . . . . 19
4.4.6. The table's description Statement . . . . . . . 19
4.4.7. The table's reference Statement . . . . . . . . 19
4.4.8. Usage Example . . . . . . . . . . . . . . . . . 19
4.5. The notification Statement . . . . . . . . . . . . . . 20
4.5.1. The notification's oid Statement . . . . . . . . 20
4.5.2. The notification's signals Statement . . . . . . 20
4.5.3. The notification's status Statement . . . . . . 20
4.5.4. The notification's description Statement . . . . 21
4.5.5. The notification's reference Statement . . . . . 21
4.5.6. Usage Example. . . . . . . . . . . . . . . . . . 21
4.6. The group Statement . . . . . . . . . . . . . . . . . . 21
4.6.1. The group's oid Statement . . . . . . . . . . . 22
4.6.2. The group's members Statement . . . . . . . . . 22
4.6.3. The group's status Statement . . . . . . . . . . 22
4.6.4. The group's description Statement . . . . . . . 22
4.6.5. The group's reference Statement . . . . . . . . 22
4.6.6. Usage Example . . . . . . . . . . . . . . . . . 22
4.7. The compliance Statement. . . . . . . . . . . . . . . . 23
4.7.1. The compliance's oid Statement . . . . . . . . . 23
4.7.2. The compliance's status Statement . . . . . . . 23
4.7.3. The compliance's description Statement . . . . . 23
4.7.4. The compliance's reference Statement . . . . . . 23
4.7.5. The compliance's mandatory Statement . . . . . . 24
4.7.6. The compliance's optional Statement. . . . . . . 24
4.7.7. The compliance's refine Statement . . . . . . . 24
4.7.8. Usage Example . . . . . . . . . . . . . . . . . 26
5. NMRG-SMING-SNMP-EXT . . . . . . . . . . . . . . . . . . . . . 26
6. NMRG-SMING-SNMP . . . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.6. 使用例. . . . . . . . . . . . . . . . . 11 4.3。 スカラStatement. . . . . . . . . . . . . . . . . 11 4.3.1。 スカラのoid Statement. . . . . . . . . . . 12 4.3.2。 スカラのオブジェクトStatement. . . . . . . . . 12 4.3.3。 スカラの状態Statement. . . . . . . . . 13 4.3.4。 スカラの記述Statement. . . . . . . 14 4.3.5。 スカラの参照Statement. . . . . . . . 14 4.3.6。 使用例。 . . . . . . . . . . . . . . . . . 14 4.4. テーブルStatement. . . . . . . . . . . . . . . . . . 14 4.4.1。 テーブルのoid Statement。 . . . . . . . . . . . 15 4.4.2. インデックス声明を見送ってください。 . . . . . . . . . . . 15 4.4.3. テーブルのものはStatement. . . . . . . . . . 17 4.4.4を作成します。 テーブルのオブジェクトStatement. . . . . . . . . . 17 4.4.5。 テーブルの状態Statement. . . . . . . . . . 19 4.4.6。 テーブルの記述Statement. . . . . . . 19 4.4.7。 テーブルの参照Statement. . . . . . . . 19 4.4.8。 使用例. . . . . . . . . . . . . . . . . 19 4.5。 通知Statement. . . . . . . . . . . . . . 20 4.5.1。 通知のoid Statement. . . . . . . . 20 4.5.2。 通知の信号Statement. . . . . . 20 4.5.3。 通知の状態Statement. . . . . . 20 4.5.4。 通知の記述Statement. . . . 21 4.5.5。 通知の参照Statement. . . . . 21 4.5.6。 使用例。 . . . . . . . . . . . . . . . . . 21 4.6. グループStatement. . . . . . . . . . . . . . . . . . 21 4.6.1。 グループのoid Statement. . . . . . . . . . . 22 4.6.2。 グループのメンバーStatement. . . . . . . . . 22 4.6.3。 グループの状態Statement. . . . . . . . . . 22 4.6.4。 グループの記述Statement. . . . . . . 22 4.6.5。 グループの参照Statement. . . . . . . . 22 4.6.6。 使用例. . . . . . . . . . . . . . . . . 22 4.7。 コンプライアンスStatement。 . . . . . . . . . . . . . . . 23 4.7.1. コンプライアンスのoid Statement. . . . . . . . . 23 4.7.2。 コンプライアンスの状態Statement. . . . . . . 23 4.7.3。 コンプライアンスの記述Statement. . . . . 23 4.7.4。 コンプライアンスの参照Statement. . . . . . 23 4.7.5。 コンプライアンスの義務的なStatement. . . . . . 24 4.7.6。 コンプライアンスの任意のStatement。 . . . . . . 24 4.7.7. 承諾のものはStatement. . . . . . . 24 4.7.8を洗練します。 使用例. . . . . . . . . . . . . . . . . 26 5。 NMRG-SMING-SNMP-EXT. . . . . . . . . . . . . . . . . . . . . 26 6。 NMRG-SMING-SNMP. . . . . . . . . . . . . . . . . . . . . . . 33 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 46 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 46
Strauss & Schoenwaelder Experimental [Page 2] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[2ページ]RFC3781SMIngマッピング
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Normative References. . . . . . . . . . . . . . . . . . 47
9.2. Informative References. . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 49
9. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 47 9.1。 引用規格。 . . . . . . . . . . . . . . . . . 47 9.2. 有益な参照。 . . . . . . . . . . . . . . . . 47人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 48の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
1. 序論
SMIng (Structure of Management Information, Next Generation) [RFC3780] is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications for application in the SNMP management framework. Section 2 introduces basics of the SNMP management framework. Section 3 defines how SMIng data types are mapped to the data types supported by the SNMP protocol. It introduces some new ASN.1 [ASN1] definitions which are used to represent new SMIng base types such as floats in the SNMP protocol.
SMIng(Management情報、Next Generationの構造)[RFC3780]は経営情報のためのプロトコルから独立しているデータ定義言語です。 このメモはノード、スカラのオブジェクト、テーブル、および円柱状のオブジェクトのひたむきな定義、およびSNMP管理フレームワークにおけるアプリケーションのための通知にアイデンティティ、クラス、それらの属性、およびイベントのSMIng定義に関するマッピングを指定するSMIng言語拡張を定義します。 セクション2はSNMP管理フレームワークの基礎を紹介します。 セクション3はSMIngデータ型がどうSNMPプロトコルによってサポートされたデータ型に写像されるかを定義します。 それはSNMPプロトコルの浮遊物などの新しいSMIngベースタイプの代理をするのに使用されるいくつかの新しいASN.1[ASN1]定義を導入します。
Section 4 describes the semantics of the SNMP mapping extensions for SMIng. The formal SMIng specification of the extension is provided in Section 5.
セクション4はSMIngのために拡大を写像するSNMPの意味論について説明します。 拡大の正式なSMIng仕様をセクション5に提供します。
Section 6 contains an SMIng module which defines derived types (such as RowStatus) that are specific to the SNMP mapping.
セクション6はSNMPマッピングに特定の派生型(RowStatusなどの)を定義するSMIngモジュールを含みます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. SNMP-Based Internet Management
2. SNMPを拠点とするインターネット管理
The SNMP network management framework [RFC3410] is based on the concept of "managed objects". Managed objects represent real or synthesized variables of systems that are to be managed. Note that in spite of these terms this model is not object-oriented. For naming purposes, the managed objects are organized hierarchically in an "object identifier tree", where only leaf nodes may represent objects.
SNMPネットワークマネージメントフレームワーク[RFC3410]は「管理オブジェクト」の概念に基づいています。 管理オブジェクトは管理されることになっているシステムの本当の、または、統合された変数を表します。 これらの用語にもかかわらず、このモデルがオブジェクト指向でないことに注意してください。 目的を命名するのにおいて、管理オブジェクトは「オブジェクト識別子木」で階層的で組織化されます。そこでは、葉のノードだけがオブジェクトを表すかもしれません。
Nodes in the object identifier tree may also identify conceptual tables, rows of conceptual tables, notifications, groups of objects and/or notifications, compliance statements, modules or other information. Each node is identified by an unique "object identifier" value which is a sequence of non-negative numbers, named "sub-identifiers", where the left-most sub-identifier refers to the
また、オブジェクト識別子木のノードは概念的なテーブルを特定するかもしれません、概念的なテーブルの行、通知、オブジェクト、そして/または、通知、承諾声明、モジュールまたは他の情報のグループ。 各ノードは最も左のサブ識別子が参照する「サブ識別子」という非負数の系列であるユニークな「オブジェクト識別子」値によって特定されます。
Strauss & Schoenwaelder Experimental [Page 3] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[3ページ]RFC3781SMIngマッピング
node next to the root of the tree and the right-most sub-identifier refers to the node that is identified by the complete object identifier value. Each sub-identifier has a value between 0 and 2^32-1 (4294967295).
木の根と最も権利サブ識別子の横のノードは完全なオブジェクト識別子価値によって特定されるノードを示します。 それぞれのサブ識別子には、値の0〜2^32-1(4294967295)があります。
The SMIng extensions described in this document are used to map SMIng data definitions to SNMP compliant managed objects. This mapping is designed to be readable to computer programs, named MIB compilers, as well as to human readers.
本書では説明されたSMIng拡張子は、SNMP対応することの管理オブジェクトにSMIngデータ定義を写像するのに使用されます。 このマッピングは、よく人間の読者のようにMIBコンパイラというコンピュータ・プログラムに読み込み可能になるように設計されています。
2.1. Kinds of Nodes
2.1. ノードの種類
Each node in the object identifier tree is of a certain kind and may represent management information or not:
オブジェクト識別子木の各ノードは、ある種類があって、経営情報を表すかもしれません:
o Simple nodes, that do not represent management information, but
may be used for grouping nodes in a subtree. Those nodes are
defined by the `node' statement. This statement can also be used
to map an SMIng `identity' to a node.
o 簡単なノードであり、それは、経営情報を表しませんが、下位木でノードを分類するのに使用されるかもしれません。 それらのノードは'ノード'声明によって定義されます。 また、ノードへのSMIng'アイデンティティ'を写像するのにこの声明を使用できます。
o Nodes representing the identity of a module to allow references to
a module in other objects of type `ObjectIdentifier'. Those nodes
are defined by the `snmp' statement,
o タイプ'ObjectIdentifier'の他のオブジェクトのモジュールの参照を許すためにモジュールのアイデンティティを表すノード。 それらのノードは'snmp'声明によって定義されます。
o Scalar objects, which have exactly one object instance and no
child nodes. See Section 2.2 for scalar objects' instances. A
set of scalar objects is mapped from one or more SMIng classes
using the `scalars' statement. The statement block of the
`scalars' statement contains one `implements' statement for each
class. The associated statement blocks in turn contain `object'
statements that specify the mapping of attributes to scalar
objects. Scalar objects MUST not have any child node.
o スカラのオブジェクト。(そのオブジェクトには、まさに1つのオブジェクトインスタンスを持っていますが、どんな子供ノードもありません)。 スカラのオブジェクトのインスタンスに関してセクション2.2を見てください。 1セットのスカラのオブジェクトは、1つ以上のSMIngのクラスから'スカラ'声明を使用することで写像されます。 声明が含む'スカラ'1の声明ブロックは各クラスのために声明を'実装します'。 関連声明ブロックは順番にスカラのオブジェクトに属性に関するマッピングを指定する'オブジェクト'声明を含んでいます。 スカラのオブジェクトには、どんな子供ノードもあってはいけません。
o Tables, which represent the root node of a collection of
information structured in table rows. Table nodes are defined by
the `table' statement. A table object identifier SHOULD not have
any other child node than the implicitly defined row node (see
below).
o テーブル。(そのテーブルはテーブル行で構造化された情報の収集の根のノードを表します)。 テーブルノードは'テーブル'声明によって定義されます。 テーブルオブジェクト識別子SHOULDには、それとなく定義された行ノードよりいかなる他の子供ノードもありません(以下を見てください)。
o Rows, which belong to a table (that is, row's object identifier
consists of the table's full object identifier plus a single `1'
sub-identifier) and represent a sequence of one or more columnar
objects. A row node is implicitly defined for each table node.
o 通り、どれが、テーブル(すなわち、行のオブジェクト識別子はテーブルの完全なオブジェクト識別子とただ一つの'1'サブ識別子から成る)に属して、1の系列を表すか、そして、または、より円柱状のオブジェクト。 行ノードはそれぞれのテーブルノードのためにそれとなく定義されます。
Strauss & Schoenwaelder Experimental [Page 4] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[4ページ]RFC3781SMIngマッピング
o Columnar objects, which belong to a row (that is, the columnar
objects' object identifier consists of the row's full object
identifier plus a single column-identifying sub-identifier) and
have zero or more object instances and no child nodes. They are
defined as follows: The classes that are implemented by a `table'
statement are identified by `implements' statements. The
statement block of each `implements' statement contains `object'
statements that specify the mapping of attributes to columnar
objects of this table. Columnar objects MUST not have any child
node.
o 円柱状のオブジェクト。(そのオブジェクトは、行(すなわち、円柱状のオブジェクトのオブジェクト識別子は行の完全なオブジェクト識別子とコラムを特定するただ一つのサブ識別子から成る)のものて、より多くのオブジェクトインスタンスを持っていますが、ゼロにもかかわらず、どんな子供ノードも持っていません)。 それらは以下の通り定義されます: 'テーブル'声明によって実装されるクラスは'道具'声明によって特定されます。 それぞれのブロックが声明を'実装する'という声明はこのテーブルの円柱状のオブジェクトに属性に関するマッピングを指定する'オブジェクト'声明を含んでいます。 円柱状のオブジェクトには、どんな子供ノードもあってはいけません。
o Notifications, which represent information that is sent by agents
within unsolicited transmissions. The `notification' statement is
used to map an SMIng event to a notification. A notification's
object identifier SHOULD not have any child node.
o 通知。(その通知は求められていないトランスミッションの中でエージェントによって送られる情報を表します)。 '通知'声明は、SMIngイベントを通知に写像するのに使用されます。 通知のオブジェクト識別子SHOULDには、どんな子供ノードもありません。
o Groups of objects and notifications, which may be used for
compliance statements. They are defined using the `group'
statement.
o オブジェクトと通知のグループ。(通知は承諾声明に使用されるかもしれません)。 それらは、'グループ'声明を使用することで定義されます。
o Compliance statements which define requirements for MIB module
implementations. They are defined using the `compliance'
statement.
o MIBモジュール実装のための要件を定義する承諾声明。 それらは、'承諾'声明を使用することで定義されます。
2.2. Scalar and Columnar Object Instances
2.2. スカラの、そして、円柱状のオブジェクトインスタンス
Instances of managed objects are identified by appending an instance-identifier to the object's object identifier. Scalar objects and columnar objects use different ways to construct the instance-identifier.
管理オブジェクトのインスタンスは、オブジェクトのオブジェクト識別子にインスタンス識別子を追加することによって、特定されます。 スカラのオブジェクトと円柱状のオブジェクトはインスタンス識別子を構成する異なった方法を使用します。
Scalar objects have exactly one object instance. It is identified by appending a single `0' sub-identifier to the object identifier of the scalar object.
スカラのオブジェクトには、まさに1つのオブジェクトインスタンスがあります。 それは、ただ一つの'0'サブ識別子をスカラのオブジェクトに関するオブジェクト識別子に追加することによって、特定されます。
Within tables, different instances of the same columnar object are identified by appending a sequence of one or more sub-identifiers to the object identifier of the columnar object which consists of the values of object instances that unambiguously distinguish a table row. These indexing objects can be columnar objects of the same and/or another table, but MUST NOT be scalar objects. Multiple applications of the same object in a single table indexing specification are strongly discouraged.
テーブルの中では、同じ円柱状のオブジェクトの異なったインスタンスは、明白にテーブル行を区別するオブジェクトインスタンスの値から成る円柱状のオブジェクトに関するオブジェクト識別子に1つ以上のサブ識別子の系列を追加することによって、特定されます。 同じくらい、そして/または、別のものの円柱状のオブジェクトがテーブルであったならそうすることができますが、オブジェクトに索引をつけるこれらは、スカラのオブジェクトであるはずがありません。 仕様に索引をつける単一のテーブルでの同じオブジェクトの複数の塗布が強くお勧めできないです。
Strauss & Schoenwaelder Experimental [Page 5] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[5ページ]RFC3781SMIngマッピング
The base types of the indexing objects indicate how to form the instance-identifier:
インデックスオブジェクトのベースタイプはインスタンス識別子を形成する方法を示します:
o integer-valued or enumeration-valued: a single sub-identifier
taking the integer value (this works only for non-negative
integers and integers of a size of up to 32 bits),
o 整数で評価されるか列挙で評価される: 整数値(これは最大32ビットのサイズの非負の整数と整数のためだけに働いている)を取るただ一つのサブ識別子
o string-valued, fixed-length strings (or variable-length with
compact encoding): `n' sub-identifiers, where `n' is the length of
the string (each octet of the string is encoded in a separate
sub-identifier),
o ストリングで評価されて、固定長さのストリングと(コンパクトなコード化による可変長): ''サブ識別子、どこ、'ストリングが長さがあるか(ストリングの各八重奏は別々のサブ識別子でコード化されます)。
o string-valued, variable-length strings or bits-valued: `n+1' sub-
identifiers, where `n' is the length of the string or bits
encoding (the first sub-identifier is `n' itself, following this,
each octet of the string or bits is encoded in a separate sub-
identifier),
o ストリングで評価される、可変長文字列ビットで評価される: '+1 'サブ識別子、どこ、'ストリングかビットの長さはコード化しているか('最初のサブ識別子がそうです、そして、これに続くストリングかビットの各八重奏自体は別々のサブ識別子でコード化されます)。
o object identifier-valued (with compact encoding): `n' sub-
identifiers, where `n' is the number of sub-identifiers in the
value (each sub-identifier of the value is copied into a separate
sub-identifier),
o 識別子によって評価されていた状態で(コンパクトなコード化がある)、反対してください: ''サブ識別子、どこ、'値におけるサブ識別子が数があるか(価値に関するそれぞれのサブ識別子は別々のサブ識別子にコピーされます)。
o object identifier-valued: `n+1' sub-identifiers, where `n' is the
number of sub-identifiers in the value (the first sub-identifier
is `n' itself, following this, each sub-identifier in the value is
copied),
o 識別子によって評価されていた状態で、反対してください: '+1 'サブ識別子、どこ、'値におけるサブ識別子が数があるか('最初のサブ識別子はそうです、そして、値におけるこれに続くそれぞれのサブ識別子自体はコピーされます)。
Note that compact encoding can only be applied to an object having a variable-length syntax (e.g., variable-length strings, bits objects or object identifier-valued objects). Further, compact encoding can only be associated with the last object in a list of indexing objects. Finally, compact encoding MUST NOT be used on a variable- length string object if that string might have a value of zero- length.
可変長の構文(例えば、可変長文字列、ビットオブジェクトまたはオブジェクトの識別子で評価されたオブジェクト)を持っているオブジェクトにコンパクトなコード化を適用できるだけであることに注意してください。 さらに、オブジェクトに索引をつけるリストにおける最後のオブジェクトにコンパクトなコード化を関連づけることができるだけです。 最終的に、そのストリングに無の長さの値があるかもしれないなら、可変長さのストリングオブジェクトの上にコンパクトなコード化を使用してはいけません。
Instances identified by use of integer-valued or enumeration-valued objects are RECOMMENDED to be numbered starting from one (i.e., not from zero). Integer objects that allow negative values, Unsigned64 objects, Integer64 objects and floating point objects MUST NOT be used for table indexing.
整数で評価されたか列挙で評価されたオブジェクトの使用で特定されたインスタンスは1つ(すなわち、ゼロでないのからの)から始めて、付番されるべきRECOMMENDEDです。 テーブルインデックスに負の数を許容する整数オブジェクト、Unsigned64オブジェクト、Integer64オブジェクト、および浮動小数点オブジェクトを使用してはいけません。
Objects which are both specified for indexing in a row and also columnar objects of the same row are termed auxiliary objects. Auxiliary objects SHOULD be non-accessible, except in the following circumstances:
並んで索引をつけるのに指定されたものと同じ行の同様に円柱状のもオブジェクトであるオブジェクトは補助のオブジェクトと呼ばれます。 補助のオブジェクトSHOULDは非アクセスしやすく、下記の事情の中で以下を除きます。
o within a module originally written to conform to SMIv1, or
o または元々SMIv1に従うために書かれたモジュールの中で。
Strauss & Schoenwaelder Experimental [Page 6] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[6ページ]RFC3781SMIngマッピング
o a row must contain at least one columnar object which is not an
auxiliary object. In the event that all of a row's columnar
objects are also specified to be indexing objects then one of them
MUST be accessible.
o 行は補助のオブジェクトでない少なくとも1個の円柱状のオブジェクトを含まなければなりません。 また、行の円柱状のオブジェクトのすべてがその時オブジェクトに索引をつけるために指定される場合、それらの1つはアクセスしやすいに違いありません。
2.3. Object Identifier Hierarchy
2.3. オブジェクト識別子階層構造
The layers of the object identifier tree near the root are well defined and organized by standardization bodies. The first level next to the root has three nodes:
根におけるオブジェクト識別子木の層は、標準化本体によってよく定義されて、組織化されます。 根の横の最初のレベルに、3つのノードがあります:
0: ccitt
0: ccitt
1: iso
1: iso
2: joint-iso-ccitt
2: 共同iso-ccitt
Note that the renaming of the Commite Consultatif International de Telegraphique et Telephonique (CCITT) to International Telecommunications Union (ITU) had no consequence on the names used in the object identifier tree.
国際Telecommunications Union(ITU)へのCommite Consultatifの国際de Telegraphique et Telephonique(CCITT)の改名がオブジェクト識別子木で使用される名前に結果を全く持っていなかったことに注意してください。
The root of the subtree administered by the Internet Assigned Numbers Authority (IANA) for the Internet is `1.3.6.1' which is assigned with the identifier `internet'. That is, the Internet subtree of object identifiers starts with the prefix `1.3.6.1.'.
インターネットAssigned民数記Authority(IANA)によってインターネットに管理された下位木の根本は'1.3.6.1'どれが識別子で割り当てられ'インターネット'です。 それはそうであり、接頭語'1.3.6があるオブジェクト識別子始めのインターネット下位木は.1です'。
Several branches underneath this subtree are used for network management:
この下位木の下におけるいくつかのブランチがネットワークマネージメントに使用されます:
The `mgmt' (internet.2) subtree is used to identify "standard" definitions. An information module produced by an IETF working group becomes a "standard" information module when the document is first approved by the IESG and enters the Internet standards track.
'管理'(インターネット.2)下位木は、「標準」の定義を特定するのに使用されます。 ドキュメントが最初に、IESGによって承認されて、インターネット標準化過程に入ると、IETFワーキンググループによって作成された情報モジュールは「標準」の情報モジュールになります。
The `experimental' (internet.3) subtree is used to identify experimental definitions being designed by working groups of the IETF or IRTF. If an information module produced by a working group becomes a "standard" module, then at the very beginning of its entry onto the Internet standards track, the definitions are moved under the mgmt subtree.
'実験的な'(インターネット.3)下位木は、IETFかIRTFのワーキンググループによって設計されている実験的な定義を特定するのに使用されます。 ワーキンググループによって作成された情報モジュールが「標準」のモジュールになるなら、開口一番、インターネット標準化過程へのエントリーでは、定義が管理下位木の下で動かされます。
The `private' (internet.4) subtree is used to identify definitions defined unilaterally. The `enterprises' (private.1) subtree beneath private is used, among other things, to permit providers of networking subsystems to register information modules of their products.
'個人的な'(インターネット.4)下位木は、一方的に定義された定義を特定するのに使用されます。 個人的な下の'企業'(個人的な.1)下位木は、ネットワークサブシステムのプロバイダーがそれらの製品の情報モジュールを登録することを許可するのに特に使用されます。
Strauss & Schoenwaelder Experimental [Page 7] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[7ページ]RFC3781SMIngマッピング
These and some other nodes are defined in the SMIng module NMRG- SMING-SNMP-EXT (Section 5).
これらとある他のノードはSMIngモジュールNMRG- SMING-SNMP-EXT(セクション5)で定義されます。
3. SMIng Data Type Mappings
3. SMIngデータ型マッピング
SMIng [RFC3780] supports the following set of base types: OctetString, Pointer, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64, Float128, Enumeration, Bits, and ObjectIdentifier.
SMIng[RFC3780]は以下のセットのベースタイプをサポートします: OctetString、指針、Integer32、Integer64、Unsigned32、Unsigned64、Float32、Float64、Float128、列挙、ビット、およびObjectIdentifier。
The SMIng core module NMRG-SMING ([RFC3780], Appendix A) defines additional derived types, among them Counter32 (derived from Unsigned32), Counter64 (derived from Unsigned64), TimeTicks32 and TimeTicks64 (derived from Unsigned32 and Unsigned64), IpAddress (derived from OctetString), and Opaque (derived from OctetString).
SMIngコアモジュールNMRG-SMING([RFC3780]、Appendix A)は追加派生型、彼らの中でCounter32(Unsigned32から、派生する)、Counter64(Unsigned64から、派生する)、TimeTicks32、TimeTicks64(Unsigned32とUnsigned64から、派生する)、IpAddress(OctetStringから、派生する)、およびOpaque(OctetStringから、派生する)を定義します。
The version 2 of the protocol operations for SNMP document [RFC3416] defines the following 9 data types which are distinguished by the protocol: INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, Counter32, TimeTicks, Opaque, Counter64, and Unsigned32.
SNMPドキュメント[RFC3416]のためのプロトコル操作のバージョン2はプロトコルによって区別される以下の9つのデータ型を定義します: 整数、八重奏ストリング、オブジェクト識別子、IpAddress、Counter32、TimeTicks、不透明なもの、Counter64、およびUnsigned32。
The SMIng base types and their derived types are mapped to SNMP data types according to the following table:
SMIngベースはタイプされます、そして、以下のテーブルに従って、彼らの派生型はSNMPデータ型に写像されます:
SMIng Data Type SNMP Data Type Comment
--------------- ------------------- -------
OctetString OCTET STRING (1)
Pointer OBJECT IDENTIFIER
Integer32 INTEGER
Integer64 Opaque (Integer64) (2)
Unsigned32 Unsigned32 (3)
Unsigned64 Opaque (Unsigned64) (2) (4)
Float32 Opaque (Float32) (2)
Float64 Opaque (Float64) (2)
Float128 Opaque (Float128) (2)
Enumeration INTEGER
Bits OCTET STRING
ObjectIdentifier OBJECT IDENTIFIER
SMIngデータ型SNMPデータ型コメント--------------- ------------------- ------- 不明瞭な不明瞭な不明瞭な不明瞭な不明瞭なOctetStringのビット八重奏ストリングObjectIdentifierオブジェクト八重奏ストリング(1)指針オブジェクト識別子Integer32整数Integer64(Integer64)(2)Unsigned32 Unsigned32(3)Unsigned64(Unsigned64)(2)(4)Float32(Float32)(2)Float64(Float64)(2)Float128(Float128)(2)列挙整数識別子
Counter32 Counter32
Counter64 Counter64
TimeTicks32 TimeTicks
TimeTicks64 Opaque (Unsigned64) (2)
IpAddress IpAddress
Opaque Opaque
Counter32 Counter32のCounter64 Counter64 TimeTicks32 TimeTicks TimeTicks64の不透明な(Unsigned64)(2)IpAddress IpAddress不透明な不透明なもの
(1) This mapping includes all types derived from the OctetString
type except those types derived from the IpAddress and Opaque
SMIng types defined in the module NMRG-SMING.
(1) このマッピングはIpAddressから得られたそういったタイプの人を除いて、OctetStringタイプから得られたすべてのタイプとモジュールNMRG-SMINGで定義されたOpaque SMIngタイプを含んでいます。
Strauss & Schoenwaelder Experimental [Page 8] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[8ページ]RFC3781SMIngマッピング
(2) This type is encoded according to the ASN.1 type with the same
name defined in Section 3.1. The resulting BER encoded value
is then wrapped in an Opaque value.
(2) ASN.1タイプに従って、同じ名前がセクション3.1で定義されている状態で、このタイプはコード化されます。 次に、包装されるコード化されたBERがOpaque値で評価する結果になること。
(3) This mapping includes all types derived from the Unsigned32
type except those types derived from the Counter32 and
TimeTicks32 SMIng types defined in the module NMRG-SMING.
(3) このマッピングはCounter32から得られたそういったタイプの人を除いて、Unsigned32タイプから得られたすべてのタイプとモジュールNMRG-SMINGで定義されたTimeTicks32 SMIngタイプを含んでいます。
(4) This mapping includes all types derived from the Unsigned64
type except those types derived from the Counter64 SMIng type
defined in the module NMRG-SMING.
(4) このマッピングはモジュールNMRG-SMINGで定義されたCounter64 SMIngタイプから得られたそういったタイプの人を除いて、Unsigned64タイプから得られたすべてのタイプを含んでいます。
3.1. ASN.1 Definitions
3.1. ASN.1定義
The ASN.1 [ASN1] type definitions below introduce data types which are used to map the new SMIng base types into the set of ASN.1 types supported by the second version of SNMP protocol operations [RFC3416].
以下でのASN.1[ASN1]型定義はSNMPプロトコル操作[RFC3416]の第2バージョンによってサポートされたASN.1タイプのセットに新しいSMIngベースタイプを写像するのに使用されるデータ型を紹介します。
NMRG-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN
NMRG-SMING-SNMPを写像している定義:、:= 始まってください。
Integer64 ::=
[APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Integer64:、:= [アプリケーション10] 暗黙の整数(-9223372036854775808..9223372036854775807)
Unsigned64
[APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615)
Unsigned64[アプリケーション11]の暗黙の整数(0..18446744073709551615)
Float32
[APPLICATION 12]
IMPLICIT OCTET STRING (SIZE (4))
Float32[アプリケーション12]の内在している八重奏ストリング(サイズ(4))
Float64
[APPLICATION 13]
IMPLICIT OCTET STRING (SIZE (8))
Float64[アプリケーション13]の内在している八重奏ストリング(サイズ(8))
Float128
[APPLICATION 14]
IMPLICIT OCTET STRING (SIZE (16))
Float128[アプリケーション14]の内在している八重奏ストリング(サイズ(16))
END
終わり
The definitions of Integer64 and Unsigned64 are consistent with the same definitions in the SPPI [RFC3159]. The floating point types Float32, Float64 and Float128 support single, double and quadruple
Integer64とUnsigned64の定義はSPPI[RFC3159]との同じ定義と一致しています。 浮動小数点タイプのFloat32、Float64、およびFloat128はシングルをサポートして、倍増して、4倍になります。
Strauss & Schoenwaelder Experimental [Page 9] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[9ページ]RFC3781SMIngマッピング
IEEE floating point values. The encoding of the values follows the "IEEE Standard for Binary Floating-Point Arithmetic" as defined in ANSI/IEEE Standard 754-1985 [IEEE754].
IEEE浮動小数点値。 値のコード化はANSI/IEEE Standard754-1985[IEEE754]で定義されるように「2進の浮動小数点の演算のIEEE規格」に続きます。
4. The snmp Extension Statement
4. snmp Extension Statement
The `snmp' statement is the main statement of the SNMP mapping specification. It gets one or two arguments: an optional lower-case identifier that specifies a node that represents the module's identity, and a mandatory statement block that contains all details of the SNMP mapping. All information of an SNMP mapping are mapped to an SNMP conformant module of the same name as the containing SMIng module. A single SMIng module must not contain more than one `snmp' statement.
'snmp'声明は仕様を写像するSNMPの主な声明です。 それは1か2つの議論を得ます: モジュールのアイデンティティを表すノードを指定する任意の小文字の識別子、およびSNMPマッピングのすべての詳細を含む義務的な声明ブロック。 SNMPマッピングのすべての情報が含んでいるSMIngモジュールと同じ名前のSNMP conformantモジュールに写像されます。 ただ一つのSMIngモジュールは1つ以上の'snmp'声明を含んではいけません。
4.1. The oid Statement
4.1. oid Statement
The snmp's `oid' statement, which must be present, if the snmp statement contains a module identifier and must be absent otherwise, gets one argument which specifies the object identifier value that is assigned to this module's identity node.
snmpの'oid'声明(モジュール識別子を含んでいて、そうでなければ、snmp声明が欠けるに違いないなら、存在していなければならない)はこのモジュールのアイデンティティノードに割り当てられるオブジェクト識別子価値を指定する1つの議論を得ます。
4.2. The node Statement
4.2. ノードStatement
The `node' statement is used to name and describe a node in the object identifier tree, without associating any class or attribute information with this node. This may be useful to group definitions in a subtree of related management information, or to uniquely define an SMIng `identity' to be referenced in attributes of type Pointer. The `node' statement gets two arguments: a lower-case node identifier and a statement block that holds detailed node information in an obligatory order.
'ノード'声明はオブジェクト識別子木でノードを命名して、説明するのに使用されます、どんなクラスや属性情報もこのノードに関連づけないで。 これは、関連する経営情報の下位木との定義を分類するか、またはタイプPointerの属性で参照をつけられるために唯一SMIng'アイデンティティ'を定義するために役に立つかもしれません。 'ノード'声明は2つの議論を得ます: 小文字のノード識別子と持ちこたえる声明ブロックは義務的なオーダーにおけるノード情報を詳しく述べました。
See the `nodeStatement' rule of the grammar (Section 5) for the formal syntax of the `node' statement.
'ノード'声明の正式な構文に関して文法(セクション5)の'nodeStatement'規則を見てください。
4.2.1. The node's oid Statement
4.2.1. ノードのoid Statement
The node's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this node.
ノードの'oid'声明(存在していなければならない)はこのノードに割り当てられるオブジェクト識別子価値を指定する1つの議論を得ます。
4.2.2. The node's represents Statement
4.2.2. ノードのものはStatementを表します。
The node's `represents' statement, which need not be present, makes this node represent an SMIng identity, so that objects of type Pointer can reference that identity. The statement gets one argument which specifies the identity name.
ノードの'表し'声明(存在している必要はない)でこのノードはSMIngのアイデンティティを表します、タイプPointerのオブジェクトがそのアイデンティティに参照をつけることができるように。 声明はアイデンティティ名を指定する1つの議論を得ます。
Strauss & Schoenwaelder Experimental [Page 10] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[10ページ]RFC3781SMIngマッピング
4.2.3 The node's status Statement
4.2.3 ノードの状態Statement
The node's `status' statement, which must be present, gets one argument which is used to specify whether this node definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.
ノードの'状態'声明(存在していなければならない)はこのノード定義が現在である、または歴史的であるかを指定するのに使用される1つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
4.2.4. The node's description Statement
4.2.4. ノードの記述Statement
The node's `description' statement, which need not be present, gets one argument which is used to specify a high-level textual description of this node.
ノードの'記述'声明(存在している必要はない)はこのノードのハイレベルの原文の記述を指定するのに使用される1つの議論を得ます。
It is RECOMMENDED to include all semantics and purposes of this node.
それは、すべての意味論を含むRECOMMENDEDとこのノードの目的です。
4.2.5. The node's reference Statement
4.2.5. ノードの参照Statement
The node's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related definitions, or some other document which provides additional information relevant to this node.
ノードの'参照'声明(存在している必要はない)はある他のドキュメント(関連する定義を定義する別のモジュールかこのノードに関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
4.2.6. Usage Examples
4.2.6. 使用例
node iso { oid 1; status current; };
node org { oid iso.3; status current; };
node dod { oid org.6; status current; };
node internet { oid dod.1; status current; };
ノードiso oid1; 状態電流;。 ノードorg oid iso.3; 状態電流;。 ノードdod oid org.6; 状態電流;。 ノードインターネットoid dod.1; 状態電流;。
node zeroDotZero {
oid 0.0;
represents NMRG-SMING::null;
status current;
description "A null value used for pointers.";
};
ノードzeroDotZero、oid0.0; NMRG-SMING: : ヌル; 状態電流; 「ヌル値は指針に使用した」記述を表す、。
4.3. The scalars Statement
4.3. スカラStatement
The `scalars' statement is used to define the mapping of one or more classes to a group of SNMP scalar managed objects organized under a common parent node. The `scalars' statement gets two arguments: a
'スカラ'声明は、一般的な親ノードの下で組織化されたSNMPのスカラの管理オブジェクトのグループと1つ以上のクラスに関するマッピングを定義するのに使用されます。 'スカラ'声明は2つの議論を得ます: a
Strauss & Schoenwaelder Experimental [Page 11] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[11ページ]RFC3781SMIngマッピング
lower-case scalar group identifier and a statement block that holds detailed mapping information of this scalar group in an obligatory order.
小文字のスカラのグループ識別子と持ちこたえる声明ブロックは義務的なオーダーでこのスカラのグループに関するマッピング情報を詳しく述べました。
See the `scalarsStatement' rule of the grammar (Section 5) for the formal syntax of the `scalars' statement.
'スカラ'声明の正式な構文に関して文法(セクション5)の'scalarsStatement'規則を見てください。
4.3.1. The scalars' oid Statement
4.3.1. スカラのoid Statement
The scalars' `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to the common parent node of this scalar group.
スカラの'oid'声明(存在していなければならない)はこのスカラのグループの一般的な親ノードに割り当てられるオブジェクト識別子価値を指定する1つの議論を得ます。
4.3.2. The scalars' object Statement
4.3.2. スカラのオブジェクトStatement
The scalars' `object' statement, which must be present at least once, makes this scalar group contain a given scalar object. It gets two arguments: the name of the scalar object to be defined and a statement block that holds additional detailed information in an obligatory order.
スカラの'オブジェクト'声明(少なくともかつて存在していなければならない)で、このスカラのグループは与えられたスカラのオブジェクトを含みます。 それは2つの議論を得ます: 定義されるべきスカラのオブジェクトとそれが追加しているとして保持する1つの声明ブロックの名前は義務的なオーダーにおける情報を詳しく述べました。
4.3.2.1. The object's implements Statement
4.3.2.1. オブジェクトの道具Statement
The `implements' statement, which must be present, is used to specify a single leaf attribute of a class that is implemented by this scalar object. The type of this attribute must be a simple type, i.e., not a class.
'道具'声明(存在していなければならない)は、このスカラのオブジェクトによって実装されるクラスの単葉属性を指定するのに使用されます。 この属性のタイプは純真なタイプ、すなわち、クラスであるはずがありません。
4.3.2.2. The object's subid Statement
4.3.2.2. オブジェクトのsubid Statement
The `subid' statement, which need not be present, is used to specify the sub-identifier that identifies the scalar object within this scalar group, i.e., the object identifier of the scalar object is the concatenation of the values of this scalar group's oid statement and of this subid statement.
'subid'声明(存在している必要はない)はこのスカラのグループの中でスカラのオブジェクトを特定するサブ識別子を指定するのに使用されます、すなわち、スカラのオブジェクトに関するオブジェクト識別子がこのスカラのグループのoid声明とこのsubid声明の値の連結です。
If this statement is omitted, the sub-identifier is the one of the previous object statement within this scalar group plus 1. If the containing object statement is the first one within the containing scalar group and the subid statement is omitted, the sub-identifier is 1.
この声明が省略されるなら、サブ識別子はこのスカラのグループプラス1の中の前のオブジェクト声明の1つです。 含んでいるオブジェクト声明が含有の中の最初のものであるなら、スカラのグループとsubid声明は省略されて、サブ識別子は1です。
4.3.2.3. The object's status Statement
4.3.2.3. オブジェクトの状態Statement
The object's `status' statement, which need not be present, gets one argument which is used to specify whether this scalar object definition is current or historic. The value `current' means that
オブジェクトの'状態'声明(存在している必要はない)はこのスカラのオブジェクト定義が現在である、または歴史的であるかを指定するのに使用される1つの議論を得ます。 値の'電流'はそれを意味します。
Strauss & Schoenwaelder Experimental [Page 12] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[12ページ]RFC3781SMIngマッピング
the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.
定義は、現在であって有効です。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
Scalar objects SHOULD NOT be defined as `current' if the implemented attribute definition is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if the implemented attribute is `obsolete'. Nevertheless, subsequent revisions of used class definitions cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module.
スカラのオブジェクトSHOULD NOT、実装している属性定義が'推奨しない'か'時代遅れである'なら、'電流'と定義されてください。 同様である、それら、SHOULD NOT、実装している属性が'時代遅れである'なら、'推奨しなく'定義されてください。 それにもかかわらず、中古のクラス定義のその後の改正を避けることができないで、唯一のSHOULDはアカウントに連れていかれたコネです。ローカルのモジュールのその後の改正。
Note that it is RECOMMENDED to omit the status statement which means that the status is inherited from the containing scalars statement. However, if the status of a scalar object varies from the containing scalar group, it has to be expressed explicitly, e.g., if the implemented attribute has been deprecated or obsoleted.
それがRECOMMENDEDであることに注意して、状態が含んでいるスカラ声明から引き継がれることを意味する状態声明を省略してください。 しかしながら、スカラのオブジェクトの状態が含有スカラのグループと異なるなら、それは明らかに言い表されなければなりません、例えば、実装している属性が推奨しないか時代遅れにされているなら。
4.3.2.4. The object's description Statement
4.3.2.4. オブジェクトの記述Statement
The object's `description' statement, which need not be present, gets one argument which is used to specify a high-level textual description of this scalar object.
オブジェクトの'記述'声明(存在している必要はない)はこのスカラのオブジェクトのハイレベルの原文の記述を指定するのに使用される1つの議論を得ます。
Note that in contrast to other definitions this description statement is not mandatory and it is RECOMMENDED to omit it, if the object is fully described by the description of the implemented attribute.
他の定義と対照してこの記述声明が義務的でなく、それがRECOMMENDEDであることに注意して、それを省略してください、オブジェクトが実装している属性の記述で完全に説明されるなら。
4.3.2.5. The object's reference Statement
4.3.2.5. オブジェクトの参照Statement
The object's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related definitions, or some other document which provides additional information relevant to this scalar object.
オブジェクトの'参照'声明(存在している必要はない)はある他のドキュメント(関連する定義を定義する別のモジュールかこのスカラのオブジェクトに関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
It is RECOMMENDED to omit this statement, if the object's references are fully described by the implemented attribute.
オブジェクトの参照が実装している属性によって完全に説明されるなら、それはこの声明を省略するRECOMMENDEDです。
4.3.3. The scalars' status Statement
4.3.3. スカラの状態Statement
The scalars' `status' statement, which must be present, gets one argument which is used to specify whether this scalar group definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be
スカラの'状態'声明(存在していなければならない)はこのスカラのグループ定義が現在である、または歴史的であるかを指定するのに使用される1つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'は、定義が時代遅れであることを意味して、実装するべきでない、そして/または、あることができます。
Strauss & Schoenwaelder Experimental [Page 13] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[13ページ]RFC3781SMIngマッピング
removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.
以前に実装されるなら、取り外しました。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
4.3.4. The scalars' description Statement
4.3.4. スカラの記述Statement
The scalars' `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this scalar group.
スカラの'記述'声明(存在していなければならない)はこのスカラのグループのハイレベルの原文の記述を指定するのに使用される1つの議論を得ます。
It is RECOMMENDED to include all semantic definitions necessary for the implementation of this scalar group.
それはこのスカラのグループの実装に必要なすべての意味定義を含むRECOMMENDEDです。
4.3.5. The scalars' reference Statement
4.3.5. スカラの参照Statement
The scalars' `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related definitions, or some other document which provides additional information relevant to this scalars statement.
スカラの'参照'声明(存在している必要はない)はある他のドキュメント(関連する定義を定義する別のモジュールかこのスカラ声明に関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
4.3.6. Usage Example
4.3.6. 使用例
scalars ip {
oid mib-2.4;
object ipForwarding { implements Ip.forwarding; };
object ipDefaultTTL { implements Ip.defaultTTL; };
// ...
status current;
description
"This scalar group implements the Ip class.";
};
スカラip、oid mib-2.4、; オブジェクトipForwarding、道具Ip.forwarding;、; オブジェクトipDefaultTTL、道具Ip.defaultTTL; ; …//状態電流; 「このスカラのグループはIpのクラスを実装する」記述、。
4.4. The table Statement
4.4. テーブルStatement
The `table' statement is used to define the mapping of one or more classes to a single SNMP table of columnar managed objects. The `table' statement gets two arguments: a lower-case table identifier and a statement block that holds detailed mapping information of this table in an obligatory order.
'テーブル'声明は、円柱状の管理オブジェクトの単一のSNMPテーブルと1つ以上のクラスに関するマッピングを定義するのに使用されます。 'テーブル'声明は2つの議論を得ます: 小文字のテーブル識別子と持ちこたえる声明ブロックは義務的なオーダーでこのテーブルに関するマッピング情報を詳しく述べました。
See the `tableStatement' rule of the grammar (Section 5) for the formal syntax of the `table' statement.
'テーブル'声明の正式な構文に関して文法(セクション5)の'tableStatement'規則を見てください。
Strauss & Schoenwaelder Experimental [Page 14] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[14ページ]RFC3781SMIngマッピング
4.4.1. The table's oid Statement
4.4.1. テーブルのoid Statement
The table's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this table's node.
テーブルの'oid'声明(存在していなければならない)はこのテーブルのノードに割り当てられるオブジェクト識別子価値を指定する1つの議論を得ます。
4.4.2. Table Indexing Statements
4.4.2. テーブルインデックス声明
SNMP table mappings offers five methods to supply table indexing information: ordinary tables, table augmentations, sparse table augmentations, table expansions, and reordered tables use different statements to denote their indexing information. Each table definition must contain exactly one of the following indexing statements.
SNMPは情報に索引をつける供給への5つのメソッドが見送るマッピング申し出を見送ります: 普通のテーブル、テーブル増大、まばらなテーブル増大、テーブル拡張、および再命令されたテーブルは、情報に索引をつけるのを指示するのに異なった声明を使用します。 それぞれのテーブル定義は、声明に索引をつけながら、ちょうど以下の1つを含まなければなりません。
4.4.2.1. The table's index Statement for Table Indexing
4.4.2.1. Table IndexingのためのテーブルのインデックスStatement
The table's `index' statement, which is used to supply table indexing information of base tables, gets one argument that specifies a comma-separated list of objects, that are used for table indexing, enclosed in parenthesis.
それは、テーブルの'インデックス'声明(ベーステーブルの情報をテーブルインデックスに提供するのに使用される)はオブジェクトのコンマで切り離されたリストを指定する1つの議論を得て、テーブルインデックスに中古で、挿入句に同封されています。
The elements of the `unique' statement of the implemented class(es) and their order should be regarded as a hint for the index elements of the table.
実装しているクラス(es)の'ユニークな'声明の原理と彼らの注文をテーブルのインデックス要素のためのヒントと見なすべきです。
In case of modules that should be compatible on the SNMP protocol level to SMIv2 versions of the module, an optional `implied' keyword may be added in front of the list to indicate a compact encoding of the last object in the list. See Section 2.2 for details.
SNMPプロトコルレベルでモジュールのSMIv2バージョンに互換性があるべきモジュールの場合には、任意の'暗示している'キーワードは、リストにおける、最後のオブジェクトのコンパクトなコード化を示すためにリストの正面で加えられるかもしれません。 詳細に関してセクション2.2を見てください。
4.4.2.2. The table's augments Statement for Table Indexing
4.4.2.2. テーブルのものはTable IndexingのためにStatementを増大させます。
The table's `augments' statement, which is used to supply table indexing information of tables that augment a base table, gets one argument that specifies the identifier of the table to be augmented. Note that a table augmentation cannot itself be augmented. Anyhow, a base table may be augmented by multiple table augmentations.
テーブルが'増大する'という声明(ベーステーブルを増大させるテーブルの情報をテーブルインデックスに提供するのに使用される)は増大するためにテーブルに関する識別子を指定する1つの議論を得ます。 テーブル増大がそうすることができないことにそれ自体で注意してください。増大します。 とにかく、ベーステーブルは複数のテーブル増大で増大するかもしれません。
A table augmentation makes instances of subordinate columnar objects identified according to the index specification of the base table corresponding to the table named in the `augments' statement. Further, instances of subordinate columnar objects of a table augmentation exist according to the same semantics as instances of subordinate columnar objects of the base table being augmented. As such, note that creation of a base table row implies the
テーブル増大で、'増大'声明で指定されたテーブルに対応するベーステーブルのインデックス仕様通りに下位の円柱状のオブジェクトのインスタンスを特定します。 さらに、増大するベーステーブルの下位の円柱状のオブジェクトのインスタンスと同じ意味論によると、テーブル増大の下位の円柱状の目的のインスタンスは存在しています。 そういうものとして、テーブル行が含意するベースのその作成に注意してください。
Strauss & Schoenwaelder Experimental [Page 15] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[15ページ]RFC3781SMIngマッピング
correspondent creation of any table row augmentations. Table augmentations MUST NOT be used in table row creation and deletion operations.
どんなテーブル行増大の通信員作成。 テーブル行作成と削除操作にテーブル増大を使用してはいけません。
4.4.2.3. The table's extends Statement for Table Indexing
4.4.2.3. テーブルのものはTable IndexingのためにStatementを広げています。
The table's `extends' statement, which is used to supply table indexing information of tables that sparsely augment a base table, gets one argument that specifies the identifier of the table to be sparsely augmented. Note that a sparse table augmentation cannot itself be augmented. Anyhow, a base table may be augmented by multiple table augmentations, sparsely or not.
テーブルが'広がっている'という声明(ベーステーブルをまばらに増大させるテーブルの情報をテーブルインデックスに提供するのに使用される)はまばらに増大するためにテーブルに関する識別子を指定する1つの議論を得ます。 まばらなテーブル増大がそうすることができないことにそれ自体で注意してください。増大します。 とにかく、ベーステーブルは複数のテーブル増大でまばらに増大するかもしれません。
A sparse table augmentation makes instances of subordinate columnar objects identified, if present, according to the index specification of the base table corresponding to the table named in the `extends' statement. Further, instances of subordinate columnar objects of a sparse table augmentation exist according to the semantics as instances of subordinate columnar objects of the base table and the (non-formal) rules that confine the sparse relationship. As such, note that creation of a sparse table row augmentation may be implied by the creation of a base table row as well as done by an explicit creation. However, if a base table row gets deleted, any dependent sparse table row augmentations get also deleted implicitly.
まばらなテーブル増大で、特定されていて、下位の円柱状のオブジェクトのインスタンスを存在させています、'広がり'声明で指定されたテーブルに対応するベーステーブルのインデックス仕様通りに。 さらに、意味論によると、まばらなテーブル増大の下位の円柱状の目的のインスタンスはベーステーブルの下位の円柱状のオブジェクトとまばらな関係を閉じ込める(非正式)の規則のインスタンスとして存在しています。 そういうものとして、まばらなテーブル行増大の作成をベーステーブル行の作成で含意して、明白な作成でするかもしれないことに注意してください。 しかしながら、ベーステーブル行が削除されるなら、また、どんな依存するまばらなテーブル行増大もそれとなく削除されます。
4.4.2.4. The table's reorders Statement for Table Indexing
4.4.2.4. Table Indexingのためのテーブルの追加注文Statement
The table's `reorders' statement is used to supply table indexing information of tables, that contain exactly the same index objects of a base table but in a different order. It gets at least two arguments. The first one specifies the identifier of the base table. The second one specifies a comma-separated list of exactly those object identifiers of the base table's `index' statement, but in the order to be used in this table. Note that a reordered table cannot itself be reordered. Anyhow, a base table may be used for multiple reordered tables.
テーブルの'追加注文'声明がテーブルの情報をテーブルインデックスに提供するのに使用されて、ベーステーブルのまさに同じインデックスオブジェクトを含んでいますが、それは異なったオーダーでそうします。 それは少なくとも2つの議論を得ます。 最初のものはベーステーブルに関する識別子を指定します。 まさにベーステーブルの'インデックス'声明に関するそれらのオブジェクト識別子のコンマで切り離されたリストを指定しますが、2番目のものはこのテーブルで使用されるべき命令でそうします。 再命令されたテーブルがそうすることができないことにそれ自体で注意してください。再命令されます。 とにかく、ベーステーブルは複数の再命令されたテーブルに使用されるかもしれません。
Under some circumstances, an optional `implied' keyword may be added in front of the list to indicate a compact encoding of the last object in the list. See Section 2.2 for details.
いくつかの状況で、任意の'暗示している'キーワードは、リストにおける、最後のオブジェクトのコンパクトなコード化を示すためにリストの正面で加えられるかもしれません。 詳細に関してセクション2.2を見てください。
Instances of subordinate columnar objects of a reordered table exist according to the same semantics as instances of subordinate columnar objects of the base table. As such, note that creation of a base table row implies the correspondent creation of any related reordered table row. Reordered tables MUST NOT be used in table row creation and deletion operations.
ベーステーブルの下位の円柱状のオブジェクトのインスタンスと同じ意味論によると、再命令されたテーブルの下位の円柱状のオブジェクトのインスタンスは存在しています。 そういうものとして、ベーステーブル行の作成がどんな関連する再命令されたテーブル行の通信員作成も含意することに注意してください。 テーブル行作成と削除操作にReorderedテーブルを使用してはいけません。
Strauss & Schoenwaelder Experimental [Page 16] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[16ページ]RFC3781SMIngマッピング
4.4.2.5. The table's expands Statement for Table Indexing
4.4.2.5. テーブルのものはTable IndexingのためにStatementを広げます。
The table's `expands' statement is used to supply table indexing information of table expansions. Table expansions use exactly the same index objects of another table together with additional indexing objects. Thus, the `expands' statement gets at least two arguments. The first one specifies the identifier of the base table. The second one specifies a comma-separated list of the additional object identifiers used for indexing. Note that an expanded table may itself be expanded, and base tables may be used for multiple table expansions.
テーブルが'広がる'という声明は、テーブル拡張の情報をテーブルインデックスに提供するのに使用されます。 テーブル拡張は追加インデックスオブジェクトと共に別のテーブルのまさに同じインデックスオブジェクトを使用します。 したがって、'広げ'声明は少なくとも2つの議論を得ます。 最初のものはベーステーブルに関する識別子を指定します。 2番目のものは索引をつけるのに使用される追加オブジェクト識別子のコンマで切り離されたリストを指定します。 広げられて、拡張テーブルがそうするかもしれないことにそれ自体で注意してください。ベーステーブルは複数のテーブル拡張に使用されてもよいです。
Under some circumstances, an optional `implied' keyword may be added in front of the list to indicate a compact encoding of the last object in the list. See Section 2.2 for details.
いくつかの状況で、任意の'暗示している'キーワードは、リストにおける、最後のオブジェクトのコンパクトなコード化を示すためにリストの正面で加えられるかもしれません。 詳細に関してセクション2.2を見てください。
4.4.3. The table's create Statement
4.4.3. テーブルのものはStatementを作成します。
The table's `create' statement, which need not be present, gets no argument. If the `create' statement is present, table row creation (and deletion) is possible.
テーブルの'作成'声明(存在している必要はない)は議論を全く得ません。 '作成'声明が存在しているなら、テーブル行作成(そして、削除)は可能です。
4.4.4. The table's object Statement
4.4.4. テーブルのオブジェクトStatement
The table's `object' statement, which must be present at least once, makes this table contain a given columnar object. It gets two arguments: the name of the columnar object to be defined and a statement block that holds additional detailed information in an obligatory order.
テーブルの'オブジェクト'声明(少なくともかつて存在していなければならない)で、このテーブルは与えられた円柱状のオブジェクトを含みます。 それは2つの議論を得ます: 定義されるべき円柱状のオブジェクトとそれが追加しているとして保持する1つの声明ブロックの名前は義務的なオーダーにおける情報を詳しく述べました。
4.4.4.1. The object's implements Statement
4.4.4.1. オブジェクトの道具Statement
The `implements' statement, which must be present, is used to specify a single leaf attribute of a class that is implemented by this columnar object. The type of this attribute must be a simple type, i.e., not a class.
'道具'声明(存在していなければならない)は、この円柱状のオブジェクトによって実装されるクラスの単葉属性を指定するのに使用されます。 この属性のタイプは純真なタイプ、すなわち、クラスであるはずがありません。
4.4.4.2. The object's subid Statement
4.4.4.2. オブジェクトのsubid Statement
The `subid' statement, which need not be present, is used to specify the sub-identifier that identifies the columnar object within this table, i.e., the object identifier of the columnar object is the concatenation of the values of this table's oid statement and of this subid statement.
'subid'声明(存在している必要はない)はこのテーブルの中で円柱状のオブジェクトを特定するサブ識別子を指定するのに使用されます、すなわち、円柱状のオブジェクトに関するオブジェクト識別子がこのテーブルのoid声明とこのsubid声明の値の連結です。
Strauss & Schoenwaelder Experimental [Page 17] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[17ページ]RFC3781SMIngマッピング
If this statement is omitted, the sub-identifier is the one of the previous object statement within this table plus 1. If the containing object statement is the first one within the containing table and the subid statement is omitted, the sub-identifier is 1.
この声明が省略されるなら、サブ識別子はこのテーブルと1の中の前のオブジェクト声明の1つです。 含んでいるオブジェクト声明が含んでいるテーブルの中の最初のものであり、subid声明が省略されるなら、サブ識別子は1です。
4.4.4.3. The object's status Statement
4.4.4.3. オブジェクトの状態Statement
The object's `status' statement, which need not be present, gets one argument which is used to specify whether this columnar object definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.
オブジェクトの'状態'声明(存在している必要はない)はこの円柱状のオブジェクト定義が現在である、または歴史的であるかを指定するのに使用される1つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
Columnar objects SHOULD NOT be defined as `current' if the implemented attribute definition is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if the implemented attribute is `obsolete'. Nevertheless, subsequent revisions of used class definitions cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module.
円柱状のオブジェクトSHOULD NOT、実装している属性定義が'推奨しない'か'時代遅れである'なら、'電流'と定義されてください。 同様である、それら、SHOULD NOT、実装している属性が'時代遅れである'なら、'推奨しなく'定義されてください。 それにもかかわらず、中古のクラス定義のその後の改正を避けることができないで、唯一のSHOULDはアカウントに連れていかれたコネです。ローカルのモジュールのその後の改正。
Note that it is RECOMMENDED to omit the status statement which means that the status is inherited from the containing table statement. However, if the status of a columnar object varies from the containing table, it has to be expressed explicitly, e.g., if the implemented attribute has been deprecated or obsoleted.
それがRECOMMENDEDであることに注意して、状態が含んでいるテーブル声明から引き継がれることを意味する状態声明を省略してください。 しかしながら、円柱状のオブジェクトの状態が含んでいるテーブルと異なるなら、それは明らかに言い表されなければなりません、例えば、実装している属性が推奨しないか時代遅れにされているなら。
4.4.4.4. The object's description Statement
4.4.4.4. オブジェクトの記述Statement
The object's `description' statement, which need not be present, gets one argument which is used to specify a high-level textual description of this columnar object.
オブジェクトの'記述'声明(存在している必要はない)はこの円柱状のオブジェクトのハイレベルの原文の記述を指定するのに使用される1つの議論を得ます。
Note that in contrast to other definitions this description statement is not mandatory and it is RECOMMENDED to omit it, if the object is fully described by the description of the implemented attribute.
他の定義と対照してこの記述声明が義務的でなく、それがRECOMMENDEDであることに注意して、それを省略してください、オブジェクトが実装している属性の記述で完全に説明されるなら。
4.4.4.5. The object's reference Statement
4.4.4.5. オブジェクトの参照Statement
The object's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related definitions, or some other document which provides additional information relevant to this columnar object.
オブジェクトの'参照'声明(存在している必要はない)はある他のドキュメント(関連する定義を定義する別のモジュールかこの円柱状のオブジェクトに関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
Strauss & Schoenwaelder Experimental [Page 18] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[18ページ]RFC3781SMIngマッピング
It is RECOMMENDED to omit this statement, if the object's references are fully described by the implemented attribute.
オブジェクトの参照が実装している属性によって完全に説明されるなら、それはこの声明を省略するRECOMMENDEDです。
4.4.5. The table's status Statement
4.4.5. テーブルの状態Statement
The table's `status' statement, which must be present, gets one argument which is used to specify whether this table definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.
テーブルの'状態'声明(存在していなければならない)はこのテーブル定義が現在である、または歴史的であるかを指定するのに使用される1つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
4.4.6. The table's description Statement
4.4.6. テーブルの記述Statement
The table's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this table.
テーブルの'記述'声明(存在していなければならない)はこのテーブルのハイレベルの原文の記述を指定するのに使用される1つの議論を得ます。
It is RECOMMENDED to include all semantic definitions necessary for the implementation of this table.
それはこのテーブルの実装に必要なすべての意味定義を含むRECOMMENDEDです。
4.4.7. The table's reference Statement
4.4.7. テーブルの参照Statement
The table's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related definitions, or some other document which provides additional information relevant to this table statement.
テーブルの'参照'声明(存在している必要はない)はある他のドキュメント(関連する定義を定義する別のモジュールかこのテーブル声明に関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
4.4.8. Usage Example
4.4.8. 使用例
table ifTable {
oid interfaces.2;
index (ifIndex);
object ifIndex { implements Interface.index; };
object ifDescr { implements Interface.description; };
// ...
status current;
description
"This table implements the Interface class.";
};
ifTableをテーブルの上に置いてください、oidが.2; インデックス(ifIndex); オブジェクトifIndexを連結する、道具Interface.index;、; オブジェクトifDescr、道具Interface.description; ; …//状態電流; 「このテーブルはInterfaceのクラスを実装する」記述、。
Strauss & Schoenwaelder Experimental [Page 19] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[19ページ]RFC3781SMIngマッピング
4.5. The notification Statement
4.5. 通知Statement
The `notification' statement is used to map events defined within classes to SNMP notifications. The `notification' statement gets two arguments: a lower-case notification identifier and a statement block that holds detailed notification information in an obligatory order.
'通知'声明は、クラスの中でSNMP通知と定義されたイベントを写像するのに使用されます。 '通知'声明は2つの議論を得ます: 小文字の通知識別子と持ちこたえる声明ブロックは義務的なオーダーにおける通知情報を詳しく述べました。
See the `notificationStatement' rule of the grammar (Section 5) for the formal syntax of the `notification' statement.
'通知'声明の正式な構文に関して文法(セクション5)の'notificationStatement'規則を見てください。
4.5.1. The notification's oid Statement
4.5.1. 通知のoid Statement
The notification's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this notification.
通知の'oid'声明(存在していなければならない)はこの通知に割り当てられるオブジェクト識別子価値を指定する1つの議論を得ます。
4.5.2. The notification's signals Statement
4.5.2. 通知の信号Statement
The notification's `signals' statement, which must be present, denotes the event that is signaled by this notification. The statement gets two arguments: the event to be signaled (in the qualified form `Class.event') and a statement block that holds detailed information on the objects transmitted with this notification in an obligatory order.
通知の'信号'声明(存在していなければならない)はこの通知で合図されるイベントを指示します。 声明は2つの議論を得ます: 合図されるべき(適切なフォーム'Class.event'で)イベントとオブジェクトの詳細な情報を保持する声明ブロックは義務的なオーダーにおけるこの通知で伝わりました。
4.5.2.1. The signals' object Statement
4.5.2.1. 信号のオブジェクトStatement
The signals' `object' statement, which can be present zero, one or multiple times, makes a single instance of a class attribute be contained in this notification. It gets one argument: the specific class attribute. The namespace of attributes not specified by qualified names is the namespace of the event's class specified in the `signals' statement.
信号の'オブジェクト'声明(現在のゼロであるかもしれません)(1か複数の回)で、この通知にクラス属性のただ一つのインスタンスを含んでいます。 それは1つの議論を得ます: 特定のクラス属性。 適切な名前によって指定されなかった属性の名前空間は'信号'声明で指定されたイベントのクラスの名前空間です。
4.5.3. The notification's status Statement
4.5.3. 通知の状態Statement
The notification's `status' statement, which must be present, gets one argument which is used to specify whether this notification definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations.
通知の'状態'声明(存在していなければならない)はこの通知定義が現在である、または歴史的であるかを指定するのに使用される1つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
Strauss & Schoenwaelder Experimental [Page 20] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[20ページ]RFC3781SMIngマッピング
4.5.4. The notification's description Statement
4.5.4. 通知の記述Statement
The notification's `description' statement, which need not be present, gets one argument which is used to specify a high-level textual description of this notification.
通知の'記述'声明(存在している必要はない)はこの通知のハイレベルの原文の記述を指定するのに使用される1つの議論を得ます。
It is RECOMMENDED to include all semantics and purposes of this notification.
それは、すべての意味論を含むRECOMMENDEDとこの通知の目的です。
4.5.5. The notification's reference Statement
4.5.5. 通知の参照Statement
The notification's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related definitions, or some other document which provides additional information relevant to this notification statement.
通知の'参照'声明(存在している必要はない)はある他のドキュメント(関連する定義を定義する別のモジュールかこの通知声明に関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
4.5.6. Usage Example
4.5.6. 使用例
notification linkDown {
oid snmpTraps.3;
signals Interface.linkDown {
object ifIndex;
object ifAdminStatus;
object ifOperStatus;
};
status current;
description
"This notification signals the linkDown event
of the Interface class.";
};
通知linkDown、oid snmpTraps.3; 「この通知はInterfaceのクラスのlinkDownイベントを示す」Interface.linkDownオブジェクトifIndex; オブジェクトifAdminStatus; オブジェクトifOperStatus;; 状態電流;記述に合図する、。
4.6. The group Statement
4.6. グループStatement
The `group' statement is used to define a group of arbitrary nodes in the object identifier tree. It gets two arguments: a lower-case group identifier and a statement block that holds detailed group information in an obligatory order.
'グループ'声明は、オブジェクト識別子木で任意のノードのグループを定義するのに使用されます。 それは2つの議論を得ます: 小文字のグループ識別子と持ちこたえる声明ブロックは義務的なオーダーにおけるグループ情報を詳しく述べました。
Note that the primary application of groups are compliance statements, although they might be referred in other formal or informal documents.
グループのプライマリアプリケーションが承諾声明であることに注意してください、それらは他の正式であるか非公式のドキュメントで参照されるかもしれませんが。
See the `groupStatement' rule of the grammar (Section 5) for the formal syntax of the `group' statement.
'グループ'声明の正式な構文に関して文法(セクション5)の'groupStatement'規則を見てください。
Strauss & Schoenwaelder Experimental [Page 21] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[21ページ]RFC3781SMIngマッピング
4.6.1. The group's oid Statement
4.6.1. グループのoid Statement
The group's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this group.
グループの'oid'声明(存在していなければならない)はこのグループに配属されるオブジェクト識別子価値を指定する1つの議論を得ます。
4.6.2. The group's members Statement
4.6.2. グループのメンバーStatement
The group's `members' statement, which must be present, gets one argument which specifies the list of nodes by their identifiers to be contained in this group. The list of nodes has to be comma-separated and enclosed in parenthesis.
グループの'メンバー'声明(存在していなければならない)はこのグループに含まれるようにそれらの識別子でノードのリストを指定する1つの議論を得ます。 ノードのリストは、コンマで切り離されて挿入句に同封されていなければなりません。
4.6.3. The group's status Statement
4.6.3. The group's status Statement
The group's `status' statement, which must be present, gets one argument which is used to specify whether this group definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and the group should no longer be used. While the value `deprecated' also indicates an obsolete definition, it permits new/continued use of this group.
The group's `status' statement, which must be present, gets one argument which is used to specify whether this group definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and the group should no longer be used. While the value `deprecated' also indicates an obsolete definition, it permits new/continued use of this group.
4.6.4. The group's description Statement
4.6.4. The group's description Statement
The group's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this group. It is RECOMMENDED to include any relation to other groups.
The group's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this group. It is RECOMMENDED to include any relation to other groups.
4.6.5. The group's reference Statement
4.6.5. The group's reference Statement
The group's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related groups, or some other document which provides additional information relevant to this group.
The group's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related groups, or some other document which provides additional information relevant to this group.
4.6.6. Usage Example
4.6.6. Usage Example
The snmpGroup, originally defined in [RFC3418], may be described as follows:
The snmpGroup, originally defined in [RFC3418], may be described as follows:
group snmpGroup {
oid snmpMIBGroups.8;
objects (snmpInPkts, snmpInBadVersions,
snmpInASNParseErrs,
snmpSilentDrops, snmpProxyDrops,
group snmpGroup { oid snmpMIBGroups.8; objects (snmpInPkts, snmpInBadVersions, snmpInASNParseErrs, snmpSilentDrops, snmpProxyDrops,
Strauss & Schoenwaelder Experimental [Page 22] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 22] RFC 3781 SMIng Mappings to SNMP May 2004
snmpEnableAuthenTraps);
status current;
description
"A collection of objects providing basic
instrumentation and control of an agent.";
};
snmpEnableAuthenTraps); status current; description "A collection of objects providing basic instrumentation and control of an agent."; };
4.7. The compliance Statement
4.7. The compliance Statement
The `compliance' statement is used to define a set of conformance requirements, named a `compliance statement'. It gets two arguments: a lower-case compliance identifier and a statement block that holds detailed compliance information in an obligatory order.
The `compliance' statement is used to define a set of conformance requirements, named a `compliance statement'. It gets two arguments: a lower-case compliance identifier and a statement block that holds detailed compliance information in an obligatory order.
See the `complianceStatement' rule of the grammar (Section 5) for the formal syntax of the `compliance' statement.
See the `complianceStatement' rule of the grammar (Section 5) for the formal syntax of the `compliance' statement.
4.7.1. The compliance's oid Statement
4.7.1. The compliance's oid Statement
The compliance's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this compliance statement.
The compliance's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this compliance statement.
4.7.2. The compliance's status Statement
4.7.2. The compliance's status Statement
The compliance's `status' statement, which must be present, gets one argument which is used to specify whether this compliance statement is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and no longer specifies a valid definition of conformance. While the value `deprecated' also indicates an obsolete definition, it permits new/continued use of the compliance specification.
The compliance's `status' statement, which must be present, gets one argument which is used to specify whether this compliance statement is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and no longer specifies a valid definition of conformance. While the value `deprecated' also indicates an obsolete definition, it permits new/continued use of the compliance specification.
4.7.3. The compliance's description Statement
4.7.3. The compliance's description Statement
The compliance's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this compliance statement.
The compliance's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this compliance statement.
4.7.4. The compliance's reference Statement
4.7.4. The compliance's reference Statement
The compliance's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related compliance statements, or some other document which provides additional information relevant to this compliance statement.
The compliance's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related compliance statements, or some other document which provides additional information relevant to this compliance statement.
Strauss & Schoenwaelder Experimental [Page 23] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 23] RFC 3781 SMIng Mappings to SNMP May 2004
4.7.5. The compliance's mandatory Statement
4.7.5. The compliance's mandatory Statement
The compliance's `mandatory' statement, which need not be present, gets one argument which is used to specify a comma-separated list of one or more groups (Section 4.6) of objects and/or notifications enclosed in parenthesis. These groups are unconditionally mandatory for implementation.
The compliance's `mandatory' statement, which need not be present, gets one argument which is used to specify a comma-separated list of one or more groups (Section 4.6) of objects and/or notifications enclosed in parenthesis. These groups are unconditionally mandatory for implementation.
If an agent claims compliance to a MIB module then it must implement each and every object and notification within each group listed in the `mandatory' statement(s) of the compliance statement(s) of that module.
If an agent claims compliance to a MIB module then it must implement each and every object and notification within each group listed in the `mandatory' statement(s) of the compliance statement(s) of that module.
4.7.6. The compliance's optional Statement
4.7.6. The compliance's optional Statement
The compliance's `optional' statement, which need not be present, is repeatedly used to name each group which is conditionally mandatory for compliance to the compliance statement. It can also be used to name unconditionally optional groups. A group named in an `optional' statement MUST be absent from the correspondent `mandatory' statement. The `optional' statement gets two arguments: a lower-case group identifier and a statement block that holds detailed compliance information on that group.
The compliance's `optional' statement, which need not be present, is repeatedly used to name each group which is conditionally mandatory for compliance to the compliance statement. It can also be used to name unconditionally optional groups. A group named in an `optional' statement MUST be absent from the correspondent `mandatory' statement. The `optional' statement gets two arguments: a lower-case group identifier and a statement block that holds detailed compliance information on that group.
Conditionally mandatory groups include those groups which are mandatory only if a particular protocol is implemented, or only if another group is implemented. The `description' statement specifies the conditions under which the group is conditionally mandatory.
Conditionally mandatory groups include those groups which are mandatory only if a particular protocol is implemented, or only if another group is implemented. The `description' statement specifies the conditions under which the group is conditionally mandatory.
A group which is named in neither a `mandatory' statement nor an `optional' statement, is unconditionally optional for compliance to the module.
A group which is named in neither a `mandatory' statement nor an `optional' statement, is unconditionally optional for compliance to the module.
See the `optionalStatement' rule of the grammar (Section 5) for the formal syntax of the `optional' statement.
See the `optionalStatement' rule of the grammar (Section 5) for the formal syntax of the `optional' statement.
4.7.6.1. The optional's description Statement
4.7.6.1. The optional's description Statement
The optional's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the conditions under which this group is conditionally mandatory or unconditionally optional.
The optional's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the conditions under which this group is conditionally mandatory or unconditionally optional.
4.7.7. The compliance's refine Statement
4.7.7. The compliance's refine Statement
The compliance's `refine' statement, which need not be present, is repeatedly used to specify each object for which compliance has a refined requirement with respect to the module definition. The
The compliance's `refine' statement, which need not be present, is repeatedly used to specify each object for which compliance has a refined requirement with respect to the module definition. The
Strauss & Schoenwaelder Experimental [Page 24] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 24] RFC 3781 SMIng Mappings to SNMP May 2004
object must be present in one of the conformance groups named in the correspondent `mandatory' or `optional' statements. The `refine' statement gets two arguments: a lower-case identifier of a scalar or columnar object and a statement block that holds detailed refinement information on that object.
object must be present in one of the conformance groups named in the correspondent `mandatory' or `optional' statements. The `refine' statement gets two arguments: a lower-case identifier of a scalar or columnar object and a statement block that holds detailed refinement information on that object.
See the `refineStatement' rule of the grammar (Section 5) for the formal syntax of the `refine' statement.
See the `refineStatement' rule of the grammar (Section 5) for the formal syntax of the `refine' statement.
4.7.7.1. The refine's type Statement
4.7.7.1. The refine's type Statement
The refine's `type' statement, which need not be present, gets one argument that is used to provide a refined type for the correspondent object. Type restrictions may be applied by appending subtyping information according to the rules of the base type. See [RFC3780] for SMIng base types and their type restrictions. In case of enumeration or bitset types the order of named numbers is not significant.
The refine's `type' statement, which need not be present, gets one argument that is used to provide a refined type for the correspondent object. Type restrictions may be applied by appending subtyping information according to the rules of the base type. See [RFC3780] for SMIng base types and their type restrictions. In case of enumeration or bitset types the order of named numbers is not significant.
Note that if a `type' and a `writetype' statement are both present then this type only applies when instances of the correspondent object are read.
Note that if a `type' and a `writetype' statement are both present then this type only applies when instances of the correspondent object are read.
4.7.7.2. The refine's writetype Statement
4.7.7.2. The refine's writetype Statement
The refine's `writetype' statement, which need not be present, gets one argument that is used to provide a refined type for the correspondent object, only when instances of that object are written. Type restrictions may be applied by appending subtyping information according to the rules of the base type. See [RFC3780] for SMIng base types and their type restrictions. In case of enumeration or bitset types the order of named numbers is not significant.
The refine's `writetype' statement, which need not be present, gets one argument that is used to provide a refined type for the correspondent object, only when instances of that object are written. Type restrictions may be applied by appending subtyping information according to the rules of the base type. See [RFC3780] for SMIng base types and their type restrictions. In case of enumeration or bitset types the order of named numbers is not significant.
4.7.7.3. The refine's access Statement
4.7.7.3. The refine's access Statement
The refine's `access' statement, which need not be present, gets one argument that is used to specify the minimal level of access that the correspondent object must implement in the sense of its original `access' statement. Hence, the refine's `access' statement MUST NOT specify a greater level of access than is specified in the correspondent object definition.
The refine's `access' statement, which need not be present, gets one argument that is used to specify the minimal level of access that the correspondent object must implement in the sense of its original `access' statement. Hence, the refine's `access' statement MUST NOT specify a greater level of access than is specified in the correspondent object definition.
An implementation is compliant if the level of access it provides is greater or equal to the minimal level in the refine's `access' statement and less or equal to the maximal level in the object's `access' statement.
An implementation is compliant if the level of access it provides is greater or equal to the minimal level in the refine's `access' statement and less or equal to the maximal level in the object's `access' statement.
Strauss & Schoenwaelder Experimental [Page 25] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 25] RFC 3781 SMIng Mappings to SNMP May 2004
4.7.7.4. The refine's description Statement
4.7.7.4. The refine's description Statement
The refine's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the refined compliance requirement.
The refine's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the refined compliance requirement.
4.7.8. Usage Example
4.7.8. Usage Example
The compliance statement contained in the SNMPv2-MIB [RFC3418], converted to SMIng:
The compliance statement contained in the SNMPv2-MIB [RFC3418], converted to SMIng:
compliance snmpBasicComplianceRev2 {
oid snmpMIBCompliances.3;
status current;
description
"The compliance statement for SNMP entities which
implement this MIB module.";
compliance snmpBasicComplianceRev2 { oid snmpMIBCompliances.3; status current; description "The compliance statement for SNMP entities which implement this MIB module.";
mandatory (snmpGroup, snmpSetGroup, systemGroup,
snmpBasicNotificationsGroup);
mandatory (snmpGroup, snmpSetGroup, systemGroup, snmpBasicNotificationsGroup);
optional snmpCommunityGroup {
description
"This group is mandatory for SNMP entities which
support community-based authentication.";
};
optional snmpWarmStartNotificationGroup {
description
"This group is mandatory for an SNMP entity which
supports command responder applications, and is
able to reinitialize itself such that its
configuration is unaltered.";
};
};
optional snmpCommunityGroup { description "This group is mandatory for SNMP entities which support community-based authentication."; }; optional snmpWarmStartNotificationGroup { description "This group is mandatory for an SNMP entity which supports command responder applications, and is able to reinitialize itself such that its configuration is unaltered."; }; };
5. NMRG-SMING-SNMP-EXT
5. NMRG-SMING-SNMP-EXT
The grammar of the snmp statement (including all its contained statements) conforms to the Augmented Backus-Naur Form (ABNF) [RFC2234]. It is included in the abnf statement of the snmp SMIng extension definition in the NMRG-SMING-SNMP-EXT module below.
The grammar of the snmp statement (including all its contained statements) conforms to the Augmented Backus-Naur Form (ABNF) [RFC2234]. It is included in the abnf statement of the snmp SMIng extension definition in the NMRG-SMING-SNMP-EXT module below.
module NMRG-SMING-SNMP-EXT {
module NMRG-SMING-SNMP-EXT {
organization "IRTF Network Management Research Group (NMRG)";
organization "IRTF Network Management Research Group (NMRG)";
contact "IRTF Network Management Research Group (NMRG)
http://www.ibr.cs.tu-bs.de/projects/nmrg/
contact "IRTF Network Management Research Group (NMRG) http://www.ibr.cs.tu-bs.de/projects/nmrg/
Strauss & Schoenwaelder Experimental [Page 26] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 26] RFC 3781 SMIng Mappings to SNMP May 2004
Frank Strauss
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391 3266
EMail: strauss@ibr.cs.tu-bs.de
Frank Strauss TU Braunschweig Muehlenpfordtstrasse 23 38106 Braunschweig Germany Phone: +49 531 391 3266 EMail: strauss@ibr.cs.tu-bs.de
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de";
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de";
description "This module defines a SMIng extension to define
the mapping of SMIng definitions of class and
their attributes and events to SNMP compatible
definitions of modules, node, scalars, tables,
and notifications, and additional information on
module compliances.
description "This module defines a SMIng extension to define the mapping of SMIng definitions of class and their attributes and events to SNMP compatible definitions of modules, node, scalars, tables, and notifications, and additional information on module compliances.
Copyright (C) The Internet Society (2004).
All Rights Reserved.
This version of this module is part of
RFC 3781, see the RFC itself for full
legal notices.";
Copyright (C) The Internet Society (2004). All Rights Reserved. This version of this module is part of RFC 3781, see the RFC itself for full legal notices.";
revision {
date "2003-12-16";
description "Initial revision, published as RFC 3781.";
};
revision { date "2003-12-16"; description "Initial revision, published as RFC 3781."; };
//
//
//
// // //
extension snmp {
extension snmp {
status current;
description
"The snmp statement maps SMIng definitions to SNMP
conformant definitions.";
abnf "
;;
;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF
;; notation (RFC 2234).
status current; description "The snmp statement maps SMIng definitions to SNMP conformant definitions."; abnf " ;; ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF ;; notation (RFC 2234).
Strauss & Schoenwaelder Experimental [Page 27] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 27] RFC 3781 SMIng Mappings to SNMP May 2004
;; ;; @(#) $Id: sming-snmp.abnf,v 1.14 2003/10/23 19:31:55 strauss Exp $ ;; ;; Copyright (C) The Internet Society (2004). All Rights Reserved. ;;
;; ;; @(#) $Id: sming-snmp.abnf,v 1.14 2003/10/23 19:31:55 strauss Exp $ ;; ;; Copyright (C) The Internet Society (2004). All Rights Reserved. ;;
;; ;; Statement rules. ;;
;; ;; Statement rules. ;;
snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep
\"{\" stmtsep
*1(oidStatement stmtsep)
*(nodeStatement stmtsep)
*(scalarsStatement stmtsep)
*(tableStatement stmtsep)
*(notificationStatement stmtsep)
*(groupStatement stmtsep)
*(complianceStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep \"{\" stmtsep *1(oidStatement stmtsep) *(nodeStatement stmtsep) *(scalarsStatement stmtsep) *(tableStatement stmtsep) *(notificationStatement stmtsep) *(groupStatement stmtsep) *(complianceStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) \"}\" optsep \";\"
nodeStatement = nodeKeyword sep lcIdentifier optsep
\"{\" stmtsep
oidStatement stmtsep
*1(representsStatement stmtsep)
statusStatement stmtsep
*1(descriptionStatement stmtsep)
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
nodeStatement = nodeKeyword sep lcIdentifier optsep \"{\" stmtsep oidStatement stmtsep *1(representsStatement stmtsep) statusStatement stmtsep *1(descriptionStatement stmtsep) *1(referenceStatement stmtsep) \"}\" optsep \";\"
representsStatement = representsKeyword sep
qucIdentifier optsep \";\"
representsStatement = representsKeyword sep qucIdentifier optsep \";\"
scalarsStatement = scalarsKeyword sep lcIdentifier optsep
\"{\" stmtsep
oidStatement stmtsep
1*(objectStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
scalarsStatement = scalarsKeyword sep lcIdentifier optsep \"{\" stmtsep oidStatement stmtsep 1*(objectStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) \"}\" optsep \";\"
tableStatement = tableKeyword sep lcIdentifier optsep
\"{\" stmtsep
oidStatement stmtsep
tableStatement = tableKeyword sep lcIdentifier optsep \"{\" stmtsep oidStatement stmtsep
Strauss & Schoenwaelder Experimental [Page 28] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 28] RFC 3781 SMIng Mappings to SNMP May 2004
anyIndexStatement stmtsep
*1(createStatement stmtsep)
1*(objectStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
anyIndexStatement stmtsep *1(createStatement stmtsep) 1*(objectStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) \"}\" optsep \";\"
objectStatement = objectKeyword sep lcIdentifier optsep
\"{\" stmtsep
implementsStatement stmtsep
*1(subidStatement stmtsep)
*1(statusStatement stmtsep)
*1(descriptionStatement stmtsep)
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
objectStatement = objectKeyword sep lcIdentifier optsep \"{\" stmtsep implementsStatement stmtsep *1(subidStatement stmtsep) *1(statusStatement stmtsep) *1(descriptionStatement stmtsep) *1(referenceStatement stmtsep) \"}\" optsep \";\"
implementsStatement = implementsKeyword sep qcattrIdentifier
optsep \";\"
implementsStatement = implementsKeyword sep qcattrIdentifier optsep \";\"
notificationStatement = notificationKeyword sep lcIdentifier
optsep \"{\" stmtsep
oidStatement stmtsep
signalsStatement stmtsep
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
notificationStatement = notificationKeyword sep lcIdentifier optsep \"{\" stmtsep oidStatement stmtsep signalsStatement stmtsep statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) \"}\" optsep \";\"
signalsStatement = signalsKeyword sep qattrIdentifier
optsep \"{\" stmtsep
*(signalsObjectStatement)
\"}\" optsep \";\"
signalsStatement = signalsKeyword sep qattrIdentifier optsep \"{\" stmtsep *(signalsObjectStatement) \"}\" optsep \";\"
signalsObjectStatement = objectKeyword sep
qattrIdentifier optsep \";\"
signalsObjectStatement = objectKeyword sep qattrIdentifier optsep \";\"
groupStatement = groupKeyword sep lcIdentifier optsep
\"{\" stmtsep
oidStatement stmtsep
membersStatement stmtsep
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
\"}\" optsep \";\"
groupStatement = groupKeyword sep lcIdentifier optsep \"{\" stmtsep oidStatement stmtsep membersStatement stmtsep statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) \"}\" optsep \";\"
complianceStatement = complianceKeyword sep lcIdentifier optsep
\"{\" stmtsep
complianceStatement = complianceKeyword sep lcIdentifier optsep \"{\" stmtsep
Strauss & Schoenwaelder Experimental [Page 29] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 29] RFC 3781 SMIng Mappings to SNMP May 2004
oidStatement stmtsep
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
*1(mandatoryStatement stmtsep)
*(optionalStatement stmtsep)
*(refineStatement stmtsep)
\"}\" optsep \";\"
oidStatement stmtsep statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) *1(mandatoryStatement stmtsep) *(optionalStatement stmtsep) *(refineStatement stmtsep) \"}\" optsep \";\"
anyIndexStatement = indexStatement /
augmentsStatement /
reordersStatement /
extendsStatement /
expandsStatement
anyIndexStatement = indexStatement / augmentsStatement / reordersStatement / extendsStatement / expandsStatement
indexStatement = indexKeyword *1(sep impliedKeyword) optsep
\"(\" optsep qlcIdentifierList
optsep \")\" optsep \";\"
indexStatement = indexKeyword *1(sep impliedKeyword) optsep \"(\" optsep qlcIdentifierList optsep \")\" optsep \";\"
augmentsStatement = augmentsKeyword sep qlcIdentifier
optsep \";\"
augmentsStatement = augmentsKeyword sep qlcIdentifier optsep \";\"
reordersStatement = reordersKeyword sep qlcIdentifier
*1(sep impliedKeyword)
optsep \"(\" optsep
qlcIdentifierList optsep \")\"
optsep \";\"
reordersStatement = reordersKeyword sep qlcIdentifier *1(sep impliedKeyword) optsep \"(\" optsep qlcIdentifierList optsep \")\" optsep \";\"
extendsStatement = extendsKeyword sep qlcIdentifier optsep \";\"
extendsStatement = extendsKeyword sep qlcIdentifier optsep \";\"
expandsStatement = expandsKeyword sep qlcIdentifier
*1(sep impliedKeyword)
optsep \"(\" optsep
qlcIdentifierList optsep \")\"
optsep \";\"
expandsStatement = expandsKeyword sep qlcIdentifier *1(sep impliedKeyword) optsep \"(\" optsep qlcIdentifierList optsep \")\" optsep \";\"
createStatement = createKeyword optsep \";\"
createStatement = createKeyword optsep \";\"
membersStatement = membersKeyword optsep \"(\" optsep
qlcIdentifierList optsep
\")\" optsep \";\"
membersStatement = membersKeyword optsep \"(\" optsep qlcIdentifierList optsep \")\" optsep \";\"
mandatoryStatement = mandatoryKeyword optsep \"(\" optsep
qlcIdentifierList optsep
\")\" optsep \";\"
mandatoryStatement = mandatoryKeyword optsep \"(\" optsep qlcIdentifierList optsep \")\" optsep \";\"
optionalStatement = optionalKeyword sep qlcIdentifier optsep
\"{\" descriptionStatement stmtsep
optionalStatement = optionalKeyword sep qlcIdentifier optsep \"{\" descriptionStatement stmtsep
Strauss & Schoenwaelder Experimental [Page 30] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 30] RFC 3781 SMIng Mappings to SNMP May 2004
\"}\" optsep \";\"
\"}\" optsep \";\"
refineStatement = refineKeyword sep qlcIdentifier optsep \"{\"
*1(typeStatement stmtsep)
*1(writetypeStatement stmtsep)
*1(accessStatement stmtsep)
descriptionStatement stmtsep
\"}\" optsep \";\"
refineStatement = refineKeyword sep qlcIdentifier optsep \"{\" *1(typeStatement stmtsep) *1(writetypeStatement stmtsep) *1(accessStatement stmtsep) descriptionStatement stmtsep \"}\" optsep \";\"
typeStatement = typeKeyword sep
(refinedBaseType / refinedType)
optsep \";\"
typeStatement = typeKeyword sep (refinedBaseType / refinedType) optsep \";\"
writetypeStatement = writetypeKeyword sep
(refinedBaseType / refinedType)
optsep \";\"
writetypeStatement = writetypeKeyword sep (refinedBaseType / refinedType) optsep \";\"
oidStatement = oidKeyword sep objectIdentifier optsep \";\"
oidStatement = oidKeyword sep objectIdentifier optsep \";\"
subidStatement = subidKeyword sep subid optsep \";\"
subidStatement = subidKeyword sep subid optsep \";\"
;; ;; Statement keywords. ;;
;; ;; Statement keywords. ;;
snmpKeyword = %x73 %x6E %x6D %x70
nodeKeyword = %x6E %x6F %x64 %x65
representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74
%x73
scalarsKeyword = %x73 %x63 %x61 %x6C %x61 %x72 %x73
tableKeyword = %x74 %x61 %x62 %x6C %x65
implementsKeyword = %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74
%x73
subidKeyword = %x73 %x75 %x62 %x69 %x64
objectKeyword = %x6F %x62 %x6A %x65 %x63 %x74
notificationKeyword = %x6E %x6F %x74 %x69 %x66 %x69 %x63 %x61 %x74
%x69 %x6F %x6E
signalsKeyword = %x73 %x69 %x67 %x6E %x61 %x6C %x73
oidKeyword = %x6F %x69 %x64
groupKeyword = %x67 %x72 %x6F %x75 %x70
complianceKeyword = %x63 %x6F %x6D %x70 %x6C %x69 %x61 %x6E %x63
%x65
impliedKeyword = %x69 %x6D %x70 %x6C %x69 %x65 %x64
indexKeyword = %x69 %x6E %x64 %x65 %x78
augmentsKeyword = %x61 %x75 %x67 %x6D %x65 %x6E %x74 %x73
reordersKeyword = %x72 %x65 %x6F %x72 %x64 %x65 %x72 %x73
extendsKeyword = %x65 %x78 %x74 %x65 %x6E %x64 %x73
expandsKeyword = %x65 %x78 %x70 %x61 %x6E %x64 %x73
snmpKeyword = %x73 %x6E %x6D %x70 nodeKeyword = %x6E %x6F %x64 %x65 representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74 %x73 scalarsKeyword = %x73 %x63 %x61 %x6C %x61 %x72 %x73 tableKeyword = %x74 %x61 %x62 %x6C %x65 implementsKeyword = %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74 %x73 subidKeyword = %x73 %x75 %x62 %x69 %x64 objectKeyword = %x6F %x62 %x6A %x65 %x63 %x74 notificationKeyword = %x6E %x6F %x74 %x69 %x66 %x69 %x63 %x61 %x74 %x69 %x6F %x6E signalsKeyword = %x73 %x69 %x67 %x6E %x61 %x6C %x73 oidKeyword = %x6F %x69 %x64 groupKeyword = %x67 %x72 %x6F %x75 %x70 complianceKeyword = %x63 %x6F %x6D %x70 %x6C %x69 %x61 %x6E %x63 %x65 impliedKeyword = %x69 %x6D %x70 %x6C %x69 %x65 %x64 indexKeyword = %x69 %x6E %x64 %x65 %x78 augmentsKeyword = %x61 %x75 %x67 %x6D %x65 %x6E %x74 %x73 reordersKeyword = %x72 %x65 %x6F %x72 %x64 %x65 %x72 %x73 extendsKeyword = %x65 %x78 %x74 %x65 %x6E %x64 %x73 expandsKeyword = %x65 %x78 %x70 %x61 %x6E %x64 %x73
Strauss & Schoenwaelder Experimental [Page 31] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 31] RFC 3781 SMIng Mappings to SNMP May 2004
createKeyword = %x63 %x72 %x65 %x61 %x74 %x65 membersKeyword = %x6D %x65 %x6D %x62 %x65 %x72 %x73 mandatoryKeyword = %x6D %x61 %x6E %x64 %x61 %x74 %x6F %x72 %x79 optionalKeyword = %x6F %x70 %x74 %x69 %x6F %x6E %x61 %x6C refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65 writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65
createKeyword = %x63 %x72 %x65 %x61 %x74 %x65 membersKeyword = %x6D %x65 %x6D %x62 %x65 %x72 %x73 mandatoryKeyword = %x6D %x61 %x6E %x64 %x61 %x74 %x6F %x72 %x79 optionalKeyword = %x6F %x70 %x74 %x69 %x6F %x6E %x61 %x6C refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65 writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65
;; End of ABNF
";
};
//
//
//
;; End of ABNF "; }; // // //
snmp {
snmp {
node ccitt { oid 0; };
node ccitt { oid 0; };
node zeroDotZero {
oid 0.0;
description "A null value used for pointers.";
};
node zeroDotZero { oid 0.0; description "A null value used for pointers."; };
node iso { oid 1; };
node org { oid iso.3; };
node dod { oid org.6; };
node internet { oid dod.1; };
node directory { oid internet.1; };
node mgmt { oid internet.2; };
node mib-2 { oid mgmt.1; };
node transmission { oid mib-2.10; };
node experimental { oid internet.3; };
node private { oid internet.4; };
node enterprises { oid private.1; };
node security { oid internet.5; };
node snmpV2 { oid internet.6; };
node snmpDomains { oid snmpV2.1; };
node snmpProxys { oid snmpV2.2; };
node snmpModules { oid snmpV2.3; };
node iso { oid 1; }; node org { oid iso.3; }; node dod { oid org.6; }; node internet { oid dod.1; }; node directory { oid internet.1; }; node mgmt { oid internet.2; }; node mib-2 { oid mgmt.1; }; node transmission { oid mib-2.10; }; node experimental { oid internet.3; }; node private { oid internet.4; }; node enterprises { oid private.1; }; node security { oid internet.5; }; node snmpV2 { oid internet.6; }; node snmpDomains { oid snmpV2.1; }; node snmpProxys { oid snmpV2.2; }; node snmpModules { oid snmpV2.3; };
node joint-iso-ccitt { oid 2; };
node joint-iso-ccitt { oid 2; };
status current;
description
"This set of nodes defines the core object
identifier hierarchy";
reference
"RFC 2578, Section 2.";
status current; description "This set of nodes defines the core object identifier hierarchy"; reference "RFC 2578, Section 2.";
Strauss & Schoenwaelder Experimental [Page 32] RFC 3781 SMIng Mappings to SNMP May 2004
Strauss & Schoenwaelder Experimental [Page 32] RFC 3781 SMIng Mappings to SNMP May 2004
};
};
};
};
6. NMRG-SMING-SNMP
6. NMRG-SMING-SNMP
The module NMRG-SMING-SNMP specified below defines derived types that are specific to the SNMP mapping.
The module NMRG-SMING-SNMP specified below defines derived types that are specific to the SNMP mapping.
module NMRG-SMING-SNMP {
module NMRG-SMING-SNMP {
organization "IRTF Network Management Research Group (NMRG)";
organization "IRTF Network Management Research Group (NMRG)";
contact "IRTF Network Management Research Group (NMRG)
http://www.ibr.cs.tu-bs.de/projects/nmrg/
contact "IRTF Network Management Research Group (NMRG) http://www.ibr.cs.tu-bs.de/projects/nmrg/
Frank Strauss
TU Braunschweig
Muehlenpfordtstrasse 23
38106 Braunschweig
Germany
Phone: +49 531 391 3266
EMail: strauss@ibr.cs.tu-bs.de
フランクストラウスTUブラウンシュバイクMuehlenpfordtstrasse23 38106ブラウンシュバイクドイツ電話: +49 3266年の531 391メール: strauss@ibr.cs.tu-bs.de
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de";
ユルゲンSchoenwaelderの国際大学ブレーメン私書箱750 561 28725ブレーメンドイツPhone: +49 3587年の421 200メール: " j.schoenwaelder@iu-bremen.de "。
description "Core type definitions for the SMIng SNMP mapping.
These definitions are based on RFC 2579 definitions
that are specific to the SNMP protocol and its
naming system.
記述は「SMIng SNMPマッピングのための型定義の芯を取ります」。 これらの定義はSNMPプロトコルとその命名システムに特定のRFC2579定義に基づいています。
Copyright (C) The Internet Society (2004).
All Rights Reserved.
This version of this module is part of
RFC 3781, see the RFC itself for full
legal notices.";
Copyright(C)インターネット協会(2004)。 All rights reserved。 「RFC自身は、完全な法定の通知に関してこのモジュールのこのバージョンがRFC3781の一部であると考えます。」
revision {
date "2003-12-16";
description "Initial version, published as RFC 3781.";
};
改正、「2003年12月16日」のときに、デートしてください; 「初期のバージョンであって、RFC3781として発行された」記述。
Strauss & Schoenwaelder Experimental [Page 33] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[33ページ]RFC3781SMIngマッピング
typedef TestAndIncr {
type Integer32 (0..2147483647);
description
"Represents integer-valued information used for atomic
operations. When the management protocol is used to
specify that an object instance having this type is to
be modified, the new value supplied via the management
protocol must precisely match the value presently held by
the instance. If not, the management protocol set
operation fails with an error of `inconsistentValue'.
Otherwise, if the current value is the maximum value of
2^31-1 (2147483647 decimal), then the value held by the
instance is wrapped to zero; otherwise, the value held by
the instance is incremented by one. (Note that
regardless of whether the management protocol set
operation succeeds, the variable-binding in the request
and response PDUs are identical.)
整数で評価された情報は原子操作に. いつを使用したか。管理プロトコルはこのタイプがあるオブジェクトインスタンスが変更されていることであると指定するのに使用されて、管理プロトコルで供給された新しい値は正確に現在インスタンスによって開催されている値に合わなければなりません。typedef TestAndIncr、Integer32(0 .2147483647)をタイプしてください;、記述、「表す、そうでなければ、'inconsistentValue'の誤りに応じて管理プロトコル集合演算が失敗する、そうでなければ」; 現行価値が2^31-1(2147483647小数)の最大値であるなら、インスタンスによって保持された値はゼロに包装されます; さもなければ、インスタンスによって保持された値は1つ増加されます。(管理プロトコル集合演算が成功するかどうかにかかわらず可変に要求と応答で拘束力があるPDUsが同じであることに注意してください。)
The value of the SNMP access clause for objects having
this type has to be `readwrite'. When an instance of a
columnar object having this type is created, any value
may be supplied via the management protocol.
このタイプがあるオブジェクトのためのSNMPアクセス節の値は'readwrite'でなければなりません。 このタイプがある円柱状のオブジェクトのインスタンスを作成するとき、管理プロトコルでどんな値も供給するかもしれません。
When the network management portion of the system is re-
initialized, the value of every object instance having
this type must either be incremented from its value prior
to the re-initialization, or (if the value prior to the
re-initialization is unknown) be set to a
pseudo-randomly generated value."; };
「システムのネットワークマネージメント一部が再初期化されるとき、このタイプがあるあらゆるオブジェクトインスタンスの値を再初期化の前に値から増加されなければならないか、またはaに設定しなければならない、(再初期化の前の値が未知であるなら)疑似である、無作為である、発生している値、」 };
typedef AutonomousType {
type Pointer;
description
"Represents an independently extensible type
identification value. It may, for example, indicate a
particular OID sub-tree with further MIB definitions, or
define a particular type of protocol or hardware.";
};
typedef AutonomousType{ Pointerをタイプしてください。 記述は「独自に広げることができるタイプ確認値を表します」。 「例えば、さらなるMIB定義で特定のOID下位木を示すか、または特定のタイプのプロトコルかハードウェアを定義するかもしれません。」 };
typedef VariablePointer {
type Pointer;
description
"A pointer to a specific object instance. For example,
sysContact.0 or ifInOctets.3.";
};
typedef VariablePointer{ Pointerをタイプしてください。 「特定のオブジェクトへの指針は例証する」記述。 「例えば、sysContact.0かifInOctets.3。」 };
typedef RowPointer {
type Pointer;
typedef RowPointer、Pointerをタイプしてください。
Strauss & Schoenwaelder Experimental [Page 34] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[34ページ]RFC3781SMIngマッピング
description
"Represents a pointer to a conceptual row. The value is
the name of the instance of the first accessible columnar
object in the conceptual row.
記述は「概念的な行に指針を表します」。 値は概念的な行における最初のアクセスしやすい円柱状のオブジェクトのインスタンスの名前です。
For example, ifIndex.3 would point to the 3rd row in the
ifTable (note that if ifIndex were not-accessible, then
ifDescr.3 would be used instead).";
};
「例えば、ifIndex.3はifTable(ifIndexがアクセスしやすくないならifDescr.3が代わりに使用されることに注意する)における3番目の行を示すでしょう。」 };
typedef RowStatus {
type Enumeration (active(1), notInService(2),
notReady(3), createAndGo(4),
createAndWait(5), destroy(6));
description
"The RowStatus type is used to manage the creation and
deletion of conceptual rows, and is used as the type for the
row status column of a conceptual row.
typedef RowStatus、Enumerationをタイプしてください、(アクティブな(1)、notInService(2)、notReady(3)、createAndGo(4)(createAndWait(5))は(6))を破壊します; 記述は「概念的な行の作成と削除を管理するのに使用されて、概念的な行に関する行状態コラムにタイプとして使用RowStatusがタイプするされます」。
The status column has six defined values:
状態コラムには、6つの定義された値があります:
- `active', which indicates that the conceptual row is
available for use by the managed device;
- 'アクティブであること'で、どれが、概念的が船をこぐのを示すかは、管理されたデバイスで使用に利用可能です。
- `notInService', which indicates that the conceptual
row exists in the agent, but is unavailable for use by
the managed device (see NOTE below);
- 'notInService'、どれが概念的な行がエージェントに存在していますが、管理されたデバイスで使用を入手できないのを示すか(以下での注意を見てください)。
- `notReady', which indicates that the conceptual row
exists in the agent, but is missing information
necessary in order to be available for use by the
managed device;
- 'notReady'、どれが概念的な行がエージェントに存在するのを示すか、しかし、管理されたデバイスで使用に利用可能になるように必要情報を逃すのは、示します。
- `createAndGo', which is supplied by a management
station wishing to create a new instance of a
conceptual row and to have its status automatically set
to active, making it available for use by the managed
device;
- 'createAndGo'(概念的な行の新しいインスタンスを作成して、状態を持ちたがっている管理ステーションによって、供給される)は自動的にアクティブにセットしました、管理されたデバイスでそれを使用に利用可能にして。
- `createAndWait', which is supplied by a management
station wishing to create a new instance of a
conceptual row (but not make it available for use by
the managed device); and,
- 'createAndWait'、どれが概念的な行(しかし、管理されたデバイスはそれを使用に利用可能にしない)の新しいインスタンスを作成したがっている管理ステーションによって供給されるか。 そして
- `destroy', which is supplied by a management station
wishing to delete all of the instances associated with
an existing conceptual row.
- 既存の概念的な行に関連しているインスタンスのすべてを削除したがっている管理ステーションによって供給される'破壊'。
Strauss & Schoenwaelder Experimental [Page 35] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[35ページ]RFC3781SMIngマッピング
Whereas five of the six values (all except `notReady') may
be specified in a management protocol set operation, only
three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by the
managed device (the status column has value `active'); it is
not available for use by the managed device, though the
agent has sufficient information to make it so (the status
column has value `notInService'); or, it is not available
for use by the managed device, and an attempt to make it so
would fail because the agent has insufficient information
(the state column has value `notReady').
管理プロトコル集合演算で6つの値('notReady'を除いたすべて)のうち5を指定するかもしれませんが、管理プロトコル検索操作に対応して3つの値だけを返すでしょう: 'notInService'の、または、'アクティブである''notReady'。 すなわち、質問される場合、既存の概念的な行には、3つの州しかありません: それは管理されたデバイスで使用に利用可能です(状態コラムは'アクティブ'に値を持っています)。 それは管理されたデバイスで使用に利用可能ではありません、エージェントには、したがって、それを作ることができるくらいの情報がありますが(状態コラムでは、値の'notInService'があります)。 または、それが管理されたデバイスで使用に利用可能でないので、エージェントには不十分な情報があるので(州のコラムでは、値の'notReady'があります)、それを作る試みは失敗するでしょう。
NOTE WELL
井戸に注意してください。
This textual convention may be used for a MIB table,
irrespective of whether the values of that table's
conceptual rows are able to be modified while it is
active, or whether its conceptual rows must be taken
out of service in order to be modified. That is, it is
the responsibility of the DESCRIPTION clause of the
status column to specify whether the status column must
not be `active' in order for the value of some other
column of the same conceptual row to be modified. If
such a specification is made, affected columns may be
changed by an SNMP set PDU if the RowStatus would not
be equal to `active' either immediately before or after
processing the PDU. In other words, if the PDU also
contained a varbind that would change the RowStatus
value, the column in question may be changed if the
RowStatus was not equal to `active' as the PDU was
received, or if the varbind sets the status to a value
other than 'active'.
この原文のコンベンションはMIBテーブルに使用されるかもしれません、それがアクティブである間、そのテーブルの概念的な行の値が変更できるかどうか、または変更されるために使われなくなっていた状態で概念的な行を取らなければならないかどうかの如何にかかわらず。 すなわち、状態コラムがある他のコラムの同じ概念的な行の値が変更されるために'アクティブであってはいけないかどうか'指定するのは、状態コラムの記述節の責任です。 そのような仕様が作られていて、RowStatusが処理するか、またはPDUを処理した後'アクティブ'と等しくないなら、影響を受けるコラムはSNMPセットPDUによって変えられるかもしれません。 言い換えれば、また、PDUがRowStatus値を変えるvarbindを含んだなら、RowStatusがPDUを受け取ったように'アクティブ'と等しくなかったか、またはvarbindが'アクティブ'を除いた値に状態を設定するなら、問題のコラムを変えるかもしれません。
Also note that whenever any elements of a row exist, the
RowStatus column must also exist.
また、また、行のどんな原理も存在しているときはいつも、RowStatusコラムが存在しなければならないことに注意してください。
To summarize the effect of having a conceptual row with a
column having a type of RowStatus, consider the following
state diagram:
一種のRowStatusを持っているコラムで概念的な行を持っているという効果をまとめるには、以下の州のダイヤグラムを考えてください:
Strauss & Schoenwaelder Experimental [Page 36] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[36ページ]RFC3781SMIngマッピング
STATE
+--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
状態+--------------+-----------+-------------+------------- | A| B| C| D| |状態あん部| 状態コラム| |状態コラム| あります。| あります。|状態コラムACTION|存在していません。| notReady| notInService| アクティブ--------------+--------------+-----------+-------------+------------- 状態を設定してください。|noError>D|「不-成」|矛盾|矛盾したコラム| または| entValue| 値| 値のcreateAndGo|矛盾| | | | 値| | | --------------+--------------+-----------+-------------+------------- 状態を設定してください。|noErrorは1を見ます。|「不-成」|矛盾|矛盾したコラム| または| entValue| 値| 値のcreateAndWait|wrongValue| | | --------------+--------------+-----------+-------------+------------- 状態を設定してください。|矛盾|「不-成」|noError|コラムをnoErrorします。| 値| entValue| | アクティブ| | | | | | または| | | | | | | |2>Dを見てください。|8>Dを見てください。| ->D--------------+--------------+-----------+-------------+------------- 状態を設定してください。|矛盾|「不-成」|noError|>CコラムをnoErrorします。| 値| entValue| | notInService| | | | | | または| | または| | | | | |3>Cを見てください。| ->C|6を見てください。--------------+--------------+-----------+-------------+------------- 状態を設定してください。|noError|noError|noError|>AコラムをnoErrorします。| | | | 破壊| ->A| ->A| ->A|7を見てください。--------------+--------------+-----------+-------------+------------- いかなる他のも設定してください。|4を見てください。|noError|noError|5コラムをいくつかに見てください。| | | | 値| | 1を見てください。| ->C| ->D--------------+--------------+-----------+-------------+-------------
(1) go to B or C, depending on information available to the
agent.
(1) エージェントにとって、利用可能な情報によって、BかCまで行ってください。
(2) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, then return noError and goto D.
(2) 他なら、変項束縛が同じPDUに含まれていて、消えますが、必要であるすべてのコラムに値を提供してください、そして、次に、noErrorとgoto Dを返してください。
Strauss & Schoenwaelder Experimental [Page 37] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[37ページ]RFC3781SMIngマッピング
(3) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, then return noError and goto C.
(3) 他なら、変項束縛が同じPDUに含まれていて、消えますが、必要であるすべてのコラムに値を提供してください、そして、次に、noErrorとgoto Cを返してください。
(4) at the discretion of the agent, the return value may be
either:
(4) エージェントの裁量では、リターン値はどちらかであるかもしれません:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding
RowStatus instance does not exist, or
inconsistentName: または対応するRowStatusインスタンスが存在しないとき、エージェントが、そのようなインスタンスを作成するのを選ばないので。
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's
value, or
inconsistentValue: または供給値がある他のMIBオブジェクトの価値の状態に反するなら。
noError: because the agent chooses to create the
instance.
noError: エージェントが、インスタンスを作成するのを選ぶので。
If noError is returned, then the instance of the status
column must also be created, and the new state is B or C,
depending on the information available to the agent. If
inconsistentName or inconsistentValue is returned, the row
remains in state A.
新しい状態は、また、noErrorを返すなら、状態コラムのインスタンスを作成しなければならなくて、BかCです、エージェントにとって、利用可能な情報によって。 inconsistentNameかinconsistentValueを返すなら、行は州Aに残っています。
(5) depending on the MIB definition for the column/table,
either noError or inconsistentValue may be returned.
(5) コラム/テーブルのためにMIB定義によって、noErrorかinconsistentValueのどちらかを返すかもしれません。
(6) the return value can indicate one of the following
errors:
(6) リターン値は以下の誤りの1つを示すことができます:
wrongValue: because the agent does not support
createAndWait, or
wrongValue: またはエージェントがcreateAndWaitをサポートしないので。
inconsistentValue: because the agent is unable to take
the row out of service at this time, perhaps because it
is in use and cannot be de-activated.
inconsistentValue: エージェントは中にそれがこのとき、恐らくあるので使われなくなっている行が使用する撮影に反-動かすことができないので。
(7) the return value can indicate the following error:
(7) リターン値は以下の誤りを示すことができます:
inconsistentValue: because the agent is unable to
remove the row at this time, perhaps because it is in
use and cannot be de-activated.
inconsistentValue: エージェントはこのとき行を取り除くことができません、恐らく、それを使用中であり、反-動かすことができないので。
NOTE: Other processing of the set request may result in a
response other than noError being returned, e.g.,
wrongValue, noCreation, etc.
以下に注意してください。 セット要求の他の処理は返されるnoError、例えば、wrongValue、noCreationなど以外の応答をもたらすかもしれません。
Strauss & Schoenwaelder Experimental [Page 38] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[38ページ]RFC3781SMIngマッピング
Conceptual Row Creation
概念的な通りの作成
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any
objects for which the agent does not supply a default; and,
making the conceptual row available for use by the managed
device.
概念的な行を作成するとき、4回の潜在的相互作用があります: 使用中でないインスタンス識別子を選択します。 概念的な行を作成します。 エージェントがデフォルトを供給しないどんなオブジェクトも初期化します。 そして、概念的を作って、管理されたデバイスで使用に利用可能な状態で船をこいでください。
Interaction 1: Selecting an Instance-Identifier
相互作用1: インスタンス識別子を選択します。
The algorithm used to select an instance-identifier varies
for each conceptual row. In some cases, the instance-
identifier is semantically significant, e.g., the
destination address of a route, and a management station
selects the instance-identifier according to the semantics.
インスタンス識別子を選択するのに使用されるアルゴリズムはそれぞれの概念的な行のために異なります。 いくつかの場合、インスタンス識別子は意味的に重要です、例えば、ルートの送付先アドレス、そして、意味論によると、管理局がインスタンス識別子を選択します。
In other cases, the instance-identifier is used solely to
distinguish conceptual rows, and a management station
without specific knowledge of the conceptual row might
examine the instances present in order to determine an
unused instance-identifier. (This approach may be used, but
it is often highly sub-optimal; however, it is also a
questionable practice for a naive management station to
attempt conceptual row creation.)
他の場合では、インスタンス識別子は唯一概念的な行を区別するのに使用されます、そして、概念的な行に関する特定の知識のない管理局は未使用のインスタンス識別子を決定するためにインスタンスプレゼントを調べるかもしれません。 (それはしばしば非常にサブ最適です; しかしながら、このアプローチは使用されるかもしれませんが、また、ナイーブな管理局が概念的な行作成を試みるのは、疑わしい習慣です。)
Alternately, the MIB module which defines the conceptual row
might provide one or more objects which provide assistance
in determining an unused instance-identifier. For example,
if the conceptual row is indexed by an integer-value, then
an object having an integer-valued SYNTAX clause might be
defined for such a purpose, allowing a management station to
issue a management protocol retrieval operation. In order
to avoid unnecessary collisions between competing management
stations, `adjacent' retrievals of this object should be
different.
交互に、概念的な行を定義するMIBモジュールは未使用のインスタンス識別子を決定するのに支援を提供する1個以上のオブジェクトを提供するかもしれません。 例えば、概念的な行が整数値によって索引をつけられるなら、整数で評価されたSYNTAX節を持っているオブジェクトはそのような目的のために定義されるかもしれません、管理局が管理プロトコル検索操作を発行するのを許容して。 競争している管理局の間の不要な衝突を避けるために、このオブジェクトの'隣接している'retrievalsは異なっているべきです。
Finally, the management station could select a pseudo-random
number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in
response to the management protocol set operation, the
management station should simply select a new pseudo-random
number and retry the operation.
最終的に、管理局はインデックスとして使用への擬似乱数を選定するかもしれません。 このインデックスが既に使用中であり、管理プロトコル集合演算に対応してinconsistentValueを返す場合、管理局は、単に新しい擬似乱数を選択して、操作を再試行するでしょうに。
A MIB designer should choose between the two latter
algorithms based on the size of the table (and therefore the
efficiency of each algorithm). For tables in which a large
number of entries are expected, it is recommended that a MIB
MIBデザイナーはテーブル(そして、したがって、それぞれのアルゴリズムの効率)のサイズに基づく2つの後者のアルゴリズムを選ぶべきです。 多くのエントリーが予想されるテーブルに関しては、そのa MIBはそれに推薦されます。
Strauss & Schoenwaelder Experimental [Page 39] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[39ページ]RFC3781SMIngマッピング
object be defined that returns an acceptable index for
creation. For tables with small numbers of entries, it is
recommended that the latter pseudo-random index mechanism be
used.
反対してください。定義されて、それが作成のために許容できるインデックスを返すということになってください。 少ない数のエントリーがあるテーブルに関しては、後者の擬似ランダムインデックスメカニズムが使用されるのは、お勧めです。
Interaction 2: Creating the Conceptual Row
相互作用2: 概念的な通りを作成します。
Once an unused instance-identifier has been selected, the
management station determines if it wishes to create and
activate the conceptual row in one transaction or in a
negotiated set of interactions.
未使用のインスタンス識別子がいったん選択されると、管理局は、それが1つのトランザクションか交渉されたセットの相互作用で概念的な行を作成して、活性化したがっているかどうか決定します。
Interaction 2a: Creating and Activating the Conceptual Row
相互作用2a: 概念的な通りを作成して、動かします。
The management station must first determine the column
requirements, i.e., it must determine those columns for
which it must or must not provide values. Depending on the
complexity of the table and the management station's
knowledge of the agent's capabilities, this determination
can be made locally by the management station. Alternately,
the management station issues a management protocol get
operation to examine all columns in the conceptual row that
it wishes to create. In response, for each column, there
are three possible outcomes:
管理局は最初にコラム要件を決定しなければなりません、すなわち、それが提供しなければならないか、または値を提供してはいけないそれらのコラムを測定しなければなりません。 テーブルの複雑さとエージェントの能力に関する管理局の知識によって、管理局は局所的にこの決断をすることができます。 交互に、経営者側が議定書の中で述べる管理局問題で、操作はそれが作成したがっている概念的な行のすべてのコラムを調べます。 応答には、各コラムのために、3つの可能な結果があります:
- a value is returned, indicating that some other
management station has already created this conceptual
row. We return to interaction 1.
- ある他の管理局が既にこの概念的な行を作成したのを示して、値を返します。 私たちは相互作用1に戻ります。
- the exception `noSuchInstance' is returned,
indicating that the agent implements the object-type
associated with this column, and that this column in at
least one conceptual row would be accessible in the MIB
view used by the retrieval were it to exist. For those
columns to which the agent provides read-create access,
the `noSuchInstance' exception tells the management
station that it should supply a value for this column
when the conceptual row is to be created.
- 例外'noSuchInstance'を返します、エージェントがこのコラムに関連しているオブジェクト・タイプを実装して、存在するなら少なくとも1つの概念的な行のこのコラムが検索で使用されるMIB視点でアクセス可能であることを示して。 エージェントが提供するそれらのコラムに関しては、アクセスを読書して作成してください、と概念的な行が作成されることであるときに、'noSuchInstance'例外はこのコラムのために、それが値を供給するべきである管理局を言います。
- the exception `noSuchObject' is returned, indicating
that the agent does not implement the object-type
associated with this column or that there is no
conceptual row for which this column would be
accessible in the MIB view used by the retrieval. As
such, the management station can not issue any
management protocol set operations to create an
instance of this column.
- 例外'noSuchObject'を返します、エージェントがこのコラムに関連しているオブジェクト・タイプを実装しないか、またはこのコラムが検索で使用されるMIB視点でアクセス可能であるどんな概念的な行もないのを示して。 そういうものとして、管理局は、このコラムのインスタンスを作成するために少しの管理プロトコル集合演算も発行できません。
Strauss & Schoenwaelder Experimental [Page 40] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[40ページ]RFC3781SMIngマッピング
Once the column requirements have been determined, a
management protocol set operation is accordingly issued.
This operation also sets the new instance of the status
column to `createAndGo'.
コラム要件がいったん決定するようになると、管理プロトコル集合演算はそれに従って、発行されます。 また、この操作は状態コラムの新しいインスタンスを'createAndGo'に設定します。
When the agent processes the set operation, it verifies that
it has sufficient information to make the conceptual row
available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the
conceptual row, and, implementation-specific defaults
supplied by the agent (note that an agent must provide
implementation-specific defaults for at least those objects
which it implements as read-only). If there is sufficient
information available, then the conceptual row is created, a
`noError' response is returned, the status column is set to
`active', and no further interactions are necessary (i.e.,
interactions 3 and 4 are skipped). If there is insufficient
information, then the conceptual row is not created, and the
set operation fails with an error of `inconsistentValue'.
On this error, the management station can issue a management
protocol retrieval operation to determine if this was
because it failed to specify a value for a required column,
or, because the selected instance of the status column
already existed. In the latter case, we return to
interaction 1. In the former case, the management station
can re-issue the set operation with the additional
information, or begin interaction 2 again using
`createAndWait' in order to negotiate creation of the
conceptual row.
エージェントが集合演算を処理するとき、それは、管理されたデバイスで概念的な行を使用に利用可能にするように十分な情報があることを確かめます。 エージェントにとって、利用可能な情報は2つのソースによって提供されます: 経営者側はエージェントによって供給されたそして概念的な行を作成する集合演算の実装特有のデフォルトについて議定書の中で述べます(エージェントが少なくともそれが書き込み禁止として実装するそれらのオブジェクトに実装特有のデフォルトを供給しなければならないことに注意してください)。 利用可能な十分な情報があれば、概念的な行は作成されます、そして、'noError'応答を返します、そして、状態コラムは'アクティブに'設定されます、そして、一層のどんな相互作用も必要ではありません(すなわち、相互作用3と4はスキップされます)。 不十分な情報があれば、概念的な行は作成されません、そして、'inconsistentValue'の誤りに応じて、集合演算は失敗します。 この誤りのときに、管理局は、これがまたは、状態コラムの選択されたインスタンスが既に存在したのでそれが必要なコラムに値を指定しなかったからであるかどうか決定するために管理プロトコル検索操作を発行できます。 後者の場合では、私たちは相互作用1に戻ります。 前の場合では、管理局は、概念的な行の作成を交渉するために追加情報で集合演算を再発行するか、または再び'createAndWait'を使用する相互作用2を始めることができます。
NOTE WELL
井戸に注意してください。
Regardless of the method used to determine the column
requirements, it is possible that the management
station might deem a column necessary when, in fact,
the agent will not allow that particular columnar
instance to be created or written. In this case, the
management protocol set operation will fail with an
error such as `noCreation' or `notWritable'. In this
case, the management station decides whether it needs
to be able to set a value for that particular columnar
instance. If not, the management station re-issues the
management protocol set operation, but without setting
コラム要件を決定するのに使用されるメソッドにかかわらず、事実上、エージェントが、その特定の円柱状のインスタンスが作成されるか、または書かれているのを許さないとき、管理局が、コラムが必要であると考えるのは、可能です。 この場合、'noCreation'か'notWritable'などの誤りに応じて、管理プロトコル集合演算は失敗するでしょう。 この場合、管理局は、それが、その特定の円柱状のインスタンスに値を設定できる必要であるかどうか決めます。 そうでなければ、管理プロトコル集合演算を再発行しますが、管理局は設定なしでそうします。
Strauss & Schoenwaelder Experimental [Page 41] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[41ページ]RFC3781SMIngマッピング
a value for that particular columnar instance;
otherwise, the management station aborts the row
creation algorithm.
その特定の円柱状のインスタンスのための値。 さもなければ、管理局は行作成アルゴリズムを中止します。
Interaction 2b: Negotiating the Creation of the Conceptual
Row
相互作用2b: 概念的な通りの作成を交渉します。
The management station issues a management protocol set
operation which sets the desired instance of the status
column to `createAndWait'. If the agent is unwilling to
process a request of this sort, the set operation fails with
an error of `wrongValue'. (As a consequence, such an agent
must be prepared to accept a single management protocol set
operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is
returned, and the status column is immediately set to either
`notInService' or `notReady', depending on whether it has
sufficient information to make the conceptual row available
for use by the managed device. If there is sufficient
information available, then the status column is set to
`notInService'; otherwise, if there is insufficient
information, then the status column is set to `notReady'.
Regardless, we proceed to interaction 3.
管理局は状態コラムの必要なインスタンスを'createAndWait'に設定する管理プロトコル集合演算を発行します。 エージェントがこの種類の要求を処理したがっていないなら、'wrongValue'の誤りに応じて、集合演算は失敗します。 (結果として、そのようなエージェントはすなわち、ただ一つの管理プロトコル集合演算、相互作用2aが上であると受け入れる用意ができていなければなりません、コラム要件によって示されたコラムのすべてを含んでいて。) さもなければ、概念的な行を作成します、そして、'noError'応答を返します、そして、すぐに'notInService'か'notReady'のどちらかに状態コラムを設定します、使用のために管理されたデバイスでそれには概念的な行を利用可能にすることができるくらいの情報があるかどうかによって。 利用可能な十分な情報があれば、状態コラムは'notInService'に設定されます。 さもなければ、不十分な情報があれば、状態コラムは'notReady'に設定されます。 不注意に、私たちは相互作用3に続きます。
Interaction 3: Initializing non-defaulted Objects
相互作用3: 非デフォルトとしたObjectsを初期化します。
The management station must now determine the column
requirements. It issues a management protocol get operation
to examine all columns in the created conceptual row. In
the response, for each column, there are three possible
outcomes:
管理局は現在、コラム要件を決定しなければなりません。 それは作成された概念的な行のすべてのコラムを操作がプロトコルで調べる管理に発行します。 応答には、各コラムのために、3つの可能な結果があります:
- a value is returned, indicating that the agent
implements the object-type associated with this column
and had sufficient information to provide a value. For
those columns to which the agent provides read-create
access (and for which the agent allows their values to
be changed after their creation), a value return tells
the management station that it may issue additional
management protocol set operations, if it desires, in
order to change the value associated with this column.
- 値を返して、エージェントがオブジェクト・タイプを実装するのを示すのが、このコラムと交際して、値を提供できるくらいの情報を持っていました。 値のリターンは、エージェントが提供するそれらのコラムがアクセス(そして、エージェントがそれらの作成の後にそれらの値を変えさせる)を読書して作成するので、願望であり値がそれであるなら変化するようにこのコラムと交際したとそれが追加管理プロトコル集合演算を発行するかもしれない管理局を言います。
- the exception `noSuchInstance' is returned,
indicating that the agent implements the object-type
associated with this column, and that this column in at
least one conceptual row would be accessible in the MIB
view used by the retrieval were it to exist. However,
- 例外'noSuchInstance'を返します、エージェントがこのコラムに関連しているオブジェクト・タイプを実装して、存在するなら少なくとも1つの概念的な行のこのコラムが検索で使用されるMIB視点でアクセス可能であることを示して。 しかしながら
Strauss & Schoenwaelder Experimental [Page 42] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[42ページ]RFC3781SMIngマッピング
the agent does not have sufficient information to
provide a value, and until a value is provided, the
conceptual row may not be made available for use by the
managed device. For those columns to which the agent
provides read-create access, the `noSuchInstance'
exception tells the management station that it must
issue additional management protocol set operations, in
order to provide a value associated with this column.
エージェントには、値を提供できるくらいの情報がありません、そして、値を提供するまで概念的な行を管理されたデバイスで使用に利用可能にしないかもしれません。 エージェントが提供するそれらのコラムに関しては、アクセスを読書して作成してください、と'noSuchInstance'例外はそれが追加管理プロトコル集合演算を発行しなければならない管理局を言います、このコラムに関連している値を提供するために。
- the exception `noSuchObject' is returned, indicating
that the agent does not implement the object-type
associated with this column or that there is no
conceptual row for which this column would be
accessible in the MIB view used by the retrieval. As
such, the management station can not issue any
management protocol set operations to create an
instance of this column.
- 例外'noSuchObject'を返します、エージェントがこのコラムに関連しているオブジェクト・タイプを実行しないか、またはこのコラムが検索で使用されるMIB視点でアクセス可能であるどんな概念的な列もないのを示して。 そういうものとして、管理局は、このコラムの例を作成するために少しの管理プロトコル集合演算も発行できません。
If the value associated with the status column is
`notReady', then the management station must first deal with
all `noSuchInstance' columns, if any. Having done so, the
value of the status column becomes `notInService', and we
proceed to interaction 4.
状態コラムに関連している値が'notReady'であるなら、管理局は最初に、もしあればすべての'noSuchInstance'コラムに対処しなければなりません。 そうしたので、状態コラムの値は'notInService'になります、そして、私たちは相互作用4に続きます。
Interaction 4: Making the Conceptual Row Available
相互作用4: 概念的な通りを利用可能にします。
Once the management station is satisfied with the values
associated with the columns of the conceptual row, it issues
a management protocol set operation to set the status column
to `active'. If the agent has sufficient information to
make the conceptual row available for use by the managed
device, the management protocol set operation succeeds (a
`noError' response is returned). Otherwise, the management
protocol set operation fails with an error of
`inconsistentValue'.
管理局がいったん概念的な列に関するコラムに関連している値に満たされていると、それは、'アクティブに'状態コラムを設定するために管理プロトコル集合演算を発行します。 エージェントに管理された装置で概念的な列を使用に利用可能にすることができるくらいの情報があるなら、管理プロトコル集合演算は成功します('noError'応答を返します)。 さもなければ、'inconsistentValue'の誤りに応じて、管理プロトコル集合演算は失敗します。
NOTE WELL
井戸に注意してください。
A conceptual row having a status column with value
`notInService' or `notReady' is unavailable to the
managed device. As such, it is possible for the
managed device to create its own instances during the
time between the management protocol set operation
which sets the status column to `createAndWait' and the
management protocol set operation which sets the status
column to `active'. In this case, when the management
protocol set operation is issued to set the status
column to `active', the values held in the agent
値の'notInService'か'notReady'に従った状態コラムがある概念的な列は管理された装置を入手できません。 そういうものとして、管理された装置が時間'createAndWait'に状態コラムを設定する管理プロトコル集合演算と'アクティブに'状態コラムを設定する管理プロトコル集合演算の間でそれ自身の例を作成するのは、可能です。 管理プロトコルがこの場合セットしたとき、操作は'アクティブに'状態コラムを設定するために発行されます、と値がエージェントに保持しました。
Strauss & Schoenwaelder Experimental [Page 43] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[43ページ]RFC3781SMIngマッピング
supersede those used by the managed device.
管理された装置によって使用されるものに取って代わってください。
If the management station is prevented from setting the
status column to `active' (e.g., due to management station or
network failure) the conceptual row will be left in the
`notInService' or `notReady' state, consuming resources
indefinitely. The agent must detect conceptual rows that
have been in either state for an abnormally long period of
time and remove them. It is the responsibility of the
DESCRIPTION clause of the status column to indicate what an
abnormally long period of time would be. This period of time
should be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'. In
the absence of such information in the DESCRIPTION clause, it
is suggested that this period be approximately 5 minutes in
length. This removal action applies not only to newly-
created rows, but also to previously active rows which are
set to, and left in, the notInService state for a prolonged
period exceeding that which is considered normal for such a
conceptual row.
管理局が'アクティブ(例えば、管理局かネットワーク失敗による)に'状態コラムを設定するのが防がれると、概念的な列は'notInService'か'notReady'状態に残されるでしょう、リソースを無期限に消費して。 エージェントは、時間の異常に長い期間、状態にある概念的な列を検出して、それらを取り除かなければなりません。 時間の異常に長い期間が何であるかを示すのは、状態コラムの記述節の責任です。 この期間は人間の応答時間('時間を考えてください'を含んでいる)の間、概念的な列の創造と状態の設定の間に'アクティブに'許容できるくらい長いはずです。 記述節のそのような情報がないとき、長さがこの期間はおよそ5分であると示唆されます。 動作が新たに作成された列だけではなく、設定される以前にアクティブな列と左に適用するこの取り外し、notInServiceはそれを超えている長期の間、どれがそのような概念的な列に正常であると考えられるかを述べます。
Conceptual Row Suspension
概念的な通りのサスペンション
When a conceptual row is `active', the management station
may issue a management protocol set operation which sets the
instance of the status column to `notInService'. If the
agent is unwilling to do so, the set operation fails with an
error of `wrongValue' or `inconsistentValue'.
Otherwise, the conceptual row is taken out of service, and a
`noError' response is returned. It is the responsibility of
the DESCRIPTION clause of the status column to indicate
under what circumstances the status column should be taken
out of service (e.g., in order for the value of some other
column of the same conceptual row to be modified).
概念的な列が'アクティブである'ときに、管理局は'notInService'に状態コラムの例を設定する管理プロトコル集合演算を発行するかもしれません。 エージェントがそうしたがっていないなら、'wrongValue'か'inconsistentValue'の誤りに応じて、集合演算は失敗します。 さもなければ、使われなくなっていた状態で概念的な列を取ります、そして、'noError'応答を返します。 状態コラムがどんな状況で使われなくなっていた状態で(例えば、ある他のコラムの同じ概念的な列の値が変更される命令における)取られるべきであるかを示すのは、状態コラムの記述節の責任です。
Conceptual Row Deletion
概念的な通りの削除
For deletion of conceptual rows, a management protocol set
operation is issued which sets the instance of the status
column to `destroy'. This request may be made regardless of
the current value of the status column (e.g., it is possible
to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds, then
all instances associated with the conceptual row are
immediately removed.";
};
概念的な列の削除において、'破壊する'状態コラムの例を設定する管理プロトコル集合演算は発行されます。 状態コラムの現行価値にかかわらずこの要求をするかもしれません(例えば、それは、'notReady'、'notInService'である概念的な列を削除するのにおいて可能であるか'アクティブです'。)。 「操作が成功するなら、すぐに、概念的な列に関連しているすべての例を取り除きます。」 };
Strauss & Schoenwaelder Experimental [Page 44] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[44ページ]RFC3781SMIngマッピング
typedef StorageType {
type Enumeration (other(1), volatile(2),
nonVolatile(3), permanent(4),
readOnly(5));
description
"Describes the memory realization of a conceptual row. A
row which is volatile(2) is lost upon reboot. A row
which is either nonVolatile(3), permanent(4) or
readOnly(5), is backed up by stable storage. A row which
is permanent(4) can be changed but not deleted. A row
which is readOnly(5) cannot be changed nor deleted.
永久的な(4)を変えますが、削除できません。typedef StorageType、Enumerationをタイプしてください、(他の(1)、揮発性の(2)、nonVolatile(3)、永久的な(4)、readOnly(5)); 記述は「安定貯蔵readOnly(5)である列を変えて、削除できないということである列のそばで. 揮発性の(2)がリブートnonVolatile(3)である列で失われているということである列(永久的な(4)かreadOnly(5))が支持される概念的な列のメモリ実現について説明します」。
If the value of an object with this syntax is either
permanent(4) or readOnly(5), it cannot be modified.
Conversely, if the value is either other(1), volatile(2)
or nonVolatile(3), it cannot be modified to be
permanent(4) or readOnly(5). (All illegal modifications
result in a 'wrongValue' error.)
この構文がある物の値が永久的な(4)かreadOnly(5)のどちらかであるなら、それを変更できません。 逆に、永久的な(4)かreadOnly(5)であることが値が他の(1)、揮発性の(2)かnonVolatile(3)のどちらかであるなら、変更されているはずがありません。 (すべての不法な変更が'wrongValue'誤りをもたらします。)
Every usage of this textual convention is required to
specify the columnar objects which a permanent(4) row
must at a minimum allow to be writable.";
};
「この原文のコンベンションのあらゆる使用法は指定するのが必要であることで、永久的な(4)列が最小限でそうしなければならない円柱状の物が、書き込み可能であることを許容するということです。」 };
typedef TDomain {
type Pointer;
description
"Denotes a kind of transport service.
typedef TDomain、Pointerをタイプしてください; 記述は「一種の輸送サービスを指示します」。
Some possible values, such as snmpUDPDomain, are defined
in the SNMPv2-TM MIB module. Other possible values are
defined in other MIB modules."
reference
"The SNMPv2-TM MIB module is defined in RFC 3417."
};
snmpUDPDomainなどの可能ないくつかの値がSNMPv2-TM MIBモジュールで定義されます。 「他の可能な値は他のMIBモジュールで定義されます」。. 「SNMPv2-TM MIBモジュールは定義されたコネRFC3417です」という参照。 };
typedef TAddressOrZero {
type OctetString (0..255);
description
"Denotes a transport service address.
typedef TAddressOrZero、OctetString(0 .255)をタイプしてください; 記述は「輸送サービスアドレスを指示します」。
A TAddress value is always interpreted within the context
of a TDomain value. Thus, each definition of a TDomain
value must be accompanied by a definition of a textual
convention for use with that TDomain. Some possible
textual conventions, such as SnmpUDPAddress for
snmpUDPDomain, are defined in the SNMPv2-TM MIB module.
Other possible textual conventions are defined in other
TAddress値はTDomain価値の文脈の中でいつも解釈されます。 したがって、原文のコンベンションの定義でそのTDomainとの使用のためにTDomain価値の各定義に伴わなければなりません。 snmpUDPDomainのためのSnmpUDPAddressなどの可能な原文のコンベンションの中にはSNMPv2-TM MIBモジュールで定義されるものもあります。 他の可能な原文のコンベンションは他で定義されます。
Strauss & Schoenwaelder Experimental [Page 45] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[45ページ]RFC3781SMIngマッピング
MIB modules.
MIBモジュール。
A zero-length TAddress value denotes an unknown transport
service address."
reference
"The SNMPv2-TM MIB module is defined in RFC 3417."
};
「TAddressが未知の輸送サービスを指示するのを評価する無の長さのアドレス」 「SNMPv2-TM MIBモジュールは定義されたコネRFC3417です」という参照。 };
typedef TAddress {
type TAddressOrZero (1..255);
description
"Denotes a transport service address.
typedef TAddress、TAddressOrZero(1 .255)をタイプしてください; 記述は「輸送サービスアドレスを指示します」。
This type does not allow a zero-length TAddress value."
};
「このタイプはゼロ・レングスTAddress価値を許容しません。」 };
};
};
7. Security Considerations
7. セキュリティ問題
This document presents an extension of the SMIng data definition language which supports the mapping of SMIng data definitions so that they can be used with the SNMP management framework. The language extension and the mapping itself has no security impact on the Internet.
このドキュメントはSNMP管理枠組みと共にそれらを使用できるようにSMIngデータ定義に関するマッピングを支持するSMIngデータ定義言語の拡大を提示します。 言語拡張とマッピング自体はセキュリティ変化もインターネットに与えません。
8. Acknowledgements
8. 承認
Since SMIng started as a close successor of SMIv2, some paragraphs and phrases are directly taken from the SMIv2 specifications [RFC2578], [RFC2579], [RFC2580] written by Jeff Case, Keith McCloghrie, David Perkins, Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser.
SMIngがSMIv2の近い後継者を始めたので、SMIv2仕様[RFC2578]、[RFC2579]、ジェフCaseによって書かれた[RFC2580]、キースMcCloghrie、デヴィッド・パーキンス、マーシャル・T.ローズ、ユルゲンSchoenwaelder、およびスティーブンL.Waldbusserから数個のパラグラフと句を直接取ります。
The authors would like to thank all participants of the 7th NMRG meeting held in Schloss Kleinheubach from 6-8 September 2000, which was a major step towards the current status of this memo, namely Heiko Dassow, David Durham, Keith McCloghrie, and Bert Wijnen.
作者はシュロスKleinheubachですなわち、このメモ、Heiko Dassow、デヴィッド・ダラム、キースMcCloghrie、およびバートWijnenの現在の状態に向かった主要なステップであった2000年9月6-8日から行われる7番目のNMRG会合のすべての関係者に感謝したがっています。
Furthermore, several discussions within the SMING Working Group reflected experience with SMIv2 and influenced this specification at some points.
その上、SMING作業部会の中のいくつかの議論が、SMIv2と共に経験を反映して、諸点でこの仕様に影響を及ぼしました。
Strauss & Schoenwaelder Experimental [Page 46] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[46ページ]RFC3781SMIngマッピング
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004.
[RFC3780] ストラウス、F.、およびJ.Schoenwaelder、「SMIng--、経営情報の次世代構造、」、RFC3780、5月2004日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
9.2. Informative References
9.2. 有益な参照
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet
Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケースとJ.とマンディとR.とパーテイン、D.とB.スチュワート、「インターネットの標準の管理枠組みのための序論と適用性声明」RFC3410(2002年12月)。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 59, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD59、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 60, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD60、RFC2580、1999年4月のための順応声明。」
[ASN1] International Organization for Standardization,
"Specification of Abstract Syntax Notation One (ASN.1)",
International Standard 8824, December 1987.
[ASN1]国際標準化機構、「抽象構文記法1(ASN.1)の仕様」、国際規格8824、1987年12月。
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of
Policy Provisioning Information (SPPI)", RFC 3159, August
2001.
[RFC3159]McCloghrie、K.、おかげさまで元気です、M.、Seligson、J.、チェン、K.、ハーン、S.、Sahita、R.、スミス、A.、およびF.Reichmeyer、「方針の構造は情報(SPPI)に食糧を供給し」て、RFC3159、2001年8月。
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, August 1985.
[IEEE754]米国電気電子技術者学会、「2進の浮動小数点の演算のIEEE規格」、ANSI/IEEE規格754-1985、1985年8月。
Strauss & Schoenwaelder Experimental [Page 47] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[47ページ]RFC3781SMIngマッピング
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC3418] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
Waldbusser, "Version 2 of the Protocol Operations for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3416, December 2002.
[RFC3416] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
Authors' Addresses
作者のアドレス
Frank Strauss TU Braunschweig Muehlenpfordtstrasse 23 38106 Braunschweig Germany
フランクストラウスTUブラウンシュバイクMuehlenpfordtstrasse23 38106ブラウンシュバイクドイツ
Phone: +49 531 391 3266 EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
以下に電話をしてください。 +49 3266年の531 391メール: strauss@ibr.cs.tu-bs.de ユリ: http://www.ibr.cs.tu-bs.de/
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
ユルゲンSchoenwaelderの国際大学ブレーメン私書箱750 561 28725・ブレーメンドイツ
Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de URI: http://www.eecs.iu-bremen.de/
以下に電話をしてください。 +49 3587年の421 200メール: j.schoenwaelder@iu-bremen.de ユリ: http://www.eecs.iu-bremen.de/
Strauss & Schoenwaelder Experimental [Page 48] RFC 3781 SMIng Mappings to SNMP May 2004
SNMP2004年5月へのストラウスとSchoenwaelderの実験的な[48ページ]RFC3781SMIngマッピング
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Strauss & Schoenwaelder Experimental [Page 49]
シュトラウスとSchoenwaelder実験的です。[49ページ]
一覧
スポンサーリンク
