[要約] RFC 6643は、SMIv2 MIBモジュールをYANGモジュールに変換するためのガイドラインを提供しています。このRFCの目的は、ネットワーク管理情報の標準化と相互運用性の向上を促進することです。
Internet Engineering Task Force (IETF) J. Schoenwaelder
Request for Comments: 6643 Jacobs University
Category: Standards Track July 2012
ISSN: 2070-1721
Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
管理情報バージョン2（SMIv2）MIBモジュールの構造のYANGモジュールへの変換
Abstract
概要
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the Simple Network Management Protocol (SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF.
YANGは、ネットワーク構成プロトコル（NETCONF）、NETCONFリモートプロシージャコール、およびNETCONF通知によって操作される構成および状態データをモデル化するために使用されるデータモデリング言語です。管理情報の構造（SMIv2）は、基本的なデータタイプ、オブジェクトモデル、および簡易ネットワーク管理プロトコル（SNMP）で使用するためのMIBモジュールの記述と改訂のルールを定義します。このドキュメントは、SMIv2 MIBモジュールのYANGモジュールへの変換を定義し、NETCONFを介してSMIv2 MIBモジュールで定義されたデータオブジェクトへの読み取り専用（config false）アクセスを可能にします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6643.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6643で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションのマテリアルが含まれている場合があります。このマテリアルの著作権を管理する人物が、IETF Trustにそのようなマテリアルの変更を許可する権利を付与していないIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとしての発行、またはそれを英語以外の言語に翻訳すること。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Mapping of Well-Known Types . . . . . . . . . . . . . . . . . 4
3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses . . . . 5
3.1. Example: IMPORTS of IF-MIB . . . . . . . . . . . . . . . . 6
4. Translation of the MODULE-IDENTITY Macro . . . . . . . . . . . 7
4.1. MODULE-IDENTITY Translation Rules . . . . . . . . . . . . 7
4.2. Example: MODULE-IDENTITY of IF-MIB . . . . . . . . . . . . 8
5. Translation of the TEXTUAL-CONVENTION Macro . . . . . . . . . 9
5.1. TEXTUAL-CONVENTION Translation Rules . . . . . . . . . . . 9
5.2. Example: OwnerString and InterfaceIndex of IF-MIB . . . . 10
5.3. Example: IfDirection of the DIFFSERV-MIB . . . . . . . . . 11
6. Translation of OBJECT IDENTIFIER Assignments . . . . . . . . . 11
7. Translation of the OBJECT-TYPE Macro . . . . . . . . . . . . . 11
7.1. Scalar and Columnar Object Translation Rules . . . . . . . 11
7.2. Example: ifNumber and ifIndex of the IF-MIB . . . . . . . 13
7.3. Non-Augmenting Conceptual Table Translation Rules . . . . 13
7.4. Example: ifTable of the IF-MIB . . . . . . . . . . . . . . 15
7.5. Example: ifRcvAddressTable of the IF-MIB . . . . . . . . . 16
7.6. Example: alHostTable of the RMON2-MIB . . . . . . . . . . 17
7.7. Augmenting Conceptual Tables Translation Rules . . . . . . 18
7.8. Example: ifXTable of the IF-MIB . . . . . . . . . . . . . 20
8. Translation of the OBJECT-IDENTITY Macro . . . . . . . . . . . 21
8.1. OBJECT-IDENTITY Translation Rules . . . . . . . . . . . . 21
8.2. Example: diffServTBParamSimpleTokenBucket of the
DIFFSERV-MIB . . . . . . . . . . . . . . . . . . . . . . . 21
9. Translation of the NOTIFICATION-TYPE Macro . . . . . . . . . . 22
9.1. NOTIFICATION-TYPE Translation Rules . . . . . . . . . . . 22
9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB . . . . . . 23
10. YANG Language Extension Definition . . . . . . . . . . . . . . 24
11. Implementing Configuration Data Nodes . . . . . . . . . . . . 27
11.1. Example: addressMapControlTable of RMON2-MIB . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . . 31
Appendix A. Mapping of Well-Known Types (Normative) . . . . . . . 33
Appendix B. Module Prefix Generation (Informative) . . . . . . . 35
This document describes a translation of SMIv2 [RFC2578], [RFC2579], [RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only (config false, as defined in Section 7.19.1 of RFC 6020) access to SMIv2 objects defined in SMIv2 MIB modules via NETCONF [RFC6241]. For a discussion why SMIv2 read-write or read-create objects are translated to read-only (config false) YANG objects, see Section 11.
このドキュメントでは、SMIv2 [RFC2578]、[RFC2579]、[RFC2580] MIBモジュールをYANG [RFC6020]モジュールに変換し、SMIv2オブジェクトへの読み取り専用アクセス（RFC 6020のセクション7.19.1で定義されているようにfalse）を有効にします。 NETCONF [RFC6241]を介してSMIv2 MIBモジュールで定義されています。 SMIv2の読み取り/書き込みまたは読み取り/作成オブジェクトが読み取り専用（config false）YANGオブジェクトに変換される理由については、セクション11を参照してください。
YANG modules generated from SMIv2 modules should not be modified. Any necessary changes should be made by modifying the original SMIv2 modules (with proper updates of the SMIv2 LAST-UPDATED and REVISION clauses) and then running the translation defined in this memo again. Note that this does not affect the usage of YANG augments and or YANG deviations: YANG modules generated from SMIv2 modules can be augmented like any other YANG module, and YANG deviations can be used to document how an implementation deviates from the generated YANG module.
SMIv2モジュールから生成されたYANGモジュールは変更しないでください。元のSMIv2モジュールを変更し（SMIv2 LAST-UPDATED句とREVISION句を適切に更新して）、必要な変更を加えてから、このメモで定義されている変換を再度実行する必要があります。これは、YANG拡張機能やYANG偏差の使用に影響を与えないことに注意してください。SMIv2モジュールから生成されたYANGモジュールは、他のYANGモジュールと同様に拡張でき、YANG偏差を使用して、生成されたYANGモジュールからの実装の逸脱を文書化できます。
SMIv1 modules can be converted to YANG by first following the rules in [RFC3584] to convert the SMIv1 module to SMIv2 and then following the rules in this document to convert the obtained SMIv2 module to YANG.
SMIv1モジュールをYANGに変換するには、最初に[RFC3584]のルールに従ってSMIv1モジュールをSMIv2に変換し、次にこのドキュメントのルールに従って取得したSMIv2モジュールをYANGに変換します。
The SMIv2-to-YANG mapping is illustrated by examples showing the translation of parts of the IF-MIB [RFC2863], the DIFFSERV-MIB [RFC3289], and the RMON2-MIB [RFC4502] SMIv2 modules.
SMIv2-to-YANGマッピングは、IF-MIB [RFC2863]、DIFFSERV-MIB [RFC3289]、およびRMON2-MIB [RFC4502] SMIv2モジュールの一部の変換を示す例によって示されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、BCP 14 [RFC2119]で説明されているように解釈されます。
The SMIv2 base types and some well-known derived textual conventions are mapped to YANG types according to Appendix A. The mapping of the OCTET STRING depends on the context. If an OCTET STRING type has an associated DISPLAY-HINT, then the corresponding YANG base type is the string type. An implementation MUST format an OCTET STRING value according to the DISPLAY-HINT, as described in RFC 2579. If an OCTECT STRING type does not have an associated DISPLAY-HINT, the binary type is used. Similarly, the mapping of the INTEGER type depends on its usage as an enumeration or a 32-bit integral type. Implementations should provide implementation-specific options to handle situations where DISPLAY- HINTs are added during a revision of a module and backwards compatibility must be preserved, i.e., an added DISPLAY-HINT needs to be ignored.
SMIv2基本タイプといくつかのよく知られている派生テキストの表記法は、付録Aに従ってYANGタイプにマップされます。OCTETSTRINGのマッピングは、コンテキストによって異なります。 OCTET STRING型にDISPLAY-HINTが関連付けられている場合、対応するYANG基本型は文字列型です。 RFC 2579で説明されているように、実装はDISPLAY-HINTに従ってOCTET STRING値をフォーマットする必要があります。OCTECTSTRINGタイプに関連付けられたDISPLAY-HINTがない場合、バイナリタイプが使用されます。同様に、INTEGER型のマッピングは、列挙型または32ビット整数型としての使用に依存します。実装は、モジュールのリビジョン中にDISPLAY- HINTが追加され、下位互換性を維持する必要がある、つまり追加されたDISPLAY-HINTを無視する必要がある状況を処理する実装固有のオプションを提供する必要があります。
The mappings shown in Appendix A may require to import the ietf-yang-types, ietf-inet-types, or ietf-yang-smiv2 YANG modules since some SMIv2 types and textual conventions map to YANG types defined in the ietf-yang-types and ietf-inet-types YANG modules defined in [RFC6021] and the ietf-yang-smiv2 YANG module defined in this document. Implementations MUST add any additional imports required by the type mapping.
付録Aに示すマッピングでは、ietf-yang-types、ietf-inet-types、またはietf-yang-smiv2 YANGモジュールをインポートする必要がある場合があります。これは、一部のSMIv2タイプおよびテキストの規則が、ietf-yang-typesで定義されたYANGタイプにマッピングされるためです[RFC6021]で定義されているietf-inet-types YANGモジュールと、このドキュメントで定義されているietf-yang-smiv2 YANGモジュール。実装では、型マッピングに必要な追加のインポートを追加する必要があります。
SMIv2 modules are mapped to corresponding YANG modules. The generated YANG module name MUST be the same as the SMIv2 module name.
SMIv2モジュールは、対応するYANGモジュールにマップされます。生成されたYANGモジュール名は、SMIv2モジュール名と同じでなければなりません。
The YANG namespace MUST be constructed out of the IANA-registered prefix urn:ietf:params:xml:ns:yang:smiv2: (see Section 12) followed by the SMIv2 module name. Since SMIv2 module names can be assumed to be unique (see Section 3 in [RFC2578]), the resulting YANG namespace is unique.
YANGネームスペースは、IANAに登録されたプレフィックスurn：ietf：params：xml：ns：yang：smiv2：（セクション12を参照）とそれに続くSMIv2モジュール名から構成する必要があります。 SMIv2モジュール名は一意であると想定できるため（[RFC2578]のセクション3を参照）、結果のYANG名前空間は一意になります。
The YANG prefix MAY be derived from the SMIv2 module name using the module prefix generation algorithm described in Appendix B. The YANG prefix is supposed to be short, and it must be unique within the set of all prefixes used by a YANG module. The algorithm described in Appendix B generates such prefixes.
YANGプレフィックスは、付録Bで説明されているモジュールプレフィックス生成アルゴリズムを使用して、SMIv2モジュール名から派生する場合があります。YANGプレフィックスは短く、YANGモジュールが使用するすべてのプレフィックスのセット内で一意である必要があります。付録Bで説明されているアルゴリズムは、このようなプレフィックスを生成します。
SMIv2 IMPORT clauses are translated to YANG import statements. One major difference between the SMIv2 import mechanism and the YANG import mechanism is that SMIv2 IMPORT clauses import specific symbols from an SMIv2 module, while the YANG import statement imports all symbols of the referenced YANG module.
SMIv2 IMPORT句は、YANGインポートステートメントに変換されます。 SMIv2インポートメカニズムとYANGインポートメカニズムの主な違いの1つは、SMIv2 IMPORT句がSMIv2モジュールから特定のシンボルをインポートするのに対し、YANGインポートステートメントは参照されるYANGモジュールのすべてのシンボルをインポートすることです。
In order to produce correct and complete YANG import statements, the following rules MUST be used:
正しく完全なYANGインポートステートメントを生成するには、次のルールを使用する必要があります。
o Process each item in each SMIv2 IMPORT clause as follows:
o 各SMIv2 IMPORT句の各アイテムを次のように処理します。
1. If an import statement for this SMIv2 module has already been generated, then ignore this item.
1. このSMIv2モジュールのインポート文がすでに生成されている場合は、このアイテムを無視してください。
2. Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2- CONF, then ignore this item. Note that these two modules can be completely ignored since all definitions in these modules are translated by translation rules.
2. それ以外の場合、SMIv2モジュール名がSNMPv2-SMIまたはSNMPv2- CONFの場合は、この項目を無視してください。これらのモジュールのすべての定義は変換ルールによって変換されるため、これら2つのモジュールは完全に無視できることに注意してください。
3. Otherwise, if this item is a textual convention matching one of the textual conventions in the SMIv2 types column of Appendix A (e.g., MacAddress, PhysAddress, or TimeStamp) then ignore this item.
3. それ以外の場合、このアイテムが付録AのSMIv2タイプ列のテキスト表記のいずれかに一致するテキスト表記（MacAddress、PhysAddress、TimeStampなど）であれば、このアイテムを無視します。
4. Otherwise, if the item is used in a SYNTAX clause of an OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify, then generate an import statement as described below.
4. それ以外の場合、その項目が、MAX-ACCESSがアクセス可能ではないOBJECT-TYPEのSYNTAX句で使用されている場合は、以下の説明に従ってインポートステートメントを生成します。
5. Otherwise, if the item is used in an OBJECTS clause of a NOTIFICATION-TYPE, then generate an import statement as described below.
5. それ以外の場合、アイテムがNOTIFICATION-TYPEのOBJECTS句で使用されている場合は、以下の説明に従ってインポートステートメントを生成します。
6. Otherwise, if the item is used in an INDEX or AUGMENTS clause, then generate an import statement as described below.
6. それ以外の場合、アイテムがINDEX句またはAUGMENTS句で使用されていると、以下の説明に従ってインポート文が生成されます。
7. Otherwise, ignore this item. Some examples of this case are OBJECT IDENTIFIER assignments and objects that are only referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or NOTIFICATION-GROUP clauses.
7. それ以外の場合は、このアイテムを無視してください。このケースのいくつかの例は、OBJECT IDENTIFIER割り当てと、MODULE-COMPLIANCE、OBJECT-GROUP、またはNOTIFICATION-GROUP句でのみ参照されるオブジェクトです。
o Generate any additional import statements as required by the type translations according to the type mapping table Appendix A. This requires the translator to consider all the types used in the SMIv2 module in order to produce the imports.
o 型変換テーブルの付録Aに従って、型変換で必要な追加のインポートステートメントを生成します。これにより、トランスレータは、インポートを生成するためにSMIv2モジュールで使用されるすべての型を考慮する必要があります。
o Generate an import statement for the YANG module ietf-yang-smiv2 with the prefix smiv2.
o 接頭辞smiv2を使用して、YANGモジュールietf-yang-smiv2のインポート文を生成します。
The generated import statements use the untranslated SMIv2 module names or the names of well-known YANG modules as their argument. The import statement must contain a prefix statement. The prefixes MAY be generated by applying the module prefix generation algorithm described in Appendix B.
生成されたインポート文は、未翻訳のSMIv2モジュール名または既知のYANGモジュールの名前を引数として使用します。インポートステートメントには、プレフィックスステートメントが含まれている必要があります。プレフィックスは、付録Bで説明されているモジュールプレフィックス生成アルゴリズムを適用することによって生成される場合があります。
The translation of the IF-MIB [RFC2863] leads to the YANG module and namespace/prefix statement and the import statements shown below. The prefix is the translation of the SMIv2 module name IF-MIB to lowercase (consisting of two tokens and thus no further abbreviation).
IF-MIB [RFC2863]の変換により、YANGモジュール、名前空間/接頭辞ステートメント、および以下に示すインポートステートメントが生成されます。プレフィックスは、SMIv2モジュール名IF-MIBを小文字に変換したものです（2つのトークンで構成されているため、省略形はありません）。
module IF-MIB {
モジュールIF-MIB {
namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB";
prefix "if-mib";
import IANAifType-MIB { prefix "ianaiftype-mib"; }
import SNMPv2-TC { prefix "snmpv2-tc"; }
import ietf-yang-types { prefix "yang"; }
import ietf-yang-smiv2 { prefix "smiv2"; }
}
SMIv2 requires an invocation of the MODULE-IDENTITY macro to provide contact and revision history for a MIB module. The clauses of the SMIv2 MODULE-IDENTITY macro MUST be translated into YANG statements as detailed below.
SMIv2では、MIDUモジュールの連絡先と改訂履歴を提供するために、MODULE-IDENTITYマクロを呼び出す必要があります。 SMIv2 MODULE-IDENTITYマクロの句は、以下に詳述するようにYANGステートメントに変換する必要があります。
o The SMIv2 ORGANIZATION clause is mapped to the YANG organization statement.
o SMIv2 ORGANIZATION句は、YANG組織ステートメントにマップされます。
o The SMIv2 CONTACT-INFO clause is mapped to the YANG contact statement.
o SMIv2 CONTACT-INFO句は、YANG連絡先ステートメントにマップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o Each SMIv2 REVISION clause is mapped to a YANG revision statement. The revision is identified by the date argument of the SMIv2 REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are mapped to corresponding description statement nested in revision clauses.
o 各SMIv2 REVISION句は、YANGリビジョンステートメントにマップされます。改訂は、SMIv2 REVISION句の日付引数によって識別されます。 REVISION句のDESCRIPTIONサブ句は、revision句にネストされた対応する記述ステートメントにマップされます。
o The SMIv2 LAST-UPDATED clause is ignored if the associated date matches a REVISION clause. Otherwise, an additional revision statement is generated.
o 関連する日付がREVISION句と一致する場合、SMIv2 LAST-UPDATED句は無視されます。それ以外の場合、追加の改訂ステートメントが生成されます。
o A top-level YANG container is generated. The container's name is the SMIv2 module name, and the container MUST be config false. The generation of the top-level container MAY be skipped if the SMIv2 module does not define any objects that go into the top-level container (e.g., an SMIv2 module only defining textual conventions).
o トップレベルのYANGコンテナが生成されます。コンテナーの名前はSMIv2モジュール名であり、コンテナーは構成falseでなければなりません。 SMIv2モジュールがトップレベルコンテナーに入るオブジェクトを定義していない場合（たとえば、SMIv2モジュールがテキストの規則のみを定義している場合）、トップレベルコンテナーの生成はスキップされる場合があります。
o The object identifier value of the invocation of the SMIv2 MODULE-IDENTITY is translated into an smiv2:oid statement contained in an smiv2:alias statement representing the MODULE-IDENTITY macro invocation. Refer to the YANG extension defined in Section 10.
o SMIv2 MODULE-IDENTITYの呼び出しのオブジェクトID値は、MODULE-IDENTITYマクロ呼び出しを表すsmiv2：aliasステートメントに含まれるsmiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
While all proper SMIv2 modules must have exactly one MODULE-IDENTITY macro invocation, there are a few notable exceptions. The modules defining the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro. Furthermore, SMIv2 modules generated from SMIv1 modules may miss an invocation of the MODULE-IDENTITY macro as well. In such cases, it is preferable to not generate organization, contact, description, or revision statements.
すべての適切なSMIv2モジュールは、正確に1つのMODULE-IDENTITYマクロを呼び出す必要がありますが、いくつかの注目すべき例外があります。 SMIv2言語を定義するモジュール（つまり、SNMPv2-SMI、SNMPv2-TC、およびSNMPv2-CONFモジュール）は、MODULE-IDENTITYマクロを呼び出しません。さらに、SMIv1モジュールから生成されたSMIv2モジュールは、MODULE-IDENTITYマクロの呼び出しも逃す可能性があります。そのような場合、組織、連絡先、説明、または改訂ステートメントを生成しないことが望ましいです。
The translation of the MODULE-IDENTITY of the IF-MIB [RFC2863] leads to the following YANG statements:
IF-MIB [RFC2863]のMODULE-IDENTITYを変換すると、次のYANGステートメントが生成されます。
organization "IETF Interfaces MIB Working Group";
組織「IETFインターフェイスMIBワーキンググループ」;
contact "Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US
「キースマックロリーシスコシステムズ株式会社170 West Tasman Drive San Jose、CA 95134-1706 US
408-526-5260 kzm@cisco.com";
４０８ー５２６ー５２６０ ｋｚｍ＠しｓこ。こｍ”；
description "The MIB module to describe generic objects for network interface sub-layers. This MIB is an updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC 1229.";
説明 "ネットワークインターフェイスサブレイヤーの汎用オブジェクトを記述するMIBモジュール。このMIBは、MIB-IIのifTableの更新バージョンであり、RFC 1229で定義されている拡張機能を組み込んでいます。";
revision "2000-06-14" {
description
"Clarifications agreed upon by the Interfaces MIB WG, and
published as RFC 2863.";
}
revision "1996-02-28" {
description
"Revisions made by the Interfaces MIB WG, and published in
RFC 2233.";
}
revision "1993-11-08" {
description
"Initial revision, published as part of RFC 1573.";
}
container IF-MIB {
config false;
}
The SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define new types derived from the SMIv2 base types. Invocations of the TEXTUAL-CONVENTION macro MUST be translated into YANG typedef statements as detailed below.
SMIv2は、TEXTUAL-CONVENTIONマクロの呼び出しを使用して、SMIv2基本タイプから派生した新しいタイプを定義します。 TEXTUAL-CONVENTIONマクロの呼び出しは、以下に詳述するように、YANG typedefステートメントに変換する必要があります。
The name of the TEXTUAL-CONVENTION macro invocation is used as the name of the generated typedef statement. The clauses of the SMIv2 TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in the typedef statement as follows:
TEXTUAL-CONVENTIONマクロ呼び出しの名前は、生成されたtypedefステートメントの名前として使用されます。 SMIv2 TEXTUAL-CONVENTIONマクロの句は、typedefステートメントに埋め込まれたYANGステートメントに次のようにマップされます。
o The SMIv2 DISPLAY-HINT clause is used to determine the type mapping of types derived form the OCTET STRING type as explained in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to generate a regular expression for the YANG pattern statement within the type statement.
o SMIv2 DISPLAY-HINT句は、セクション2で説明されているように、OCTET STRINGタイプから派生したタイプのタイプマッピングを決定するために使用されます。さらに、DISPLAY-HINT値は、タイプ内のYANGパターンステートメントの正規表現を生成するために使用できます。ステートメント。
o The SMIv2 DISPLAY-HINT is translated into an smiv2:display-hint statement. Refer to the YANG extension defined in Section 10.
o SMIv2 DISPLAY-HINTは、smiv2：display-hintステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The SMIv2 SYNTAX clause is mapped to the YANG type statement. SMIv2 range restrictions are mapped to YANG range statements, while SMIv2 length restrictions are mapped to YANG length statements. SMIv2 INTEGER enumerations are mapped to YANG enum/ value statements. SMIv2 BITS are mapped to YANG bit/position statements. For OCTET STRING types that are mapped to a YANG string base type (see Section 2), the length specified in the YANG length statement must be consistent with the stringified representation of values. If an implementation is unable to derive a proper length restrictions, then the YANG length statement MUST be omitted.
o SMIv2 SYNTAX句は、YANGタイプのステートメントにマップされます。 SMIv2範囲の制限はYANG範囲ステートメントにマップされ、SMIv2の長さ制限はYANGの長さステートメントにマップされます。 SMIv2 INTEGER列挙は、YANG enum / valueステートメントにマップされます。 SMIv2 BITSは、YANGビット/位置ステートメントにマップされます。 YANG文字列の基本型（セクション2を参照）にマップされるOCTET STRING型の場合、YANGの長さステートメントで指定された長さは、値の文字列表現と一致している必要があります。実装が適切な長さ制限を導出できない場合、YANG長さステートメントは省略されなければなりません（MUST）。
This translation assumes that labels of named numbers and named bits do not change when an SMIv2 module is revised. This is consistent with the clarification of the SMIv2 module revision rules in Section 4.9 of [RFC4181].
この変換では、SMIv2モジュールが改訂されても、名前付き番号と名前付きビットのラベルは変更されないと想定しています。これは、[RFC4181]のセクション4.9のSMIv2モジュールリビジョンルールの明確化と一致しています。
The translations of the OwnerString and InterfaceIndex textual conventions of the IF-MIB [RFC2863] are shown below.
IF-MIB [RFC2863]のOwnerStringおよびInterfaceIndexテキスト表記法の翻訳を以下に示します。
typedef OwnerString {
type string {
length "0..255";
pattern '\p{IsBasicLatin}{0,255}';
}
status deprecated;
description
"This data type is used to model an administratively
assigned name of the owner of a resource. This information
is taken from the NVT ASCII character set. It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number. In some cases
the agent itself will be the owner of an entry. In these
cases, this string shall be set to a string starting with
'agent'.";
smiv2:display-hint "255a";
}
typedef InterfaceIndex {
type int32 {
range "1..2147483647";
}
description
"A unique value, greater than zero, for each interface or
interface sub-layer in the managed system. It is
recommended that values are assigned contiguously starting
from 1. The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's
network management system to the next re-initialization.";
smiv2:display-hint "d";
}
The translation of the IfDirection textual convention of the DIFFSERV-MIB [RFC3289] is shown below.
DIFFSERV-MIB [RFC3289]のIfDirectionテキスト表記法の翻訳を以下に示します。
typedef IfDirection {
type enumeration {
enum inbound { value 1; }
enum outbound { value 2; }
}
description
"IfDirection specifies a direction of data travel on an
interface. 'inbound' traffic is operated on during reception
from the interface, while 'outbound' traffic is operated on
prior to transmission on the interface.";
}
The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER assignments are translated into smiv2:alias statements. Refer to the YANG extension defined in Section 10.
SMIv2は、OBJECT IDENTIFIER割り当てを使用して、OBJECT IDENTIFIERツリー内の中間ノードの名前を導入します。 OBJECT IDENTIFIER割り当ては、smiv2：aliasステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
The SMIv2 uses the OBJECT-TYPE macro to define objects and the structure of conceptual tables. Objects exist either as scalars (exactly one instance within an SNMP context) or columnar objects within conceptual tables (zero or multiple instances within an SNMP context). A number of auxiliary objects define the index (key) of a conceptual table. Furthermore, conceptual tables can be augmented by other conceptual tables. All these differences must be taken into account when translating SMIv2 OBJECT-TYPE macro invocations to YANG. Invocations of the OBJECT-TYPE macro MUST be translated into YANG statements as detailed below.
SMIv2は、OBJECT-TYPEマクロを使用して、オブジェクトと概念テーブルの構造を定義します。オブジェクトは、スカラー（SNMPコンテキスト内のインスタンスは1つだけ）または概念的なテーブル内の列オブジェクト（SNMPコンテキスト内のゼロまたは複数のインスタンス）として存在します。いくつかの補助オブジェクトは、概念的なテーブルのインデックス（キー）を定義します。さらに、概念テーブルは、他の概念テーブルによって拡張できます。 SMIv2 OBJECT-TYPEマクロ呼び出しをYANGに変換するときは、これらすべての違いを考慮する必要があります。 OBJECT-TYPEマクロの呼び出しは、以下に詳述するようにYANGステートメントに変換する必要があります。
SMIv2 OBJECT-TYPE macro invocations defining scalars or columnar objects with a MAX-ACCESS of "not-accessible", "read-only", "read-write", and "read-create" are translated to YANG leaf statements. Additionally, columnar objects with a MAX-ACCESS of "accessible-for-notify" are translated to YANG leaf statements if that columnar object is part of the INDEX clause of the table containing that columnar object. The name of the leaf is the name associated with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 OBJECT-TYPE macro invocations with a MAX-ACCESS of
MAX-ACCESSが「アクセス不可」、「読み取り専用」、「読み取り-書き込み」、および「読み取り-作成」のスカラーまたは列オブジェクトを定義するSMIv2 OBJECT-TYPEマクロ呼び出しは、YANGリーフステートメントに変換されます。さらに、「accessible-for-notify」のMAX-ACCESSを持つ円柱オブジェクトは、その円柱オブジェクトがその円柱オブジェクトを含むテーブルのINDEX句の一部である場合、YANGリーフステートメントに変換されます。リーフの名前は、SMIv2 OBJECT-TYPEマクロの呼び出しに関連付けられた名前です。 MAX-ACCESS ofのSMIv2 OBJECT-TYPEマクロ呼び出し
"accessible-for-notify" are not translated to YANG data tree leafs but instead are translated into YANG notification leafs.
"accessible-for-notify"はYANGデータツリーリーフに変換されませんが、代わりにYANG通知リーフに変換されます。
Leaf statements for scalar objects are created in a container representing the scalar's parent node in the OID tree. This container is named after the scalar's parent node in the OID tree and placed in the top-level container representing the SMIv2 module; see Section 4.1. In the rare case that the scalar's parent node has multiple names, the automatic translation MUST fail with an error, and the name clash needs to be investigated and fixed manually. In case a previous revision of the SMIv2 module did not have an ambiguity, then the name used by the previous revision MUST be used. The leaf statements representing columnar objects are created in the list representing a conceptual row; see Section 7.3.
スカラーオブジェクトのリーフステートメントは、OIDツリー内のスカラーの親ノードを表すコンテナーに作成されます。このコンテナーは、OIDツリー内のスカラーの親ノードにちなんで名付けられ、SMIv2モジュールを表す最上位のコンテナーに配置されます。セクション4.1を参照してください。スカラーの親ノードが複数の名前を持つまれなケースでは、自動変換はエラーで失敗する必要があり、名前の衝突を調査して手動で修正する必要があります。 SMIv2モジュールの以前のリビジョンに曖昧さがなかった場合、以前のリビジョンで使用されていた名前を使用する必要があります。列のオブジェクトを表すリーフステートメントは、概念的な行を表すリストに作成されます。セクション7.3を参照してください。
o The SMIv2 SYNTAX clause is mapped to the YANG type statement. SMIv2 range restrictions are mapped to YANG range statements, while SMIv2 length restrictions are mapped to YANG length statements. SMIv2 INTEGER enumerations are mapped to YANG enum/ value statements. SMIv2 BITS are mapped to YANG bit/position statements. For OCTET STRING types that are mapped to a YANG string base type (see Section 2), the length specified in the YANG length statement must be consistent with the stringified representation of values. If an implementation is unable to derive proper length restrictions, then the YANG length statement MUST be omitted.
o SMIv2 SYNTAX句は、YANGタイプのステートメントにマップされます。 SMIv2範囲の制限はYANG範囲ステートメントにマップされ、SMIv2の長さ制限はYANGの長さステートメントにマップされます。 SMIv2 INTEGER列挙は、YANG enum / valueステートメントにマップされます。 SMIv2 BITSは、YANGビット/位置ステートメントにマップされます。 YANG文字列の基本型（セクション2を参照）にマップされるOCTET STRING型の場合、YANGの長さステートメントで指定された長さは、値の文字列表現と一致している必要があります。実装が適切な長さ制限を導出できない場合は、YANG長さステートメントを省略しなければなりません（MUST）。
o The SMIv2 UNITS clause is mapped to the YANG units statement.
o SMIv2 UNITS句は、YANG unitsステートメントにマップされます。
o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access statement. Refer to the YANG extension defined in Section 10.
o SMIv2 MAX-ACCESSは、smiv2：max-accessステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The SMIv2 DEFVAL clause is mapped to an smiv2:defval statement. Refer to the YANG extension defined in Section 10.
o SMIv2 DEFVAL句は、smiv2：defvalステートメントにマップされます。セクション10で定義されているYANG拡張を参照してください。
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 OBJECT-TYPEマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
This translation assumes that labels of named numbers and named bits do not change when an SMIv2 module is revised. This is consistent with the clarification of the SMIv2 module revision rules in Section 4.9 of [RFC4181].
この変換では、SMIv2モジュールが改訂されても、名前付き番号と名前付きビットのラベルは変更されないと想定しています。これは、[RFC4181]のセクション4.9のSMIv2モジュールリビジョンルールの明確化と一致しています。
The translations of the ifNumber scalar object and the ifIndex columnar object of the IF-MIB [RFC2863] are shown below. Since ifNumber is a scalar object in the interfaces branch of the IF-MIB, the YANG leaf ifNumber will be placed in a YANG container called interfaces, which is registered in the top-level container IF-MIB.
IF-MIB [RFC2863]のifNumberスカラーオブジェクトとifIndex列オブジェクトの変換を以下に示します。 ifNumberはIF-MIBのインターフェースブランチのスカラーオブジェクトであるため、YANGリーフifNumberは、インターフェースと呼ばれるYANGコンテナーに配置されます。これは、最上位のコンテナーIF-MIBに登録されています。
leaf ifNumber {
type int32;
description
"The number of network interfaces (regardless of their
current state) present on this system.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.1";
}
leaf ifIndex {
type if-mib:InterfaceIndex;
description
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.2.1.1";
}
An OBJECT-TYPE macro invocation defining a non-augmenting conceptual table is translated to a YANG container statement using the name of the OBJECT-TYPE macro invocation. This container is created in the top-level container representing the SMIv2 module. The clauses of the macro are translated as follows:
非拡張概念テーブルを定義するOBJECT-TYPEマクロ呼び出しは、OBJECT-TYPEマクロ呼び出しの名前を使用してYANGコンテナーステートメントに変換されます。このコンテナは、SMIv2モジュールを表す最上位のコンテナに作成されます。マクロの句は次のように変換されます。
o The SMIv2 SYNTAX clause is ignored
o SMIv2 SYNTAX句は無視されます
o The SMIv2 UNITS clause is ignored.
o SMIv2 UNITS句は無視されます。
o The SMIv2 MAX-ACCESS clause is ignored.
o SMIv2 MAX-ACCESS句は無視されます。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 OBJECT-TYPEマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
An OBJECT-TYPE macro invocation defining a conceptual row is translated to a YANG list statement. It is contained in the YANG container representing the conceptual table. The generated list uses the name of the row OBJECT-TYPE macro invocation. The clauses of the OBJECT-TYPE macro are translated as follows:
概念的な行を定義するOBJECT-TYPEマクロの呼び出しは、YANGリストステートメントに変換されます。これは、概念表を表すYANGコンテナーに含まれています。生成されたリストは、行OBJECT-TYPEマクロ呼び出しの名前を使用します。 OBJECT-TYPEマクロの句は次のように変換されます。
o The SMIv2 SYNTAX clause is ignored.
o SMIv2 SYNTAX句は無視されます。
o The SMIv2 UNITS clause is ignored.
o SMIv2 UNITS句は無視されます。
o The SMIv2 MAX-ACCESS clause is ignored.
o SMIv2 MAX-ACCESS句は無視されます。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The SMIv2 INDEX clause is mapped to the YANG key clause listing the columnar objects forming the key of the YANG list. If the same object appears more than once in the INDEX clause, append '_<n>' to the duplicate object name(s) where '<n>' counts the occurrences of the object in the INDEX clause, starting from 2. Additional leaf statements must be created to define the leafs introduced.
o SMIv2 INDEX句は、YANGリストのキーを形成する列オブジェクトをリストするYANGキー句にマップされます。同じオブジェクトがINDEX句で複数回出現する場合は、重複するオブジェクト名に「_ <n>」を追加します。「<n>」は、INDEX句でのオブジェクトの出現を2から数えます。導入されたリーフを定義するには、リーフステートメントを作成する必要があります。
o If the SMIv2 INDEX clause contains the IMPLIED keyword, then an smiv2:implied statement is generated to record the name of the object preceded by the IMPLIED keyword. Refer to the YANG extension defined in Section 10.
o SMIv2 INDEX句にIMPLIEDキーワードが含まれている場合、smiv2：impliedステートメントが生成され、IMPLIEDキーワードの前にオブジェクトの名前が記録されます。セクション10で定義されているYANG拡張を参照してください。
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 OBJECT-TYPEマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
Within the list statement, YANG leaf statements are created for columnar objects as described in Section 7.1. For objects listed in the SMIv2 INDEX clause that are not part of the conceptual table itself, YANG leaf statements of type leafref pointing to the referenced definition are created.
リストステートメント内で、セクション7.1で説明されているように、YANGリーフステートメントが列オブジェクトに対して作成されます。概念表自体の一部ではないSMIv2 INDEX節にリストされているオブジェクトの場合、参照された定義を指すタイプleafrefのYANGリーフステートメントが作成されます。
The translation of the definition of the ifTable of the IF-MIB [RFC2863] is shown below.
IF-MIB [RFC2863]のifTableの定義の翻訳を以下に示します。
container ifTable {
description
"A list of interface entries. The number of entries is
given by the value of ifNumber.";
smiv2:oid "1.3.6.1.2.1.2.2";
list ifEntry {
key "ifIndex";
description
"An entry containing management information applicable to a
particular interface.";
smiv2:oid "1.3.6.1.2.1.2.2.1";
leaf ifIndex {
type if-mib:InterfaceIndex;
description
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.2.2.1.1";
}
// ...
}
}
The translation of the definition of the ifRcvAddressTable of the IF-MIB [RFC2863] is shown below.
IF-MIB [RFC2863]のifRcvAddressTableの定義の変換を以下に示します。
container ifRcvAddressTable { description "This table contains an entry for each address (broadcast, multicast, or uni-cast) for which the system will receive packets/frames on a particular interface, except as follows:
コンテナifRcvAddressTable {説明 "このテーブルには、システムが特定のインターフェイスでパケット/フレームを受信する各アドレス（ブロードキャスト、マルチキャスト、またはユニキャスト）のエントリが含まれます。ただし、次の場合は除きます。
- for an interface operating in promiscuous mode, entries are only required for those addresses for which the system would receive frames were it not operating in promiscuous mode.
- 無差別モードで動作しているインターフェイスの場合、エントリは、無差別モードで動作していない場合にシステムがフレームを受信するアドレスに対してのみ必要です。
- for 802.5 functional addresses, only one entry is required, for the address which has the functional address bit ANDed with the bit mask of all functional addresses for which the interface will accept frames.
- 802.5機能アドレスの場合、インターフェースがフレームを受け入れるすべての機能アドレスのビットマスクとANDされた機能アドレスビットを持つアドレスに対して、1つのエントリのみが必要です。
A system is normally able to use any unicast address which
corresponds to an entry in this table as a source address.";
smiv2:oid "1.3.6.1.2.1.31.1.4";
list ifRcvAddressEntry {
key "ifIndex ifRcvAddressAddress";
description
"A list of objects identifying an address for which the
system will accept packets/frames on the particular
interface identified by the index value ifIndex.";
smiv2:oid "1.3.6.1.2.1.31.1.4.1";
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
leaf ifRcvAddressAddress {
type yang:phys-address;
description
"An address for which the system will accept packets/frames
on this entry's interface.";
smiv2:max-access "not-accessible";
smiv2:oid "1.3.6.1.2.1.31.1.4.1.1";
}
// ...
}
}
The translation of the definition of the alHostTable of the RMON2-MIB [RFC4502] is shown below.
RMON2-MIB [RFC4502]のalHostTableの定義の翻訳を以下に示します。
container alHostTable { description "A collection of statistics for a particular protocol from a particular network address that has been discovered on an interface of this device.
コンテナalHostTable {説明 "このデバイスのインターフェイスで発見された特定のネットワークアドレスからの特定のプロトコルの統計のコレクション。
The probe will populate this table for all protocols in the protocol directory table whose value of protocolDirHostConfig is equal to supportedOn(3), and will delete any entries whose protocolDirEntry is deleted or has a protocolDirHostConfig value of supportedOff(2).
プローブは、protocolDirHostConfigの値がsupportedOn（3）と等しいプロトコルディレクトリテーブル内のすべてのプロトコルについてこのテーブルを生成し、protocolDirEntryが削除されているか、protocolDirHostConfig値がsupportedOff（2）であるエントリを削除します。
The probe will add to this table all addresses
seen as the source or destination address in all packets with
no MAC errors and will increment octet and packet counts in
the table for all packets with no MAC errors. Further,
entries will only be added to this table if their address
exists in the nlHostTable and will be deleted from this table
if their address is deleted from the nlHostTable.";
smiv2:oid "1.3.6.1.2.1.16.16.1";
list alHostEntry {
key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex "
+ "nlHostAddress protocolDirLocalIndex_2";
description
"A conceptual row in the alHostTable.
The hlHostControlIndex value in the index identifies the hlHostControlEntry on whose behalf this entry was created. The first protocolDirLocalIndex value in the index identifies the network-layer protocol of the address. The nlHostAddress value in the index identifies the network-layer address of this entry. The second protocolDirLocalIndex value in the index identifies the protocol that is counted by this entry.
インデックスのhlHostControlIndex値は、このエントリが作成されたhlHostControlEntryを識別します。インデックスの最初のprotocolDirLocalIndex値は、アドレスのネットワーク層プロトコルを識別します。インデックスのnlHostAddress値は、このエントリのネットワーク層アドレスを識別します。インデックスの2番目のprotocolDirLocalIndex値は、このエントリによってカウントされるプロトコルを識別します。
An example of the indexing in this entry is alHostOutPkts.1.783495.18.4.128.2.6.6.34.
このエントリのインデックスの例は、alHostOutPkts.1.783495.18.4.128.2.6.6.34です。
Note that some combinations of index values may result in an
index that exceeds 128 sub-identifiers in length, which exceeds
the maximum for the SNMP protocol. Implementations should take
care to avoid such combinations.";
smiv2:oid "1.3.6.1.2.1.16.16.1.1";
// ...
／／ 。。。
leaf protocolDirLocalIndex {
type leafref {
path "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:protocolDirTable/"
+ "rmon2-mib:protocolDirEntry/"
+ "rmon2-mib:protocolDirLocalIndex";
}
}
// ...
／／ 。。。
leaf protocolDirLocalIndex_2 {
type leafref {
path "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:protocolDirTable/"
+ "rmon2-mib:protocolDirEntry/"
+ "rmon2-mib:protocolDirLocalIndex";
}
}
// ...
}
}
An OBJECT-TYPE macro invocation defining an augmenting conceptual table is translated to a YANG smiv2:alias statement. Refer to the YANG extension defined in Section 10. The clauses of the macro are translated as follows:
拡張概念テーブルを定義するOBJECT-TYPEマクロ呼び出しは、YANG smiv2：aliasステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。マクロの句は次のように変換されます。
o The SMIv2 SYNTAX clause is ignored.
o SMIv2 SYNTAX句は無視されます。
o The SMIv2 UNITS clause is ignored.
o SMIv2 UNITS句は無視されます。
o The SMIv2 MAX-ACCESS clause is ignored.
o SMIv2 MAX-ACCESS句は無視されます。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 OBJECT-TYPEマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
An OBJECT-TYPE macro invocation defining a conceptual row augmentation is translated to a YANG smiv2:alias statement and a YANG augment statement using the path to the augmented table as its argument. The clauses of the OBJECT-TYPE macro are translated as follows:
概念的な行の拡張を定義するOBJECT-TYPEマクロの呼び出しは、拡張テーブルへのパスを引数として使用して、YANG smiv2：aliasステートメントとYANG拡張ステートメントに変換されます。 OBJECT-TYPEマクロの句は次のように変換されます。
o The SMIv2 SYNTAX clause is ignored.
o SMIv2 SYNTAX句は無視されます。
o The SMIv2 UNITS clause is ignored.
o SMIv2 UNITS句は無視されます。
o The SMIv2 MAX-ACCESS clause is ignored.
o SMIv2 MAX-ACCESS句は無視されます。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The value of the SMIv2 OBJECT-TYPE macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 OBJECT-TYPEマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
Within the augment statement, YANG leaf statements are created as described in Section 7.1.
augmentステートメント内では、YANGリーフステートメントがセクション7.1で説明されているように作成されます。
The translation of the definition of the ifXTable of the IF-MIB [RFC2863] is shown below.
IF-MIB [RFC2863]のifXTableの定義の翻訳を以下に示します。
smiv2:alias "ifXTable" {
description
"A list of interface entries. The number of entries is
given by the value of ifNumber. This table contains
additional objects for the interface table.";
smiv2:oid "1.3.6.1.2.1.31.1.1";
}
smiv2:alias "ifXEntry" {
description
"An entry containing additional management information
applicable to a particular interface.";
smiv2:oid "1.3.6.1.2.1.31.1.1.1";
}
augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" {
description
"An entry containing additional management information
applicable to a particular interface.";
smiv2:oid "1.3.6.1.2.1.31.1.1.1";
leaf ifName {
type snmpv2-tc:DisplayString;
description
"The textual name of the interface. The value of this
object should be the name of the interface as assigned by
the local device and should be suitable for use in commands
entered at the device's `console'. This might be a text
name, such as `le0' or a simple port number, such as `1',
depending on the interface naming syntax of the device. If
several entries in the ifTable together represent a single
interface as named by the device, then each will have the
same value of ifName. Note that for an agent which responds
to SNMP queries concerning an interface on some other
(proxied) device, then the value of ifName for such an
interface is the proxied device's local name for it.
If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string.";
smiv2:max-access "read-only";
smiv2:oid "1.3.6.1.2.1.31.1.1.1.1";
}
// ... }
／／ 。。。 ｝
The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define information about an OBJECT IDENTIFIER assignment. Invocations of the OBJECT-IDENTITY macro MUST be translated into YANG identity statements as detailed below.
SMIv2は、OBJECT-IDENTITYマクロの呼び出しを使用して、OBJECT IDENTIFIER割り当てに関する情報を定義します。 OBJECT-IDENTITYマクロの呼び出しは、以下で詳しく説明するように、YANG IDステートメントに変換する必要があります。
The name of the OBJECT-IDENTITY macro invocation is used as the name of the generated identity statement. The generated identity statement uses the smiv2:object-identity defined in Section 10 as its base. The clauses of the SMIv2 OBJECT-IDENTITY macro are mapped to YANG statements as follows:
OBJECT-IDENTITYマクロ呼び出しの名前は、生成されたIDステートメントの名前として使用されます。生成されたIDステートメントは、セクション10で定義されたsmiv2：object-identityをベースとして使用します。 SMIv2 OBJECT-IDENTITYマクロの句は、次のようにYANGステートメントにマップされます。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The value of the SMIv2 OBJECT-IDENTITY macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 OBJECT-IDENTITYマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
The translation of the diffServTBParamSimpleTokenBucket of the DIFFSERV-MIB [RFC3289] is shown below. (Please note that the description should refer to RFC 3290, Section 5.1.3.)
DIFFSERV-MIB [RFC3289]のdiffServTBParamSimpleTokenBucketの変換を以下に示します。 （説明はRFC 3290のセクション5.1.3を参照する必要があります）。
identity diffServTBParamSimpleTokenBucket {
base "smiv2:object-identity";
description
"Two Parameter Token Bucket Meter as described in the Informal
Differentiated Services Model section 5.2.3.";
smiv2:oid "1.3.6.1.2.1.97.3.1.1";
}
SMIv2 provides the NOTIFICATION-TYPE macro to define event notifications. YANG provides the notification statement for the same purpose. Invocations of the NOTIFICATION-TYPE macro MUST be translated into YANG notification statements as detailed below.
SMIv2は、イベント通知を定義するNOTIFICATION-TYPEマクロを提供します。 YANGは同じ目的で通知ステートメントを提供します。 NOTIFICATION-TYPEマクロの呼び出しは、以下に詳述するように、YANG通知ステートメントに変換する必要があります。
The name of the NOTIFICATION-TYPE macro invocation is used as the name of the generated notification statement. The clauses of the NOTIFICATION-TYPE macro are mapped to YANG statements embedded in the notification statement as follows.
NOTIFICATION-TYPEマクロ呼び出しの名前は、生成された通知ステートメントの名前として使用されます。 NOTIFICATION-TYPEマクロの句は、次のように通知ステートメントに埋め込まれたYANGステートメントにマップされます。
o The SMIv2 OBJECTS clause is mapped to a sequence of YANG containers. For each object listed in the OBJECTS clause value, a YANG container statement is generated. The name of this container is the string "object-<n>", where <n> is the position of the object in the value of the OBJECTS clause (first element has position 1). If the current object belongs to a conceptual table, then a sequence of leaf statements is generated for each INDEX object of the conceptual table. These leafs are named after the INDEX objects and of type leafref. Finally, a leaf statement is generated named after the current object. If the current object has a MAX-ACCESS of "read-only", "read-write", or "read-create", then the generated leaf is of type leafref. Otherwise, if the current object has a MAX-ACCESS of "accessible-for-notify", then a leaf is generated, following the steps in Section 7.1.
o SMIv2 OBJECTS句は、YANGコンテナーのシーケンスにマップされます。 OBJECTS句の値にリストされているオブジェクトごとに、YANGコンテナーステートメントが生成されます。このコンテナの名前は文字列「object- <n>」です。<n>は、OBJECTS句の値におけるオブジェクトの位置です（最初の要素の位置は1です）。現在のオブジェクトが概念テーブルに属している場合、概念テーブルの各INDEXオブジェクトに対して一連のリーフステートメントが生成されます。これらのリーフは、INDEXオブジェクトとleafrefタイプの名前が付けられています。最後に、現在のオブジェクトにちなんで名前が付けられたリーフステートメントが生成されます。現在のオブジェクトのMAX-ACCESSが「read-only」、「read-write」、または「read-create」の場合、生成される葉のタイプはleafrefです。それ以外の場合、現在のオブジェクトのMAX-ACCESSが「accessible-for-notify」であると、7.1節の手順に従ってリーフが生成されます。
o The SMIv2 STATUS clause is mapped to the YANG status statement. The generation of the YANG status statement is skipped if the value of the STATUS clause is current.
o SMIv2のSTATUS句は、YANGステータスステートメントにマップされます。 STATUS句の値が現在の場合、YANGステータスステートメントの生成はスキップされます。
o The SMIv2 DESCRIPTION clause is mapped to the YANG description statement.
o SMIv2 DESCRIPTION句は、YANG記述ステートメントにマップされます。
o The SMIv2 REFERENCE clause is mapped to the YANG reference statement.
o SMIv2 REFERENCE句は、YANG参照ステートメントにマップされます。
o The value of the SMIv2 NOTIFICATION-TYPE macro invocation is translated into an smiv2:oid statement. Refer to the YANG extension defined in Section 10.
o SMIv2 NOTIFICATION-TYPEマクロ呼び出しの値は、smiv2：oidステートメントに変換されます。セクション10で定義されているYANG拡張を参照してください。
The translation of the linkDown notification of the IF-MIB [RFC2863] is shown below.
IF-MIB [RFC2863]のlinkDown通知の変換を以下に示します。
notification linkDown {
description
"A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus.";
smiv2:oid "1.3.6.1.6.3.1.1.5.3";
container object-1 {
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
}
container object-2 {
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
leaf ifAdminStatus {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifAdminStatus";
}
}
}
container object-3 {
leaf ifIndex {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifIndex";
}
}
leaf ifOperStatus {
type leafref {
path "/if-mib:IF-MIB/if-mib:ifTable" +
"/if-mib:ifEntry/if-mib:ifOperStatus";
}
}
}
}
This section defines some YANG extension statements that can be used to capture some information present in SMIv2 modules that is not translated into core YANG statements. The YANG module references [RFC2578] and [RFC2579].
このセクションでは、コアYANGステートメントに変換されないSMIv2モジュールに存在するいくつかの情報をキャプチャするために使用できるいくつかのYANG拡張ステートメントを定義します。 YANGモジュールは[RFC2578]および[RFC2579]を参照します。
<CODE BEGINS> file "ietf-yang-smiv2@2012-06-22.yang"
module ietf-yang-smiv2 {
モジュールietf-yang-smiv2 {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2";
prefix "smiv2";
organization "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
組織「IETF NETMOD（NETCONFデータモデリング言語）ワーキンググループ」;
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: David Kessens
<mailto:david.kessens@nsn.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>";
description "This module defines YANG extensions that are used to translate SMIv2 concepts into YANG.
説明「このモジュールは、SMIv2の概念をYANGに変換するために使用されるYANG拡張を定義します。
Copyright (c) 2012 IETF Trust and the persons identified as authors of the code. All rights reserved.
Copyright（c）2012 IETF Trustおよびコードの作成者として識別された人物。全著作権所有。
Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions
IETFトラストの法的条項のセクション4.cに記載されているSimplified BSD Licenseに従い、変更の有無にかかわらず、ソース形式およびバイナリ形式での再配布および使用は許可され、それに含まれるライセンス条項に従います。
Relating to IETF Documents (http://trustee.ietf.org/license-info).
IETFドキュメント（http://trustee.ietf.org/license-info）に関連しています。
This version of this YANG module is part of RFC 6643; see the RFC itself for full legal notices.";
このYANGモジュールのこのバージョンはRFC 6643の一部です。完全な法的通知については、RFC自体を参照してください。 ";
revision 2012-06-22 {
description
"Initial revision.";
reference
"RFC 6643: Translation of Structure of Management Information
Version 2 (SMIv2) MIB Modules to YANG Modules";
}
identity object-identity {
description
"Base identity for all SMIv2 OBJECT-IDENTITYs.";
}
typedef opaque {
type binary;
description
"The Opaque type supports the capability to pass arbitrary ASN.1
syntax. A value is encoded using the ASN.1 Basic Encoding Rules
into a string of octets. This, in turn, is encoded as an OCTET
STRING, in effect 'double-wrapping' the original ASN.1 value.
In the value set and its semantics, this type is equivalent to
the Opaque type of the SMIv2. This type exists in the SMIv2
solely for backward-compatibility reasons and this is also
true for this YANG data type.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension display-hint {
argument "format";
description
"The display-hint statement takes as an argument the DISPLAY-HINT
assigned to an SMIv2 textual convention.";
reference
"RFC 2579: Textual Conventions for SMIv2";
}
extension max-access {
argument "access";
description
"The max-access statement takes as an argument the MAX-ACCESS
assigned to an SMIv2 object definition.
The MAX-ACCESS value is SMIv2 specific and has no impact on
the access provided to YANG objects through protocols such
as NETCONF.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension defval {
argument "value";
description
"The defval statement takes as an argument a default value
defined by an SMIv2 DEFVAL clause. Note that the value is in
the SMIv2 value space defined by the SMIv2 syntax of the
corresponding object and not in the YANG value space
defined by the corresponding YANG data type.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension implied {
argument "index";
description
"If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then
the implied statement is present in the YANG module and takes as
an argument the name of the IMPLIED index object.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension alias {
argument "descriptor";
description
"The alias statement introduces an SMIv2 descriptor. The body of
the alias statement is expected to contain an oid statement that
provides the numeric OID associated with the descriptor.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension oid {
argument "value";
description
"The oid statement takes as an argument the object identifier
assigned to an SMIv2 definition. The object identifier value
is written in decimal dotted notation.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
extension subid {
argument "value";
description
"The subid statement takes as an argument the last sub-identifier
of the object identifier assigned to an SMIv2 definition. The
sub-identifier value is a single positive decimal natural number.
The subid statement may not be used as a substatement to any
top-level node in a YANG document. The subid substatement may
be used only as a substatement to a node having a parent node
defined with either an smiv2:oid or smiv2:subid substatement.";
reference
"RFC 2578: Structure of Management Information Version 2 (SMIv2)";
}
}
｝
<CODE ENDS>
<コード終了>
The result of the translation of SMIv2 MIB modules into YANG modules, even if SMIv2 objects are read-write or read-create, consists of read-only (config false) YANG objects. One reason is that the persistency models of the underlying protocols, SNMP and NETCONF, are quite different. With SNMP, the persistency of a writable object depends either on the object definition itself (i.e., the text in the DESCRIPTION clause) or the persistency properties of the conceptual row it is part of, sometimes controlled via a columnar object using the StorageType textual convention. With NETCONF, the persistency of configuration objects is determined by the properties of the underlying datastore. Furthermore, NETCONF as defined in [RFC6241] does not provide a standard operation to modify operational state. The <edit-config> and <copy-config> operations only manipulate configuration data. As a consequence of these considerations, it is not possible to generate YANG configuration data nodes from SMIv2 definitions in an automated way.
SMIv2 MIBモジュールをYANGモジュールに変換した結果は、SMIv2オブジェクトが読み取り/書き込みまたは読み取り/作成であっても、読み取り専用（config false）YANGオブジェクトで構成されます。 1つの理由は、基礎となるプロトコルの持続性モデルであるSNMPとNETCONFがまったく異なるためです。 SNMPでは、書き込み可能なオブジェクトの永続性は、オブジェクト定義自体（つまり、DESCRIPTION句のテキスト）またはそれが含まれる概念的な行の永続性プロパティに依存し、StorageTypeテキスト表記法を使用して、列オブジェクトによって制御される場合があります。 。 NETCONFでは、構成オブジェクトの永続性は、基礎となるデータストアのプロパティによって決定されます。さらに、[RFC6241]で定義されているNETCONFは、動作状態を変更する標準の動作を提供していません。 <edit-config>および<copy-config>操作は、構成データのみを操作します。これらの考慮事項の結果として、自動化された方法でSMIv2定義からYANG構成データノードを生成することはできません。
However, for selected SMIv2 objects where the SNMP and NETCONF persistency semantics are consistent, implementations may choose to implement some YANG data nodes generated from SMIv2 definitions as configuration data nodes. Such a deviation from the generated read-only YANG module should be formally documented in the form of a separate YANG module that uses YANG deviation statements to change the config property of the data nodes implemented as configuration data nodes from false to true. Deviations that change the config false property to true without any other changes to the semantics of the data node do not affect the compliance with the YANG module generated from an SMIv2 module.
ただし、SNMPとNETCONFの永続性セマンティクスが一貫している選択されたSMIv2オブジェクトの場合、実装は、SMIv2定義から生成されたいくつかのYANGデータノードを構成データノードとして実装することを選択できます。生成された読み取り専用のYANGモジュールからのこのような逸脱は、構成データノードとして実装されているデータノードの構成プロパティをfalseからtrueに変更するために、YANG偏差ステートメントを使用する別のYANGモジュールの形式で正式に文書化する必要があります。データノードのセマンティクスに他の変更を加えずにconfig falseプロパティをtrueに変更する偏差は、SMIv2モジュールから生成されたYANGモジュールへの準拠に影響しません。
The following example demonstrates how certain columnar objects of the addressMapControlTable of the RMON2-MIB [RFC4502] can be turned into YANG configuration data nodes. Note that YANG deviations affect the property of the target node only and are not inherited downwards.
次の例は、RMON2-MIB [RFC4502]のaddressMapControlTableの特定の円柱状オブジェクトをYANG構成データノードに変換する方法を示しています。 YANGの偏差はターゲットノードのプロパティにのみ影響し、下位に継承されないことに注意してください。
module acme-RMON2-MIB-deviations {
モジュールacme-RMON2-MIB-deviations {
namespace "http://acme.example.com/RMON2-MIB-deviations";
prefix "acme-rmon2-devs";
import RMON2-MIB {
prefix "rmon2-mib";
revision-date 2006-05-02;
}
revision 2012-01-11 {
description
"First version.";
}
deviation "/rmon2-mib:RMON2-MIB" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlIndex" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlDataSource" {
deviate replace {
config true;
}
}
deviation "/rmon2-mib:RMON2-MIB/"
+ "rmon2-mib:addressMapControlTable/"
+ "rmon2-mib:addressMapControlEntry/"
+ "rmon2-mib:addressMapControlOwner" {
deviate replace {
config true;
}
}
}
A NETCONF server that implements the RMON2-MIB module with these deviations would advertise the following capabilities in its <hello> message (where whitespace has been added for readability):
これらの逸脱を含むRMON2-MIBモジュールを実装するNETCONFサーバーは、<hello>メッセージで次の機能を通知します（読みやすくするために空白が追加されています）。
<capability>
urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB?
module=RMON2-MIB&
revision=2006-05-02&
deviations=acme-RMON2-MIB-deviations
</capability>
<capability>
http://acme.example.com/RMON2-MIB-deviations?
module=acme-RMON2-MIB-deviations&
revision=2012-01-11
</capability>
This document registers two URIs in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registrations have been made.
このドキュメントは、IETF XMLレジストリ[RFC3688]に2つのURIを登録します。 RFC 3688のフォーマットに従って、次の登録が行われました。
URI: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
Registrant Contact: The NETMOD WG of the IETF.
登録者の連絡先：IETFのNETMOD WG。
XML: N/A, the requested URI is an XML namespace.
XML：N / A、要求されたURIはXML名前空間です。
URI: urn:ietf:params:xml:ns:yang:smiv2
Registrant Contact: The NETMOD WG of the IETF.
登録者の連絡先：IETFのNETMOD WG。
XML: N/A, the requested URI is an XML namespace.
XML：N / A、要求されたURIはXML名前空間です。
This document registers a YANG module in the YANG Module Names registry [RFC6020].
このドキュメントは、YANGモジュール名レジストリ[RFC6020]にYANGモジュールを登録します。
Name: ietf-yang-smiv2
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2
Prefix: smiv2
Reference: RFC 6643
This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. The translation itself has no security impact on the Internet.
このドキュメントは、SMIv2 MIBモジュールのYANGモジュールへの変換を定義し、NETCONFを介してSMIv2 MIBモジュールで定義されたデータオブジェクトへの読み取り専用（config false）アクセスを可能にします。翻訳自体はインターネットのセキュリティに影響を与えません。
Users of YANG data models generated from SMIv2 data models that have been published in the RFC series are advised to consult the security considerations of the respective RFCs. The security considerations of RFCs containing SMIv2 data models explain which objects are sensitive and important to protect. NETCONF users are encouraged to make use of the NETCONF access control model [RFC6536], which allows the specification of access control rules to protect potentially sensitive information.
RFCシリーズで公開されているSMIv2データモデルから生成されたYANGデータモデルのユーザーは、それぞれのRFCのセキュリティに関する考慮事項を参照することをお勧めします。 SMIv2データモデルを含むRFCのセキュリティに関する考慮事項は、どのオブジェクトが機密であり、保護する必要があるかを説明しています。 NETCONFユーザーは、潜在的な機密情報を保護するためのアクセス制御ルールの仕様を可能にするNETCONFアクセス制御モデル[RFC6536]を利用することをお勧めします。
The author wishes to thank the following individuals for providing helpful comments on various draft versions of this document: Andy Bierman, Benoit Claise, Martin Bjorklund, Leif Johansson, David Reid, Dan Romascanu, and David Spakes.
著者は、このドキュメントのさまざまなドラフトバージョンに役立つコメントを提供してくれた次の人物に感謝します。AndyBierman、Benoit Claise、Martin Bjorklund、Leif Johansson、David Reid、Dan Romascanu、およびDavid Spakes。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Structure of Management Information Version 2（SMIv2）"、STD 58、RFC 2578、April 1999。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、Ed。、and J. Schoenwaelder、Ed。、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、April 1999。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIv2の適合宣言」、STD 58、RFC 2580、1999年4月。
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[RFC6020] Bjorklund、M。、編、「YANG-ネットワーク構成プロトコル（NETCONF）のデータモデリング言語」、RFC 6020、2010年10月。
[RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010.
[RFC6021] Schoenwaelder、J。、「Common YANG Data Types」、RFC 6021、2010年10月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[RFC3289]ベイカー、F。、チャン、K。、およびA.スミス、「差別化サービスアーキテクチャの管理情報ベース」、RFC 3289、2002年5月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", RFC 3584, August 2003.
[RFC3584] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、RFC 3584、2003年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling M。、「The IETF XML Registry」、BCP 81、RFC 3688、2004年1月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]ハード、C、「MIBドキュメントの作成者およびレビュー担当者向けガイドライン」、BCP 111、RFC 4181、2005年9月。
[RFC4502] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2", RFC 4502, May 2006.
[RFC4502] Waldbusser、S。、「リモートネットワーク監視管理情報ベースバージョン2」、RFC 4502、2006年5月。
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、およびA. Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、2011年6月。
[RFC6536] Bierman, A., Ed. and M. Bjorklund, Ed., "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012.
[RFC6536]ビアマン、A。、エド。およびM. Bjorklund編、「Network Configuration Protocol（NETCONF）Access Control Model」、RFC 6536、2012年3月。
Appendix A. Mapping of Well-Known Types (Normative)
付録A.既知のタイプのマッピング（規範的）
This normative appendix describes the mapping of SMIv2 types to YANG types. The mapping is fully consistent with Tables 1 and 2 of [RFC6021].
この規範的な付録では、SMIv2タイプのYANGタイプへのマッピングについて説明します。マッピングは、[RFC6021]の表1および2と完全に一致しています。
SMIv2 Module: SNMPv2-SMI SMIv2 Type: INTEGER (used as an enumeration) YANG Type: enumeration
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：INTEGER（列挙として使用）YANGタイプ：列挙
SMIv2 Module: SNMPv2-SMI SMIv2 Type: INTEGER (used as a numeric type) YANG Type: int32
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：INTEGER（数値タイプとして使用）YANGタイプ：int32
SMIv2 Module: SNMPv2-SMI SMIv2 Type: Integer32 YANG Type: int32
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：Integer32 YANGタイプ：int32
SMIv2 Module: SNMPv2-SMI SMIv2 Type: OCTET STRING (used as a binary string) YANG Type: binary
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：OCTET STRING（バイナリストリングとして使用）YANGタイプ：バイナリ
SMIv2 Module: SNMPv2-SMI SMIv2 Type: OCTET STRING (used to hold UTF-8 or ASCII characters) YANG Type: string
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：OCTET STRING（UTF-8またはASCII文字を保持するために使用）YANGタイプ：文字列
SMIv2 Module: SNMPv2-SMI SMIv2 Type: OBJECT IDENTIFIER YANG Module: ietf-yang-types YANG Type: object-identifier-128
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：OBJECT IDENTIFIER YANGモジュール：ietf-yang-types YANGタイプ：object-identifier-128
SMIv2 Module: SNMPv2-SMI SMIv2 Type: BITS YANG Type: bits
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：BITS YANGタイプ：ビット
SMIv2 Module: SNMPv2-SMI SMIv2 Type: IpAddress YANG Module: ietf-inet-types YANG Type: ipv4-address
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：IpAddress YANGモジュール：ietf-inet-types YANGタイプ：ipv4-address
SMIv2 Module: SNMPv2-SMI SMIv2 Type: Counter32 YANG Module: ietf-yang-types YANG Type: counter32 SMIv2 Module: SNMPv2-SMI SMIv2 Type: Gauge32 YANG Module: ietf-yang-types YANG Type: gauge32
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：Counter32 YANGモジュール：ietf-yang-types YANGタイプ：counter32 SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：Gauge32 YANGモジュール：ietf-yang-types YANGタイプ：Gauge32
SMIv2 Module: SNMPv2-SMI SMIv2 Type: TimeTicks YANG Module: ietf-yang-types YANG Type: timeticks
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：TimeTicks YANGモジュール：ietf-yang-types YANGタイプ：timeticks
SMIv2 Module: SNMPv2-SMI SMIv2 Type: Counter64 YANG Module: ietf-yang-types YANG Type: counter64
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：Counter64 YANGモジュール：ietf-yang-types YANGタイプ：counter64
SMIv2 Module: SNMPv2-SMI SMIv2 Type: Unsigned32 YANG Type: uint32
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：Unsigned32 YANGタイプ：uint32
SMIv2 Module: SNMPv2-SMI SMIv2 Type: Opaque YANG Module: ietf-yang-smiv2 YANG Type: opaque
SMIv2モジュール：SNMPv2-SMI SMIv2タイプ：不透明YANGモジュール：ietf-yang-smiv2 YANGタイプ：不透明
SMIv2 Module: SNMPv2-TC SMIv2 Type: PhysAddress YANG Module: ietf-yang-types YANG Type: phys-address
SMIv2モジュール：SNMPv2-TC SMIv2タイプ：PhysAddress YANGモジュール：ietf-yang-types YANGタイプ：phys-address
SMIv2 Module: SNMPv2-TC SMIv2 Type: MacAddress YANG Module: ietf-yang-types YANG Type: mac-address
SMIv2モジュール：SNMPv2-TC SMIv2タイプ：MacAddress YANGモジュール：ietf-yang-types YANGタイプ：mac-address
SMIv2 Module: SNMPv2-TC SMIv2 Type: TruthValue YANG Type: boolean
SMIv2モジュール：SNMPv2-TC SMIv2タイプ：TruthValue YANGタイプ：ブール値
SMIv2 Module: SNMPv2-TC SMIv2 Type: TimeStamp YANG Module: ietf-yang-types YANG Type: timestamp
SMIv2モジュール：SNMPv2-TC SMIv2タイプ：TimeStamp YANGモジュール：ietf-yang-types YANGタイプ：タイムスタンプ
SMIv2 Module: RMON2-MIB SMIv2 Type: ZeroBasedCounter32 YANG Module: ietf-yang-types YANG Type: zero-based-counter32 SMIv2 Module: HCNUM-TC SMIv2 Type: ZeroBasedCounter64 YANG Module: ietf-yang-types YANG Type: zero-based-counter64
SMIv2モジュール：RMON2-MIB SMIv2タイプ：ZeroBasedCounter32 YANGモジュール：ietf-yang-types YANGタイプ：zero-based-counter32 SMIv2モジュール：HCNUM-TC SMIv2タイプ：ZeroBasedCounter64 YANGモジュール：ietf-yang-types YANGタイプ：ゼロベース-counter64
SMIv2 Module: HCNUM-TC SMIv2 Type: CounterBasedGauge64 YANG Module: ietf-yang-types YANG Type: gauge64
SMIv2モジュール：HCNUM-TC SMIv2タイプ：CounterBasedGauge64 YANGモジュール：ietf-yang-types YANGタイプ：Gauge64
SMIv2 Module: INET-ADDRESS-MIB SMIv2 Type: InetAutonomousSystemNumber YANG Module: ietf-inet-types YANG Type: as-number
SMIv2モジュール：INET-ADDRESS-MIB SMIv2タイプ：InetAutonomousSystemNumber YANGモジュール：ietf-inet-types YANGタイプ：as-number
SMIv2 Module: INET-ADDRESS-MIB SMIv2 Type: InetVersion YANG Module: ietf-inet-types YANG Type: ip-version
SMIv2モジュール：INET-ADDRESS-MIB SMIv2タイプ：InetVersion YANGモジュール：ietf-inet-types YANGタイプ：ip-version
SMIv2 Module: INET-ADDRESS-MIB SMIv2 Type: InetPortNumber YANG Module: ietf-inet-types YANG Type: port-number
SMIv2モジュール：INET-ADDRESS-MIB SMIv2タイプ：InetPortNumber YANGモジュール：ietf-inet-types YANGタイプ：ポート番号
SMIv2 Module: DIFFSERV-DSCP-TC SMIv2 Type: Dscp YANG Module: ietf-inet-types YANG Type: dscp
SMIv2モジュール：DIFFSERV-DSCP-TC SMIv2タイプ：Dscp YANGモジュール：ietf-inet-types YANGタイプ：dscp
SMIv2 Module: IPV6-FLOW-LABEL-MIB SMIv2 Type: IPv6FlowLabel YANG Module: ietf-inet-types YANG Type: ipv6-flow-label
SMIv2モジュール：IPV6-FLOW-LABEL-MIB SMIv2タイプ：IPv6FlowLabel YANGモジュール：ietf-inet-types YANGタイプ：ipv6-flow-label
SMIv2 Module: URI-TC-MIB SMIv2 Type: Uri YANG Module: ietf-inet-types YANG Type: uri
SMIv2モジュール：URI-TC-MIB SMIv2タイプ：Uri YANGモジュール：ietf-inet-types YANGタイプ：uri
Appendix B. Module Prefix Generation (Informative)
付録B.モジュールプレフィックスの生成（参考）
This section describes an algorithm to generate module prefixes to be used in the import statements. The input of the prefix generation algorithm is a set of prefixes (usually derived from imported module names) and a specific module name to be converted into a prefix. The algorithm described below produces a prefix for the given module name that is unique within the set of prefixes.
このセクションでは、インポートステートメントで使用されるモジュールプレフィックスを生成するアルゴリズムについて説明します。プレフィックス生成アルゴリズムの入力は、プレフィックスのセット（通常はインポートされたモジュール名から派生）と、プレフィックスに変換される特定のモジュール名です。以下で説明するアルゴリズムは、プレフィックスのセット内で一意の、指定されたモジュール名のプレフィックスを生成します。
+-----------------+--------+
| YANG Module | Prefix |
+-----------------+--------+
| ietf-yang-types | yang |
| ietf-inet-types | inet |
| ietf-yang-smiv2 | smiv2 |
+-----------------+--------+
Table 1: Special Prefixes For Well-Known YANG Modules
表1：既知のYANGモジュールの特別なプレフィックス
o First, some predefined translations mapping well-known YANG modules to short prefixes are tried (see Table 1). If a fixed translation rule exists and leads to a conflict-free prefix, then the fixed translation is used.
o 最初に、よく知られたYANGモジュールを短いプレフィックスにマッピングするいくつかの事前定義された変換が試行されます（表1を参照）。固定変換ルールが存在し、競合のないプレフィックスにつながる場合、固定変換が使用されます。
o Otherwise, prefixes are generated by tokenizing a YANG module name, using hyphens as token separators. The tokens derived from the module name are converted to lowercase characters. The prefix then becomes the shortest sequence of tokens concatenated using hyphens as separators, which includes at least two tokens and which is unique among all prefixes used in the YANG module.
o それ以外の場合は、ハイフンをトークンの区切り記号として使用して、YANGモジュール名をトークン化することにより、プレフィックスが生成されます。モジュール名から派生したトークンは小文字に変換されます。次に、接頭辞は、ハイフンをセパレーターとして使用して連結されたトークンの最短のシーケンスになります。これには、少なくとも2つのトークンが含まれ、YANGモジュールで使用されるすべての接頭辞の中で一意です。
In the worst case, the prefix derived from an SMIv2 module name becomes the SMIv2 module name translated to lowercase. But on average, much shorter prefixes are generated.
最悪の場合、SMIv2モジュール名から派生したプレフィックスは、小文字に変換されたSMIv2モジュール名になります。しかし、平均して、はるかに短いプレフィックスが生成されます。
Author's Address
著者のアドレス
Juergen Schoenwaelder Jacobs University
Juergen Schoenwaelder Jacobs University
EMail: j.schoenwaelder@jacobs-university.de