Network Working Group F. Strauss
Request for Comments: 3780 TU Braunschweig
Category: Experimental J. Schoenwaelder
International University Bremen
May 2004
SMIng - Next Generation Structure of Management Information
Status of this 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.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This memo defines the base SMIng (Structure of Management Information, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP.
このメモは基本SMIng（経営情報の構造、次世代）言語を定義します。 SMIngは、管理情報のプロトコルに依存しない表現を提供するデータ定義言語です。個別のRFCは、SNMPなどの特定の管理プロトコルにSMIngのマッピングを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The History of SMIng . . . . . . . . . . . . . . . . . . 4
1.2. Terms of Requirement Levels. . . . . . . . . . . . . . . 5
2. SMIng Data Modeling. . . . . . . . . . . . . . . . . . . . . . 5
2.1. Identifiers. . . . . . . . . . . . . . . . . . . . . . . 6
3. Base Types and Derived Types . . . . . . . . . . . . . . . . . 7
3.1. OctetString. . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Pointer. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . 9
3.4. Integer32. . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Integer64. . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 13
3.8. Float32. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9. Float64. . . . . . . . . . . . . . . . . . . . . . . . . 14
3.10. Float128 . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11. Enumeration. . . . . . . . . . . . . . . . . . . . . . . 17
3.12. Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.13. Display Formats. . . . . . . . . . . . . . . . . . . . . 18
4. The SMIng File Structure . . . . . . . . . . . . . . . . . . . 20
4.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Textual Data . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Statements and Arguments . . . . . . . . . . . . . . . . 21
5. The module Statement . . . . . . . . . . . . . . . . . . . . . 21
5.1. The module's import Statement. . . . . . . . . . . . . . 22
5.2. The module's organization Statement. . . . . . . . . . . 23
5.3. The module's contact Statement . . . . . . . . . . . . . 23
5.4. The module's description Statement . . . . . . . . . . . 23
5.5. The module's reference Statement . . . . . . . . . . . . 23
5.6. The module's revision Statement. . . . . . . . . . . . . 23
5.6.1. The revision's date Statement . . . . . . . . . . 24
5.6.2. The revision's description Statement. . . . . . . 24
5.7. Usage Example. . . . . . . . . . . . . . . . . . . . . . 24
6. The extension Statement. . . . . . . . . . . . . . . . . . . . 25
6.1. The extension's status Statement . . . . . . . . . . . . 25
6.2. The extension's description Statement. . . . . . . . . . 26
6.3. The extension's reference Statement. . . . . . . . . . . 26
6.4. The extension's abnf Statement . . . . . . . . . . . . . 26
6.5. Usage Example. . . . . . . . . . . . . . . . . . . . . . 26
7. The typedef Statement. . . . . . . . . . . . . . . . . . . . . 27
7.1. The typedef's type Statement . . . . . . . . . . . . . . 27
7.2. The typedef's default Statement. . . . . . . . . . . . . 27
7.3. The typedef's format Statement . . . . . . . . . . . . . 27
7.4. The typedef's units Statement. . . . . . . . . . . . . . 28
7.5. The typedef's status Statement . . . . . . . . . . . . . 28
7.6. The typedef's description Statement. . . . . . . . . . . 29
7.7. The typedef's reference Statement. . . . . . . . . . . . 29
7.8. Usage Examples . . . . . . . . . . . . . . . . . . . . . 29
8. The identity Statement . . . . . . . . . . . . . . . . . . . . 30
8.1. The identity's parent Statement. . . . . . . . . . . . . 30
8.2. The identity's status Statement. . . . . . . . . . . . . 30
8.3. The identity' description Statement. . . . . . . . . . . 31
8.4. The identity's reference Statement . . . . . . . . . . . 31
8.5. Usage Examples . . . . . . . . . . . . . . . . . . . . . 31
9. The class Statement. . . . . . . . . . . . . . . . . . . . . . 32
9.1. The class' extends Statement . . . . . . . . . . . . . . 32
9.2. The class' attribute Statement . . . . . . . . . . . . . 32
9.2.1. The attribute's type Statement. . . . . . . . . . 32
9.2.2. The attribute's access Statement. . . . . . . . . 32
9.2.3. The attribute's default Statement . . . . . . . . 33
9.2.4. The attribute's format Statement. . . . . . . . . 33
9.2.5. The attribute's units Statement . . . . . . . . . 33
9.2.6. The attribute's status Statement. . . . . . . . . 34
9.2.7. The attribute's description Statement . . . . . . 34
9.2.8. The attribute's reference Statement . . . . . . . 34
9.3. The class' unique Statement. . . . . . . . . . . . . . . 35
9.4. The class' event Statement . . . . . . . . . . . . . . . 35
9.4.1. The event's status Statement. . . . . . . . . . . 35
9.4.2. The event's description Statement . . . . . . . . 35
9.4.3. The event's reference Statement . . . . . . . . . 36
9.5. The class' status Statement. . . . . . . . . . . . . . . 36
9.6. The class' description Statement . . . . . . . . . . . . 36
9.7. The class' reference Statement . . . . . . . . . . . . . 37
9.8. Usage Example. . . . . . . . . . . . . . . . . . . . . . 37
10. Extending a Module . . . . . . . . . . . . . . . . . . . . . . 38
11. SMIng Language Extensibility . . . . . . . . . . . . . . . . . 39
12. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.1. Normative References . . . . . . . . . . . . . . . . . . 42
14.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. NMRG-SMING Module . . . . . . . . . . . . . . . . . . 44
Appendix B. SMIng ABNF Grammar. . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 64
In traditional management systems, management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written in conformance with a specification language, the Structure of Management Information (SMI). There are different versions of the SMI. The SMI version 1 (SMIv1) is defined in [RFC1155], [RFC1212], [RFC1215], and the SMI version 2 (SMIv2) in [RFC2578], [RFC2579], and [RFC2580]. Both are based on adapted subsets of OSI's Abstract Syntax Notation One, ASN.1 [ASN1].
従来の管理システムでは、管理情報は、仮想インフォメーションストアに存在する、管理対象オブジェクトのコレクションとして表示され、管理情報ベース（MIB）と呼ばれます。関連するオブジェクトのコレクションは、MIBモジュールで定義されています。これらのモジュールは、仕様言語、管理情報（SMI）の構造に準拠して書かれています。 SMIの異なるバージョンがあります。 SMIバージョン1（でSMIv1）[RFC2578]、[RFC2579]及び[RFC2580]の[RFC1155]、[RFC1212]、[RFC1215]、およびSMIバージョン2（SMIv2の）で定義されています。双方は、OSIの抽象構文記法1、ASN.1 [ASN1]の適合サブセットに基づいています。
In a similar fashion, policy provisioning information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Provisioning Classes are defined in PIB modules. PIB modules are written using the Structure of Policy Provisioning Information (SPPI) [RFC3159] which is an adapted subset of SMIv2.
同様に、ポリシープロビジョニング情報は、仮想インフォメーションストアに存在するプロビジョニングクラス（のPRCs）とプロビジョニングのインスタンス（のPRI）の集合体として見て、ポリシー情報ベース（PIB）と呼ばれます。関連プロビジョニングクラスのコレクションは、PIBモジュールで定義されています。 PIBモジュールはSMIv2のに適合したサブセットであるポリシーのプロビジョニング情報（SPPI）[RFC3159]の構造を使用して書かれています。
The SMIv1 and the SMIv2 are bound to the Simple Network Management Protocol (SNMP) [RFC3411], while the SPPI is bound to the Common Open Policy Service Provisioning (COPS-PR) Protocol [RFC3084]. Even though the languages have common rules, it is hard to use common data definitions with both protocols. It is the purpose of this document to define a common data definition language, named SMIng, that can formally specify data models independent of specific protocols and applications. The appendix of this document defines a core module that supplies common SMIng definitions.
SPPIは、一般的なオープンポリシーサービスのプロビジョニング（COPS-PR）プロトコル[RFC3084]にバインドされている間でSMIv1とSMIv2のは、簡易ネットワーク管理プロトコル（SNMP）[RFC3411]にバインドされています。言語は共通のルールを持っているにもかかわらず、両方のプロトコルで共通のデータ定義を使用することは困難です。正式に特定のプロトコルやアプリケーションの独立したデータモデルを指定することができますSMIngという名前の共通のデータ定義言語を、定義するには、このドキュメントの目的です。このドキュメントの付録では、一般的なSMIngの定義を提供するコアモジュールを定義します。
A companion document contains an SMIng language extension to define SNMP specific mappings of SMIng definitions in compatibility with SMIv2 MIB modules [RFC3781]. Additional language extensions may be added in the future, e.g., to define COPS-PR specific mappings of SMIng definitions in a way that is compatible with SPPI PIBs.
仲間ドキュメントはSMIv2のMIBモジュール[RFC3781]との相溶性にSMIng定義のSNMP固有のマッピングを定義するためにSMIng言語の拡張機能が含まれています。追加の言語拡張はSPPIのPIBと互換性のある方法でSMIng定義のCOPS-PR固有のマッピングを定義するために、例えば、将来的に追加することができます。
Section 2 gives an overview of the basic concepts of data modeling using SMIng, while the subsequent sections present the concepts of the SMIng language in detail: the base types, the SMIng file structure, and all SMIng core statements.
基本型、SMIngファイル構造、およびすべてのSMIngコア文：後続のセクションでは、詳細にSMIng言語の概念を提示しながら、第2節では、SMIngを使用して、データ・モデリングの基本的な概念の概要を与えます。
The remainder of the document describes extensibility features of the language and rules to follow when changes are applied to a module. Appendix B contains the grammar of SMIng in ABNF [RFC2234] notation.
文書の残りの部分は変更がモジュールに適用される際に従うために拡張言語の機能および規則を説明しています。付録Bは、ABNF [RFC2234]表記SMIngの文法を含んでいます。
SMIng started in 1999 as a research project to address some drawbacks of SMIv2, the current data modeling language for management information bases. Primarily, its partial dependence on ASN.1 and a number of exception rules turned out to be problematic. In 2000, the work was handed over to the IRTF Network Management Research Group where it was significantly detailed. Since the work of the RAP Working Group on COPS-PR and SPPI emerged in 1999/2000, SMIng was split into two parts: a core data definition language (defined in this document) and protocol mappings to allow the application of core definitions through (potentially) multiple management protocols. The replacement of SMIv2 and SPPI by a single merged data definition language was also a primary goal of the IETF SMING Working Group that was chartered at the end of 2000.
SMIngはSMIv2の、管理情報ベースの現在のデータモデリング言語のいくつかの欠点に対処するための研究プロジェクトとして1999年に開始しました。主に、ASN.1および例外ルールの数にその部分依存性が問題となることが判明しました。 2000年には、仕事は、それがかなり詳細に説明されたIRTFネットワーク管理研究グループに引き渡されました。 （経由コアの定義の適用を可能にするために（この文書で定義された）コアデータ定義言語とプロトコルのマッピング：COPS-PRとSPPIのRAPワーキンググループの仕事は1999/2000に出現するので、SMIngは、2つの部分に分割されました潜在的に）複数の管理プロトコル。単一マージされたデータ定義言語によってのSMIv2とSPPIの交換も、2000年の終わりにチャーターされたIETF SMING作業部会の主な目的でした。
The requirements for a new data definition language were discussed several times within the IETF SMING Working Group and changed significantly over time [RFC3216], so that another proposal (in addition to SMIng), named SMI Data Structures (SMI-DS), was presented to the Working Group. In the end, neither of the two proposals found enough consensus and support, and the attempt to merge the existing concepts did not succeed, resulting in the Working Group being closed down in April 2003.
SMIデータ構造（SMI-DS）の名前（SMIngに加えて）別の提案は、発表されたように、新しいデータ定義言語のための要件は、IETF SMINGワーキンググループの中に数回議論して時間[RFC3216]で大幅に変更されましたワーキンググループへ。最後に、2つの案のいずれも十分なコンセンサスとサポート、および2003年4月に閉鎖されたワーキンググループで、その結果、成功しなかった既存の概念をマージしようとする試みを発見しました。
In order to record the work of the NMRG (Network Management Research Group) on SMIng, this memo and the accompanying memo on the SNMP protocol mapping [RFC3781] have been published for informational purposes.
SMIng上NMRG（ネットワーク管理研究グループ）の作業を記録するために、このメモとSNMPプロトコルマッピング[RFC3781]の添付文書は情報提供の目的のために公開されています。
Note that throughout these documents, the term "SMIng" refers to the specific data modeling language that is specified in this document, whereas the term "SMING" refers to the general effort within the IETF Working Group to define a new management data definition language as an SMIv2 successor and probably an SPPI merger, for which "SMIng" and "SMI-DS" were two specific proposals.
用語「SMINGは」として、新たな管理データ定義言語を定義するためのIETFワーキンググループ内の一般的な努力を指し、一方、これらの文書を通じて、用語「SMIng」は、この文書で指定された特定のデータモデリング言語を示すことに注意してくださいSMIv2の後継とおそらくSPPIの合併のための「SMIng」と「SMI-DS」は、2つの具体的な提案でした。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
SMIng is a language designed to specify management information in a structured way readable to computer programs, e.g., MIB compilers, as well as to human readers.
SMIngは、コンピュータプログラム、例えば、MIBコンパイラに、並びにヒトの読者に読みやすい構造化された方法で管理情報を指定するために設計された言語です。
Management information is modeled in classes. Classes can be defined from scratch or by derivation from a parent class. Derivation from multiple parent classes is not possible. The concept of classes is described in Section 9.
管理情報は、クラスでモデル化されます。クラスは最初からまたは親クラスから派生によって定義することができます。複数の親クラスから派生することはできません。クラスの概念は、第9章で説明されています。
Each class has a number of attributes. Each attribute represents an atomic piece of information of a base type, a sub-type of a base type, or another class. The concept of attributes is described in Section 9.2.
各クラスは、属性の数を持っています。各属性は、基本型、基本型のサブタイプ、または別のクラスの情報の原子部分を表します。属性の概念は、セクション9.2に記載されています。
The base types of SMIng include signed and unsigned integers, octet strings, enumeration types, bitset types, and pointers. Pointers are references to class instances, attributes of class instances, or arbitrary identities. The SMIng type system is described in Section 3.
SMIngの基本型は、符号付きと符号なし整数、オクテット文字列、列挙型、ビットセットの種類、およびポインタを含みます。ポインタは、クラスのインスタンス、クラスインスタンスの属性、または任意のアイデンティティへの参照です。 SMIng型システムはセクション3に記載されています。
Related class and type definitions are defined in modules. A module may refer to definitions from other modules by importing identifiers from those modules. Each module may serve one or multiple purposes:
関連クラスと型定義はモジュールで定義されています。モジュールは、これらのモジュールの識別子をインポートすることによって、他のモジュールからの定義を参照することができます。各モジュールは、1つのまたは複数の目的を果たすことがあります。
o the definition of management classes,
O管理クラスの定義は、
o the definition of events,
イベントの定義は、O、
o the definition of derived types,
O派生型の定義は、
o the definition of arbitrary untyped identities serving as values of pointers,
Oポインタの値として、任意の型指定のないアイデンティティの定義は、
o the definition of SMIng extensions allowing the local module or other modules to specify information beyond the scope of the base SMIng in a machine readable notation. Some extensions for the application of SMIng in the SNMP framework are defined in [RFC3781],
ローカルモジュールまたは他のモジュールは、機械可読表記における基地SMIngの範囲を超えて情報を指定することを可能にするSMIng拡張の定義O。 SNMPフレームワーク内SMIngのアプリケーションのためのいくつかの拡張機能は、[RFC3781]で定義されています
o the definition of information beyond the scope of the base SMIng statements, based on locally defined or imported SMIng extensions.
ローカルに定義されたまたはインポートSMIng拡張子に基づいて、基地SMIng文の範囲を超えて情報の定義、O。
Each module is identified by an upper-case identifier. The names of all standard modules must be unique (but different versions of the same module should have the same name). Developers of enterprise modules are encouraged to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g., by using the enterprise or organization name as a prefix.
各モジュールは、大文字の識別子によって識別されます。すべての標準モジュールの名前は一意である必要があります（ただし、同じモジュールの異なるバージョンが同じ名前を持つ必要があります）。企業・モジュールの開発者は、接頭辞として、企業や組織名を使用することにより、例えば、標準または他のエンタープライズ・モジュールと衝突する確率が低いだろう彼らのモジュールの名前を選択することをお勧めします。
Identifiers are used to identify different kinds of SMIng items by name. Each identifier is valid in a namespace which depends on the type of the SMIng item being defined:
識別子は名前によってSMIngアイテムの種類を識別するために使用されています。各識別子は定義されているSMIngアイテムの種類によって異なり、ネームスペースで有効です。
o The global namespace contains all module identifiers.
oをグローバル名前空間は、すべてのモジュール識別子が含まれています。
o Each module defines a new namespace. A module's namespace may contain definitions of extension identifiers, derived type identifiers, identity identifiers, and class identifiers. Furthermore, a module may import identifiers of these kinds from other modules. All these identifiers are also visible within all inner namespaces of the module.
O各モジュールは、新しい名前空間を定義します。モジュールの名前空間は、拡張識別子、派生型識別子、アイデンティティ識別子、およびクラス識別子の定義が含まれていてもよいです。さらに、モジュールは他のモジュールからのこれらの種類の識別子をインポートすることができます。すべてのこれらの識別子は、モジュールのすべての内部のネームスペース内に表示されています。
o Each class within a module defines a new namespace. A class' namespace may contain definitions of attribute identifiers and event identifiers.
Oモジュール内の各クラスには、新しい名前空間を定義します。クラスの名前空間は属性識別子とイベント識別子の定義が含まれていてもよいです。
o Each enumeration type and bitset type defines a new namespace of its named numbers. These named numbers are visible in each expression of a corresponding value, e.g., default values and sub-typing restrictions.
O各列挙型とビットセットタイプは、その名前の数字の新しい名前空間を定義します。これらの名前付き数字は、対応する値、例えば、デフォルト値およびサブタイピング制限の各式で表示されています。
o Extensions may define additional namespaces and have additional rules of other namespaces' visibility.
Oの拡張機能は、追加の名前空間を定義し、他の名前空間可視性の追加の規則を有することができます。
Within every namespace each identifier MUST be unique.
すべてのネームスペース内の各識別子は一意である必要があります。
Each identifier starts with an upper-case or lower-case character, dependent on the kind of SMIng item, followed by zero or more letters, digits, and hyphens.
各識別子は、ゼロ以上の文字、数字、およびハイフンに続くSMIngアイテムの種類に応じて大文字または小文字の文字で始まります。
All identifiers defined in a namespace MUST be unique and SHOULD NOT only differ in case. Identifiers MUST NOT exceed 64 characters in length. Furthermore, the set of all identifiers defined in all modules of a single standardization body or organization SHOULD be unique and mnemonic. This promotes a common language for humans to use when discussing a module.
名前空間で定義されたすべての識別子が一意である必要があり、大文字と小文字の区別だけが異なるべきではありません。識別子の長さは64文字を超えてはなりません。さらに、単一の標準化団体または組織のすべてのモジュールで定義されているすべての識別子の組は、ユニークでニーモニックであるべきです。これは、モジュールを議論する際に人間が使用するための共通言語を推進しています。
To reference an item that is defined in the local module, its definition MUST sequentially precede the reference. Thus, there MUST NOT be any forward references.
ローカルモジュールで定義されている項目を参照するために、その定義は順次参照に先行しなければなりません。このように、任意の前方参照があってはなりません。
To reference an item that is defined in an external module it MUST be imported (Section 5.1). Identifiers that are neither defined nor imported MUST NOT be visible in the local module.
外部モジュールで定義されている項目を参照するためには（セクション5.1）をインポートする必要があります。どちらも定義されていないにも輸入されている識別子は、ローカルモジュールに表示されてはなりません。
When identifiers from external modules are referenced, there is the possibility of name collisions. As such, if different items with the same identifier are imported or if imported identifiers collide with identifiers of locally defined items, then this ambiguity is resolved by prefixing those identifiers with the names of their modules and the namespace operator `::', i.e., `Module::item'. Of course, this notation can be used to refer to identifiers even when there is no name collision.
外部モジュールからの識別子が参照されている場合は、名前の衝突の可能性があります。同じ識別子を持つ異なるアイテムをインポートしたりしている場合は、インポートの識別子がローカルに定義された項目の識別子と衝突した場合などのように、この曖昧さは、すなわち、そのモジュールの名前と名前空間演算子 `::」でこれらの識別子を付けることによって解決され、 `モジュール::アイテム」。もちろん、この記法は名前の衝突がない場合でも、識別子を参照するために使用することができます。
Note that SMIng core language keywords MUST NOT be imported. See the `...Keyword' rules of the SMIng ABNF grammar in Appendix B for a list of those keywords.
SMIngコア言語のキーワードがインポートされてはならないことに注意してください。これらのキーワードのリストについては、付録BでSMIng ABNF文法の `...キーワード」のルールを参照してください。
SMIng has a set of base types, similar to those of many programming languages, but with some differences due to special requirements from the management information model.
SMIngは、多くのプログラミング言語と同様の基本タイプのセットを、持っていますが、管理情報モデルから特別な要求のためにいくつかの違いで。
Additional types may be defined, derived from those base types or from other derived types. Derived types may use subtyping to formally restrict the set of possible values. An initial set of commonly used derived types is defined in the SMIng standard module NMRG-SMING [RFC3781].
付加的なタイプは、定義されたベース型からまたは他の派生型に由来してもよいです。派生型は、正式に可能な値のセットを制限するためにサブタイプを使用することができます。一般的に使用される派生型の初期セットはSMIng標準モジュールNMRG-SMING [RFC3781]で定義されています。
The different base types and their derived types allow different kinds of subtyping, namely size restrictions of octet strings (Section 3.1), range restrictions of numeric types (Section 3.4
異なる塩基の種類とその派生型は、サブタイプの異なる種類の、オクテットストリング（セクション3.1）の、すなわちサイズ制限、数値型の範囲の制限（3.4節を許可します
through Section 3.10), restricted pointer types (Section 3.2), and restrictions on the sets of named numbers for enumeration types (Section 3.11) and bit sets (Section 3.12).
3.10節を介して）、制限されたポインタ型（3.2節）、および列挙型の名前付きの数字のセットに制限（3.11節）とビットセット（3.12節）。
The OctetString base type represents arbitrary binary or textual data. Although SMIng has a theoretical size limitation of 2^16-1 (65535) octets for this base type, module designers should realize that there may be implementation and interoperability limitations for sizes in excess of 255 octets.
OctetStringにベース型は任意のバイナリまたはテキストデータを表します。 SMIngは、この基本タイプの2 ^ 16-1（65535）オクテットの理論上のサイズ制限を有するが、モジュールの設計者は、255個のオクテットを超えるサイズの実装との相互運用性に関する制限が存在し得ることを理解すべきです。
Values of octet strings may be denoted as textual data enclosed in double quotes or as arbitrary binary data denoted as a `0x'-prefixed hexadecimal value of an even number of at least two hexadecimal digits, where each pair of hexadecimal digits represents a single octet. Letters in hexadecimal values MAY be upper-case, but lower-case characters are RECOMMENDED. Textual data may contain any number (possibly zero) of any 7-bit displayable ASCII characters, including tab characters, spaces, and line terminator characters (nl or cr & nl). Some characters require a special encoding (see Section 4.2). Textual data may span multiple lines, where each subsequent line prefix containing only white space up to the column where the first line's data starts SHOULD be skipped by parsers for a better text formatting.
オクテットストリングの値は、テキストを二重引用符で囲まれたデータ、または16進数の各対は、単一のオクテットを表す少なくとも2桁の16進数の偶数の `0x'-接頭進値として示すように任意のバイナリデータとして表されてもよいです。 16進数の文字は大文字であってもよく、しかし小文字が推奨されます。テキストデータは、タブ文字、スペース、および（NLまたはCR＆NL）回線終端文字を含む任意の7ビット表示可能なASCII文字、任意の数の（おそらくゼロ）を含んでいてもよいです。一部の文字は特別なエンコーディング（4.2節を参照）が必要です。テキストデータは、第1ラインのデータが始まるより良いテキストの書式設定のためにパーサーによってスキップするカラムまで空白のみを含む各後続行プレフィックス複数行にまたがることができます。
When defining a type derived (directly or indirectly) from the OctetString base type, the size in octets may be restricted by appending a list of size ranges or explicit size values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A size range consists of a lower bound, two consecutive dots `..', and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number of at least two digits. Size restricting values MUST NOT be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a size restriction is applied to an already size restricted octet string, the new restriction MUST be equal or more limiting, that is, raising the lower bounds, reducing the upper bounds, removing explicit size values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
「| OctetStringにベースタイプから（直接または間接的に）派生型を定義する場合、オクテットサイズは `パイプによって分離、サイズ範囲、または明示的なサイズ値のリストを追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。サイズ範囲は '..下限、二つの連続したドット'から構成され、上限。各値は、10進数または `0x'-接頭16進表記で指定することができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。サイズ制限値は負であってはなりません。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。サイズ制限は既にサイズ制限オクテットストリングに適用した場合、新たな制限は、明示的なサイズ値または範囲を、下限を上げる上限を減少、除去、つまり、制限同等以上であるか、または分割が複数の範囲に及びます中間ギャップが。
Value Examples:
値の例：
"This is a multiline textual data example." // legal "This is "illegally" quoted." // illegal quotes "This is \"legally\" quoted." // legally encoded quotes "But this is 'ok', as well." // legal apostrophe quoting "" // legal zero length 0x123 // illegal odd hex length 0x534d496e670a // legal octet string
「これは、複数行のテキストデータの例です。」 //法的違法「これは 『』引用しました。」 //不正な引用符は、合法的に「これは\される」\「引用されました。」 //合法的にエンコードされた引用符「しかし、これは同様に、 『OK』です。」 「」//法的ゼロの長さ0x123 //違法奇数の六角長0x534d496e670a //法的オクテット文字列を引用//法的アポストロフィ
Restriction Examples:
制限の例：
OctetString (0 | 4..255) // legal size spec OctetString (4) // legal exact size OctetString (-1 | 1) // illegal negative size OctetString (5 | 0) // illegal ordering OctetString (1 | 1..10) // illegal overlapping
OctetStringに（0 | 4..255）//リーガルサイズスペックOctetStringに（4）//法的正確なサイズのOctetString（-1 | 1）//不正な負のサイズのOctetString（5 | 0）//不正な順序OctetStringに（1 | 1 ..10）//不正な重複
The Pointer base type represents values that reference class instances, attributes of class instances, or arbitrary identities. The only values of the Pointer type that can be present in a module can refer to identities. They are denoted as identifiers of the concerned identities.
ポインタの基本型は、クラスのインスタンス、クラスのインスタンスの属性、または任意のアイデンティティを参照する値を表します。モジュール内に存在することができるポインタ型の値のみがアイデンティティを参照することができます。彼らは心配アイデンティティの識別子と表記されています。
When defining a type derived (directly or indirectly) from the Pointer base type, the values may be restricted to a specific class, attribute or identity, and all (directly or indirectly) derived items thereof by appending the identifier of the appropriate construct enclosed in parenthesis.
ポインタの基本型から（直接または間接的に）派生型を定義する場合、値は特定のクラス、属性又は識別に制限され、すべての（直接的または間接的に）で囲まれた適切な構築物の識別子を付加することによって、そのアイテムを誘導することができます括弧。
Value Examples:
値の例：
null // legal identity name snmpUDPDomain // legal identity name
ヌル//法的アイデンティティ名snmpUDPDomain //法的アイデンティティ名
Restriction Examples:
制限の例：
Pointer (snmpTransportDomain) // legal restriction
ポインタ（snmpTransportDomain）//法的規制
The ObjectIdentifier base type represents administratively assigned names for use with SNMP and COPS-PR. This type SHOULD NOT be used in protocol independent SMIng modules. It is meant to be used in SNMP and COPS-PR mappings of attributes of type Pointer (Section 3.2).
ObjectIdentifierの基本型は、SNMPとCOPS-PRで使用するための管理上割り当てられた名前を表します。このタイプは、プロトコルに依存しないSMIngモジュールでは使用しないでください。ポインタ型（3.2節）の属性のSNMPとCOPS-PRのマッピングに使用されることを意味しています。
Values of this type may be denoted as a sequence of numerical non-negative sub-identifier values in which each MUST NOT exceed 2^32-1 (4294967295). Sub-identifiers may be denoted in decimal or `0x'- prefixed hexadecimal. They are separated by single dots and without any intermediate white space. Alternatively (and preferred in most cases), the first element may be a previously defined or imported lower-case identifier, representing a static object identifier prefix.
このタイプの値は、それぞれが2 ^ 32-1（4294967295）を超えてはならないれた数値非負サブ識別子の値のシーケンスとして表すことができます。副識別子は、10進数または `0x'-接頭進数で表すことができます。彼らは、単一のドットでかつ任意の中間ホワイトスペースなしで分離されています。代替的に（多くの場合に好ましい）、最初の要素は、静的オブジェクト識別子のプレフィックスを表す、以前に定義またはインポート小文字の識別子であってもよいです。
Although the number of sub-identifiers in SMIng object identifiers is not limited, module designers should realize that there may be implementations that stick with the SMIv1/v2 limit of 128 sub-identifiers.
SMIngオブジェクト識別子でサブ識別子の数は限定されないが、モジュールの設計者は、128のサブ識別子でSMIv1 / v2の制限に固執の実装が存在し得ることを理解すべきです。
Object identifier derived types cannot be restricted in any way.
オブジェクト識別子派生型は、任意の方法で制限することはできません。
Value Examples:
値の例：
1.3.6.1 // legal numerical oid mib-2.1 // legal oid with identifier prefix internet.4.1.0x0627.0x01 // legal oid with hex subids iso.-1 // illegal negative subid iso.org.6 // illegal non-heading identifier IF-MIB::ifNumber.0 // legal fully qualified instance oid
iso.-1 1.3.6.1 //法的数値OIDのMIB-2.1 //六角subidsと識別子プレフィックスinternet.4.1.0x0627.0x01 //法的OIDに法的OID //不正負サブIDのiso.org.6 //不正非-heading識別子は、IF-MIB :: ifNumber.0 //法的完全修飾インスタンスのOID
The Integer32 base type represents integer values between -2^31 (-2147483648) and 2^31-1 (2147483647).
Integer32の基本タイプ（-2147483648）31 ^ -2から2 ^ 31-1（2147483647）の整数値を表します。
Values of type Integer32 may be denoted as decimal or hexadecimal numbers, where only decimal numbers can be negative. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of at least two hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
タイプInteger32のの値は10進数のみが負であることができる、10進数または16進数として表すことができます。ゼロ以外の小数はゼロの数字をリードしていてはなりません。 16進数は `0X」で始まるされ、文字が大文字である、少なくとも2桁の16進数の偶数番号を持つ必要がありますが、小文字が推奨されます。
When defining a type derived (directly or indirectly) from the Integer32 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, and the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number of at least two digits. If multiple values or ranges are given they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
「| Integer32の基本タイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます文字、括弧で囲まれたリスト全体。範囲は、「..下限、二つの連続したドット 'から構成され、上限。各値は、10進数または `0x'-接頭16進表記で指定することができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。複数の値または範囲が指定されている場合、それらすべてが互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。
Value Examples:
値の例：
015 // illegal leading zero -123 // legal negative value - 1 // illegal intermediate space 0xabc // illegal hexadecimal value length -0xff // illegal sign on hex value 0x80000000 // illegal value, too large 0xf00f // legal hexadecimal value
015 //不正先行ゼロ-123 //法的負の値 - 1つの//違法中間空間0xabc //不正進値長-0xff //進値は0x80000000に違法符号//不正な値、大きすぎる0xf00f //法的16進値
Restriction Examples:
制限の例：
Integer32 (0 | 5..10) // legal range spec Integer32 (5..10 | 2..3) // illegal ordering Integer32 (4..8 | 5..10) // illegal overlapping
構文Integer32（0 | 5..10）//有効範囲の仕様構文Integer32（5..10 | 2..3）//違法発注構文Integer32（4..8 | 5..10）//不正な重複
The Integer64 base type represents integer values between -2^63 (-9223372036854775808) and 2^63-1 (9223372036854775807).
Integer64ベースタイプ（-9223372036854775808）63 ^ -2から2 ^ 63-1（9223372036854775807）の整数値を表します。
Values of type Integer64 may be denoted as decimal or hexadecimal numbers, where only decimal numbers can be negative. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
タイプInteger64の値は10進数のみが負であることができる、10進数または16進数として表すことができます。ゼロ以外の小数はゼロの数字をリードしていてはなりません。 16進数は `0X」で始まるされ、文字が大文字であってもよく、しかし小文字が推奨される16進数の偶数を持たなければなりません。
When defining a type derived (directly or indirectly) from the Integer64 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number of at least two digits. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
「| Integer64ベースタイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。範囲は、「..下限、二つの連続したドット 'から構成され、上限。各値は、10進数または `0x'-接頭16進表記で指定することができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。
Value Examples:
値の例：
015 // illegal leading zero -123 // legal negative value - 1 // illegal intermediate space 0xabc // illegal hexadecimal value length -0xff // illegal sign on hex value 0x80000000 // legal value
015 //不正先行ゼロ-123 //法的負の値 - 1つの//違法中間空間0xabc //不正進値長-0xff //進値は0x80000000に違法符号//有効な値
Restriction Examples:
制限の例：
Integer64 (0 | 5..10) // legal range spec Integer64 (5..10 | 2..3) // illegal ordering Integer64 (4..8 | 5..10) // illegal overlapping
Integer64（0 | 5..10）//有効範囲仕様Integer64（5..10 | 2..3）//不正な順序Integer64（4..8 | 5..10）//不正な重複
The Unsigned32 base type represents positive integer values between 0 and 2^32-1 (4294967295).
Unsigned32の基本タイプは、0から2 ^ 32-1（4294967295）との間の正の整数値を表します。
Values of type Unsigned32 may be denoted as decimal or hexadecimal numbers. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
タイプUnsigned32の値は、10進数または16進数として表すことができます。ゼロ以外の小数はゼロの数字をリードしていてはなりません。 16進数は `0X」で始まるされ、文字が大文字であってもよく、しかし小文字が推奨される16進数の偶数を持たなければなりません。
When defining a type derived (directly or indirectly) from the Unsigned32 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number of at least two digits. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
「| Unsigned32の基本タイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。範囲は、「..下限、二つの連続したドット 'から構成され、上限。各値は、10進数または `0x'-接頭16進表記で指定することができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。
Value Examples:
値の例：
015 // illegal leading zero -123 // illegal negative value 0xabc // illegal hexadecimal value length 0x80000000 // legal hexadecimal value 0x8080000000 // illegal value, too large
015 //不正先行ゼロ-123 //不正負値0xabc //不正16進値の長さは0x80000000 //法的進値0x8080000000 //不正値、大きすぎます
Restriction Examples:
制限の例：
Unsigned32 (0 | 5..10) // legal range spec Unsigned32 (5..10 | 2..3) // illegal ordering Unsigned32 (4..8 | 5..10) // illegal overlapping
Unsigned32の（0 | 5..10）//有効範囲仕様のUnsigned32（5..10 | 2..3）//不正な順序のUnsigned32（4..8 | 5..10）//不正な重複
The Unsigned64 base type represents positive integer values between 0 and 2^64-1 (18446744073709551615).
Unsigned64にベース型は0から2 ^ 64-1（18446744073709551615）との間の正の整数値を表します。
Values of type Unsigned64 may be denoted as decimal or hexadecimal numbers. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
タイプUnsigned64にの値は、10進数または16進数として表すことができます。ゼロ以外の小数はゼロの数字をリードしていてはなりません。 16進数は `0X」で始まるされ、文字が大文字であってもよく、しかし小文字が推奨される16進数の偶数を持たなければなりません。
When defining a type derived (directly or indirectly) from the Unsigned64 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number of at least two digits. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
「| Unsigned64にベースタイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。範囲は、「..下限、二つの連続したドット 'から構成され、上限。各値は、10進数または `0x'-接頭16進表記で指定することができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。
Value Examples:
値の例：
015 // illegal leading zero -123 // illegal negative value 0xabc // illegal hexadecimal value length 0x8080000000 // legal hexadecimal value
015 //不正先行ゼロ-123 //不正負値0xabc //不正16進値長0x8080000000 //法的16進値
Restriction Examples:
制限の例：
Unsigned64 (1..10000000000) // legal range spec Unsigned64 (5..10 | 2..3) // illegal ordering
Unsigned64に（1..10000000000）//有効範囲仕様Unsigned64に（5..10 | 2..3）//不正な順序
The Float32 base type represents floating point values of single precision as described by [IEEE754].
[IEEE754]によって記載されたようFLOAT32ベース型は単精度の浮動小数点値を表します。
Values of type Float32 may be denoted as a decimal fraction with an optional exponent, as known from many programming languages. See the grammar rule `floatValue' of Appendix B for the detailed syntax. Special values are `snan' (signalling Not-a-Number), `qnan' (quiet Not-a-Number), `neginf' (negative infinity), and `posinf' (positive infinity). Note that -0.0 and +0.0 are different floating point values. 0.0 is equal to +0.0.
多くのプログラミング言語から知られているようなタイプのfloat32の値は、オプションの指数と小数として示されてもよいです。詳細な構文については、付録Bの文法規則に従ってFloatValue `」を参照してください。特別な値は、（静かな非数）、 `neginf「（負の無限大）、および` posinf」（正の無限大）「`のQNaN、（非数をシグナリング）」` SNaNのです。 -0.0と+0.0は異なる浮動小数点値であることに留意されたいです。 0.0 +0.0に等しいです。
When defining a type derived (directly or indirectly) from the Float32 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. The special values `snan', `qnan', `neginf', and `posinf' must be explicitly listed in restrictions if they shall be included, where `snan' and `qnan' cannot be used in ranges.
「|のfloat32ベースタイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。範囲は、「..下限、二つの連続したドット 'から構成され、上限。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。 `SNaNの「と` qNaNを」範囲で使用することができない場合、彼らは、含まれなければならない場合には、特別な値 `SNaNの「`のQNaN」、 `neginf「そして` posinfは、」明示的な制限にリストされている必要があります。
Note that encoding is not subject to this specification. It has to be described by protocols that transport objects of type Float32. Note also that most floating point encodings disallow the representation of many values that can be written as decimal fractions as used in SMIng for human readability. Therefore, explicit values in floating point type restrictions should be handled with care.
符号化は、本明細書の対象ではないことに留意されたいです。これは、プロトコルタイプのfloat32のトランスポート・オブジェクトによって記述する必要があります。ほとんどの浮動小数点符号化は、人間の可読性のためにSMIngで使用される小数点以下のように書くことができる多くの値の表示を許可しないことにも留意されたいです。そのため、浮動小数点型の制限で明示的な値は注意して取り扱ってください。
Value Examples:
値の例：
00.1 // illegal leading zero 3.1415 // legal value -2.5E+3 // legal negative exponential value
00.1 //不正先行ゼロ3.1415 //法定値-2.5E + 3 //法的負の指数値
Restriction Examples:
制限の例：
Float32 (-1.0..1.0) // legal range spec Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 Float32 (neginf..-0.0) // legal range spec Float32 (-10.0..10.0 | 0) // illegal overlapping
float32（-1.0..1.0）//有効範囲仕様のfloat32（1 | 3.3 | 5）//法的、おそらく表現できない3.3のfloat32（neginf ..- 0.0）//有効範囲仕様のfloat32（-10.0..10.0 | 0 ）//不正な重複
The Float64 base type represents floating point values of double precision as described by [IEEE754].
[IEEE754]により記載されたようにのfloat64ベースタイプは倍精度の浮動小数点値を表します。
Values of type Float64 may be denoted as a decimal fraction with an optional exponent, as known from many programming languages. See the grammar rule `floatValue' of Appendix B for the detailed syntax. Special values are `snan' (signalling Not-a-Number), `qnan' (quiet Not-a-Number), `neginf' (negative infinity), and `posinf' (positive infinity). Note that -0.0 and +0.0 are different floating point values. 0.0 is equal to +0.0.
多くのプログラミング言語から知られているようなタイプのfloat64の値は、オプションの指数と小数として示されてもよいです。詳細な構文については、付録Bの文法規則に従ってFloatValue `」を参照してください。特別な値は、（静かな非数）、 `neginf「（負の無限大）、および` posinf」（正の無限大）「`のQNaN、（非数をシグナリング）」` SNaNのです。 -0.0と+0.0は異なる浮動小数点値であることに留意されたいです。 0.0 +0.0に等しいです。
When defining a type derived (directly or indirectly) from the Float64 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. The special values `snan', `qnan', `neginf', and `posinf' must be explicitly listed in restrictions if they shall be included, where `snan' and `qnan' cannot be used in ranges.
「|のfloat64ベースタイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。範囲は、「..下限、二つの連続したドット 'から構成され、上限。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。 `SNaNの「と` qNaNを」範囲で使用することができない場合、彼らは、含まれなければならない場合には、特別な値 `SNaNの「`のQNaN」、 `neginf「そして` posinfは、」明示的な制限にリストされている必要があります。
Note that encoding is not subject to this specification. It has to be described by protocols that transport objects of type Float64. Note also that most floating point encodings disallow the representation of many values that can be written as decimal fractions as used in SMIng for human readability. Therefore, explicit values in floating point type restrictions should be handled with care.
符号化は、本明細書の対象ではないことに留意されたいです。これは、タイプのfloat64のトランスポート・オブジェクトというプロトコルで記述する必要があります。ほとんどの浮動小数点符号化は、人間の可読性のためにSMIngで使用される小数点以下のように書くことができる多くの値の表示を許可しないことにも留意されたいです。そのため、浮動小数点型の制限で明示的な値は注意して取り扱ってください。
Value Examples:
値の例：
00.1 // illegal leading zero 3.1415 // legal value -2.5E+3 // legal negative exponential value
00.1 //不正先行ゼロ3.1415 //法定値-2.5E + 3 //法的負の指数値
Restriction Examples:
制限の例：
Float64 (-1.0..1.0) // legal range spec Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 Float64 (neginf..-0.0) // legal range spec Float64 (-10.0..10.0 | 0) // illegal overlapping
float64（-1.0..1.0）//有効範囲仕様のfloat64（1 | 3.3 | 5）//法的、おそらく表現できない3.3のfloat64（neginf ..- 0.0）//有効範囲仕様のfloat64（-10.0..10.0 | 0 ）//不正な重複
The Float128 base type represents floating point values of quadruple precision as described by [IEEE754].
[IEEE754]によって記載されたようFloat128ベース型は四重精度の浮動小数点値を表します。
Values of type Float128 may be denoted as a decimal fraction with an optional exponent, as known from many programming languages. See the grammar rule `floatValue' of Appendix B for the detailed syntax. Special values are `snan' (signalling Not-a-Number), `qnan' (quiet Not-a-Number), `neginf' (negative infinity), and `posinf' (positive infinity). Note that -0.0 and +0.0 are different floating point values. 0.0 is equal to +0.0.
多くのプログラミング言語から知られているようなタイプFloat128の値は、オプションの指数と小数として示されてもよいです。詳細な構文については、付録Bの文法規則に従ってFloatValue `」を参照してください。特別な値は、（静かな非数）、 `neginf「（負の無限大）、および` posinf」（正の無限大）「`のQNaN、（非数をシグナリング）」` SNaNのです。 -0.0と+0.0は異なる浮動小数点値であることに留意されたいです。 0.0 +0.0に等しいです。
When defining a type derived (directly or indirectly) from the Float128 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..', and an upper bound. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type, the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. The special values `snan', `qnan', `neginf', and `posinf' must be explicitly listed in restrictions if they shall be included, where `snan' and `qnan' cannot be used in ranges.
「| Float128ベースタイプから（直接または間接的に）派生型を定義する場合、可能な値のセットは、パイプ `によって分離された範囲または明示的な値のリストを、追加することによって制限することができます括弧で囲まれたリスト全体を持つ文字、。範囲は、「..下限、二つの連続したドット 'から構成され、上限。複数の値または範囲が指定されている場合、それらはすべて互いに素でなければならないと昇順でなければなりません。値制限が既に制限タイプに適用した場合、新たな制限が制限同等以上でなければなりません、それは、下限を上げる上限を減少させる、中間ギャップを有する複数の範囲に明示的な値または範囲、または分割範囲を除去することです。 `SNaNの「と` qNaNを」範囲で使用することができない場合、彼らは、含まれなければならない場合には、特別な値 `SNaNの「`のQNaN」、 `neginf「そして` posinfは、」明示的な制限にリストされている必要があります。
Note that encoding is not subject to this specification. It has to be described by protocols that transport objects of type Float128. Note also that most floating point encodings disallow the representation of many values that can be written as decimal fractions as used in SMIng for human readability. Therefore, explicit values in floating point type restrictions should be handled with care.
符号化は、本明細書の対象ではないことに留意されたいです。これは、プロトコルタイプFloat128のトランスポート・オブジェクトによって記述する必要があります。ほとんどの浮動小数点符号化は、人間の可読性のためにSMIngで使用される小数点以下のように書くことができる多くの値の表示を許可しないことにも留意されたいです。そのため、浮動小数点型の制限で明示的な値は注意して取り扱ってください。
Value Examples:
値の例：
00.1 // illegal leading zero 3.1415 // legal value -2.5E+3 // legal negative exponential value
00.1 //不正先行ゼロ3.1415 //法定値-2.5E + 3 //法的負の指数値
Restriction Examples:
制限の例：
Float128 (-1.0..1.0) // legal range spec Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 Float128 (neginf..-0.0) // legal range spec Float128 (-10.0..10.0 | 0) // illegal overlapping
Float128（-1.0..1.0）//有効範囲仕様Float128（1 | 3.3 | 5）//法的、おそらく表現できない3.3 Float128（neginf ..- 0.0）//有効範囲仕様Float128（-10.0..10.0 | 0 ）//不正な重複
The Enumeration base type represents values from a set of integers in the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where each value has an assigned name. The list of those named numbers has to be comma-separated, enclosed in parenthesis, and appended to the `Enumeration' keyword. Each named number is denoted by its lower-case identifier followed by the assigned integer value, denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis. Hexadecimal numbers must have an even number of at least two digits. Every name and every number in an enumeration type MUST be unique. It is RECOMMENDED that values be positive, start at 1, and be numbered contiguously. All named numbers MUST be given in ascending order.
列挙基本型は、各値が割り当てられた名前を持つ-2 ^ 31（-2147483648）と2 ^ 31-1（2147483647）の範囲の整数の集合からの値を表します。これらの名前の番号のリストは、カンマで区切られ、括弧で囲まれた、と `列挙」キーワードに追加しなければなりません。各名前の数は、括弧で囲まれた10進数または `0x'-接頭進数として示される割り当てられた整数値続いて小文字の識別子、によって表されます。 16進数は、少なくとも2桁の偶数を持っている必要があります。列挙型のすべての名前とすべての番号は一意でなければなりません。値が正で、1で開始することをお勧めします、と連番します。すべての名前の数字は昇順で指定する必要があります。
Values of enumeration types may be denoted as decimal or `0x'- prefixed hexadecimal numbers or preferably as their assigned names. Hexadecimal numbers must have an even number of at least two digits.
列挙型の値は、割り当てられた名前として、好ましくは16進数を接頭辞または0x'- 10進数または `のように表すことができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。
When types are derived (directly or indirectly) from an enumeration type, the set of named numbers may be equal or restricted by removing one or more named numbers, but no named numbers may be added or changed regarding its name, value, or both.
型は列挙型から（直接または間接的に）誘導される場合、名前付き数字のセットは、同じまたは1つ以上の名前付き数字を除去することによって制限することができるが、名前付きの数字は、その名前、値、またはその両方に関する追加したり変更することができます。
Type and Value Examples:
型と値の例：
Enumeration (up(1), down(2), testing(3)) Enumeration (down(2), up(1)) // illegal order
列挙（アップ（1）、ダウン（2）、（3）テスト）列挙（ダウン（2）、最大（1））//不正注文を
0 // legal (though not recommended) value up // legal value given by name 2 // legal value given by number
0 //（お勧めしませんが）正当な値まで数で与えられた名前2 //有効な値で与え//有効な値を
The Bits base type represents bit sets. That is, a Bits value is a set of flags identified by small integer numbers starting at 0. Each bit number has an assigned name. The list of those named numbers has to be comma-separated, enclosed in parenthesis, and appended to the `Bits' keyword. Each named number is denoted by its lower-case identifier followed by the assigned integer value, denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis. Hexadecimal numbers must have an even number of at least two digits. Every name and every number in a bits type MUST be unique. It is RECOMMENDED that numbers start at 0 and be numbered contiguously. Negative numbers are forbidden. All named numbers MUST be given in ascending order.
ビットベース型は、ビットセットを表します。すなわち、ビット値が各ビット数は0に割り当てられた名前を持つ開始小さな整数によって識別フラグのセットです。これらの名前の番号のリストは、カンマで区切られ、括弧で囲まれた、と `ビットキーワードに追加しなければなりません。各名前の数は、括弧で囲まれた10進数または `0x'-接頭進数として示される割り当てられた整数値続いて小文字の識別子、によって表されます。 16進数は、少なくとも2桁の偶数を持っている必要があります。ビットタイプのすべての名前とすべての番号は一意でなければなりません。数字は0から始まり、連番することが推奨されます。負の数は禁止されています。すべての名前の数字は昇順で指定する必要があります。
Values of bits types may be denoted as a comma-separated list of decimal or `0x'-prefixed hexadecimal numbers or preferably their assigned names enclosed in parenthesis. Hexadecimal numbers must have an even number of at least two digits. There MUST NOT be any element (by name or number) listed more than once. Elements MUST be listed in ascending order.
ビット・タイプの値は、10進数または `0x'-接頭16進数、または好ましくは括弧で囲まれ、割り当てられた名のカンマ区切りリストとして表すことができます。 16進数は、少なくとも2桁の偶数を持っている必要があります。 2回以上リスト（名前または番号）任意の要素があってはなりません。要素は昇順でリストされなければなりません。
When defining a type derived (directly or indirectly) from a bits type, the set of named numbers may be restricted by removing one or more named numbers, but no named numbers may be added or changed regarding its name, value, or both.
ビットタイプから（直接または間接的に）派生型を定義する場合、名前付き数字のセットは、1つの以上の名前付き数字を除去することによって制限することができるが、名前付きの数字は、その名前、値、またはその両方に関する追加したり変更することができます。
Type and Value Examples:
型と値の例：
Bits (readable(0), writable(1), executable(2)) Bits (writable(1), readable(0) // illegal order
ビット（読み取り可能な（0）、書き込み可能（1）、実行（2））ビット（書き込み可能（1）、読み取り可能な（0）//不正順序
() // legal empty value (readable, writable, 2) // legal value (0, readable, executable) // illegal, readable(0) appears twice (writable, 4) // illegal, element 4 out of range
（）//法的空の値（読み取り可能、書き込み可能、2）//有効な値（0、読み取り可能、実行可能）//不正、読み取り可能な（0）を2回表示され（書き込み可能、4）範囲外//不正、素子4
Attribute and type definitions allow the specification of a format to be used when a value of that attribute or an attribute of that type is displayed. Format specifications are represented as textual data.
属性と型定義は、その属性またはそのタイプの属性の値が表示されるときのフォーマットの仕様を使用することを可能にします。フォーマット仕様は、テキストデータとして表現されています。
When the attribute or type has an underlying base type of Integer32, Integer64, Unsigned32, or Unsigned64, the format consists of an integer-format specification containing two parts. The first part is a single character suggesting a display format, either: `x' for hexadecimal, `d' for decimal, `o' for octal, or `b' for binary. For all types, when rendering the value, leading zeros are omitted, and for negative values, a minus sign is rendered immediately before the digits. The second part is always omitted for `x', `o', and `b', and need not be present for `d'. If present, the second part starts with a hyphen and is followed by a decimal number, which defines the implied decimal point when rendering the value. For example `d-2' suggests that a value of 1234 be rendered as `12.34'.
属性又はタイプInteger32の、Integer64、Unsigned32の、またはUnsigned64にの基礎となる基本型を有する場合、フォーマットは二つの部分を含む整数形式の仕様で構成されています。 `X「進のために、` D」小数点以下、 'O「オクタルため、または' B」バイナリ用のため：最初の部分は、表示形式を示唆する単一の文字、のいずれかです。値をレンダリングする際に、すべてのタイプについては、先行ゼロが省略され、負の値のため、マイナス記号は数字の直前にレンダリングされます。第二の部分は、常に '、X「' O」、及び 'Bのために省略されている「及び' Dについて存在する必要はありません」。存在する場合、第二の部分は、ハイフンで始まり、値をレンダリングするときに暗黙の小数点を定義進数、が続きます。例えば `D-2' 1234の値が` 12.34' としてレンダリングされることを示唆しています。
When the attribute or type has an underlying base type of OctetString, the format consists of one or more octet-format specifications. Each specification consists of five parts, with each part using and removing zero or more of the next octets from the value and producing the next zero or more characters to be displayed. The octets within the value are processed in order of significance, most significant first.
属性又はタイプOctetStringに下地タイプを有する場合、フォーマットは、一つ以上のオクテットフォーマット仕様で構成されています。各仕様は、各部分が表示されるように使用してその値から次のオクテットのゼロ以上を除去し、次のゼロ以上の文字を生成すると、5つの部分から構成されています。値内のオクテットは最も重要な最初の、重要性の順に処理されています。
The five parts of a octet-format specification are:
オクテットフォーマット仕様の5つの部分です。
1. The (optional) repeat indicator. If present, this part is a `*', and indicates that the current octet of the value is to be used as the repeat count. The repeat count is an unsigned integer (which may be zero) specifying how many times the remainder of this octet-format specification should be successively applied. If the repeat indicator is not present, the repeat count is one.
1.（オプション）リピートインジケータ。存在する場合、この部分は `*」で、その値の現在のオクテットは繰り返し回数として使用されるべきであることを示しています。繰り返し回数は、このオクテットフォーマット仕様の残りの部分は連続して適用されなければならない回数を指定する（ゼロであってもよい）の符号なし整数です。リピートインジケータが存在しない場合、繰り返し回数は1です。
2. The octet length: one or more decimal digits specifying the number of octets of the value to be used and formatted by this octet-specification. Note that the octet length can be zero. If less than this number of octets remain in the value, then the lesser number of octets are used.
2オクテットの長さ：このオクテット明細書で使用してフォーマットされる値のオクテット数を指定する1つまたは複数の桁。オクテットの長さがゼロであることができることに留意されたいです。オクテット未満のこの数は、値が残っている場合は、オクテットのより少ない数が使用されます。
3. The display format, either: `x' for hexadecimal, `d' for decimal, `o' for octal, `a' for ASCII, or `t' for UTF-8 [RFC3629]. If the octet length part is greater than one, and the display format part refers to a numeric format, then network byte-ordering (big-endian encoding) is used to interpret the octets in the value. The octets processed by the `t' display format do not necessarily form an integral number of UTF-8 characters. Trailing octets which do not form a valid UTF-8 encoded character are discarded.
3.表示形式、次のいずれか `X小数ため、 'O 'オクタルため、`' UTF-8のASCIIのために、または' T」[RFC3629] '進、 `Dために'。オクテット長部分が1より大きいと、表示形式部は数値形式を指す場合、ネットワークバイト順（ビッグエンディアンエンコーディング）が値のオクテットを解釈するために使用されます。 `t」の表示形式によって処理されたオクテットは、必ずしもUTF-8文字の整数を形成しません。有効なUTF-8エンコードされた文字を形成しない末尾のオクテットは破棄されます。
4. The (optional) display separator character. If present, this part is a single character produced for display after each application of this octet-specification; however, this character is not produced for display if it would be immediately followed by the display of the repeat terminator character for this octet specification. This character can be any character other than a decimal digit and a `*'.
4.（オプション）表示区切り文字。存在する場合、この部分は、このオクテット明細書の各適用後の表示のために製造された単文字です。それはすぐにこのオクテット仕様の繰り返しターミネータ文字の表示が続く場合は、この文字を表示するために作成されていません。この文字は、小数点以下の数字と `*」以外の任意の文字にすることができます。
5. The (optional) repeat terminator character, which can be present only if the display separator character is present and this octet specification begins with a repeat indicator. If present, this part is a single character produced after all the zero or more repeated applications (as given by the repeat count) of this octet specification. This character can be any character other than a decimal digit and a `*'.
5.表示区切り文字が存在し、このオクテット仕様リピートインジケータで始まる場合にのみ存在することができる（オプション）リピート終了文字、。存在する場合、この部分は、このオクテット仕様の全てのゼロ以上の繰り返しのアプリケーション（繰り返し回数によって与えられる）後に生成単一の文字です。この文字は、小数点以下の数字と `*」以外の任意の文字にすることができます。
Output of a display separator character or a repeat terminator character is suppressed if it would occur as the last character of the display.
それは、ディスプレイの最後の文字として発生する場合は、表示区切り文字やリピート終了文字の出力が抑制されています。
If the octets of the value are exhausted before all the octet format specifications have been used, then the excess specifications are ignored. If additional octets remain in the value after interpreting all the octet format specifications, then the last octet format specification is re-interpreted to process the additional octets, until no octets remain in the value.
すべてのオクテットフォーマット仕様が使用されていた前の値のオクテットが排出される場合には、過剰な仕様は無視されます。追加のオクテットが、すべてのオクテットフォーマット仕様を解釈後の値にとどまる場合は何のオクテット値になくなるまで、そして最後のオクテットフォーマット仕様は、追加のオクテットを処理するために再解釈されます。
Note that for some types, no format specifications are defined. For derived types and attributes that are based on such types, format specifications SHOULD be omitted. Implementations MUST ignore format specifications they cannot interpret. Also note that the SMIng grammar (Appendix B) does not specify the syntax of format specifications.
いくつかのタイプのために、何のフォーマット仕様が定義されていないことに注意してください。そのようなタイプに基づいて派生型及び属性のために、形式仕様は省略されるべきです。実装は、彼らが解釈できないフォーマット仕様を無視しなければなりません。また、SMIng文法（付録B）は、フォーマット仕様の構文を指定していないことに注意してください。
Display Format Examples:
表示形式例：
Base Type Format Example Value Rendered Value
----------- ------------------- ---------------- -----------------
OctetString 255a "Hello World." Hello World.
OctetString 1x: "Hello!" 48:65:6c:6c:6f:21
OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024
OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee
Integer32 d-2 1234 12.34
The topmost container of SMIng information is a file. An SMIng file may contain zero, one or more modules. It is RECOMMENDED that modules be stored into separate files by their module names, where possible. However, for dedicated purposes, it may be reasonable to collect several modules in a single file.
SMIng情報の最上位コンテナがファイルです。 SMIngファイルはゼロ、一つ以上のモジュールが含まれていてもよいです。モジュールが可能そのモジュール名で別々のファイルに格納することを推奨します。しかし、専用の目的のために、単一のファイルに複数のモジュールを収集するのが妥当かもしれません。
The top level SMIng construct is the `module' statement (Section 5) that defines a single SMIng module. A module contains a sequence of sections in an obligatory order with different kinds of definitions. Whether these sections contain statements or remain empty mainly depends on the purpose of the module.
トップレベルSMIng構築物は、単一SMIngモジュールを定義 `モジュール」文（セクション5）です。モジュールは、定義の異なる種類の必須のためにセクションの配列を含みます。これらのセクションは、ステートメントが含まれているか、空のままかどうかを主にモジュールの目的に依存します。
Comments can be included at any position in an SMIng file, except between the characters of a single token like those of a quoted string. However, it is RECOMMENDED that all substantive descriptions be placed within an appropriate description clause, so that the information is available to SMIng parsers.
コメントは引用符で囲まれた文字列のそれらのような単一のトークンの文字の間を除いて、SMIngファイル内の任意の位置に含めることができます。しかし、情報がSMIngパーサに利用可能であるように、すべての実質的な記述は、適切な説明句内に配置することが推奨されます。
Comments commence with a pair of adjacent slashes `//' and end at the end of the line.
コメントは、行の末尾に隣接するスラッシュ `//」と一対の端で始まります。
Some statements, namely `organization', `contact', `description', `reference', `abnf', `format', and `units', get a textual argument. This text, as well as representations of OctetString values, have to be enclosed in double quotes. They may contain arbitrary characters with the following exceptional encoding rules:
いくつかの書類、すなわち `組織 '`接触'、 `記述 '`リファレンス'、 `ABNF '`フォーマット'、そして `台はテキストの引数を取得します。このテキストだけでなく、のOctetString値の表現は、二重引用符で囲む必要があります。彼らは、以下の例外的な符号化規則で任意の文字を含めることがあります。
A backslash character introduces a special character, which depends on the character that immediately follows the backslash:
バックスラッシュ文字はすぐにバックスラッシュの後に続く文字に依存の特殊文字を、導入されています。
\n new line \t a tab character \" a double quote \\ a single backslash
\ nは改行\ Tタブ文字\」二重引用符\\単一のバックスラッシュ
If the text contains a line break followed by whitespace which is used to indent the text according to the layout in the SMIng file, this prefixing whitespace is stripped from the text.
テキストはSMIngファイル内のレイアウトに応じてテキストをインデントするために使用される空白が続く改行が含まれている場合は、この接頭辞空白はテキストから取り除かれます。
SMIng has a very small set of basic grammar rules based on the concept of statements. Each statement starts with a lower-case keyword identifying the statement, followed by a number (possibly zero) of arguments. An argument may be quoted text, an identifier, a value of any base type, a list of identifiers enclosed in parenthesis `( )', or a statement block enclosed in curly braces `{ }'. Since statement blocks are valid arguments, it is possible to nest statement sequences. Each statement is terminated by a semicolon `;'.
SMIngは、文の概念に基づいて、基本的な文法規則の非常に小さなセットを持っています。各ステートメントは、引数の数（おそらくゼロ）に続いて、ステートメントを識別する小文字のキーワードで始まります。引数は、テキスト、識別子、任意の基本型の値、括弧で囲まれた識別子のリストを引用することができる `（）「または中括弧で囲まれたステートメントブロック` {}」。文のブロックが有効な引数であるため、それは巣文の配列に可能です。それぞれの文はセミコロン `で終了します;」。
The core set of statements may be extended using the SMIng `extension' statement. See Sections 6 and 11 for details.
文のコアセットはSMIng `拡張」ステートメントを使用して拡張することができます。詳細については、セクション6および11を参照してください。
At places where a statement is expected, but an unknown lower-case word is read, those statements MUST be skipped up to the proper semicolon, including nested statement blocks.
場所で文が期待されていますが、未知の小文字の単語が読まれる場合、これらのステートメントは、ネストされたステートメントのブロックを含む、適切なセミコロンまでスキップしなければなりません。
The `module' statement is used as a container of all definitions of a single SMIng module. It gets two arguments: an upper-case module name and a statement block that contains mandatory and optional statements and sections of statements in an obligatory order:
`モジュール」文は、単一のSMIngモジュールのすべての定義のコンテナとして使用されています。大文字のモジュール名と義務ために必須およびオプションの文と文のセクションが含まれている文ブロック：それは2つの引数を取得します。
module <MODULE-NAME> {
モジュール<MODULE-NAME> {
<optional import statements>
<organization statement>
<contact statement>
<description statement>
<optional reference statement>
<at least one revision statement>
<optional extension statements>
<オプションの拡張文>
<optional typedef statements>
<オプションのtypedef文>
<optional identity statements>
<オプションのアイデンティティ文>
<optional class statements>
<オプションのクラスステートメント>
};
｝；
The optional `import' statements (Section 5.1) are followed by the mandatory `organization' (Section 5.2), `contact' (Section 5.3), and `description' (Section 5.4) statements and the optional `reference' statement (Section 5.5), which in turn are followed by at least one mandatory `revision' statement (Section 5.6). The part up to this point defines the module's meta information, i.e., information that describes the whole module but does not define any items used by applications in the first instance. This part of a module is followed by its main definitions, namely SMIng extensions (Section 6), derived types (Section 7), identities (Section 8), and classes (Section 9).
オプション `インポート（5.2節）、`接触「（5.3節）、そして `記述」（5.4節）文とオプション`リファレンス」ステートメント（5.5項「文（5.1節）は必須 `組織が続いています」 ）、今度は、少なくとも1つの必須 `リビジョン」文（5.6節）が続いています。ここまでの部分は、モジュールのメタ情報、モジュール全体が記載されているが、最初のインスタンス内のアプリケーションによって使用される任意の項目を定義していない、すなわち、情報を定義します。モジュールのこの部分は、すなわち拡張（第6節）、派生タイプ（セクション7）、アイデンティティ（セクション8）、及びクラス（セクション9）SMIng、その主な定義が続きます。
See the `moduleStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `module' statement.
声明 `moduleStatement「`モジュールの正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The optional module's `import' statement is used to import identifiers from external modules into the local module's namespace. It gets two arguments: the name of the external module and a comma-separated list of one or more identifiers to be imported enclosed in parenthesis.
オプションモジュールの `インポート」文は、ローカルモジュールの名前空間に外部モジュールから識別子をインポートするために使用されます。それは2つの引数を取得します：外部モジュールの名前と1つのまたは複数の識別子のカンマ区切りリストは括弧で囲まれたインポートします。
Multiple `import' statements for the same module but with disjoint lists of identifiers are allowed, though NOT RECOMMENDED. The same identifier from the same module MUST NOT be imported multiple times. To import identifiers with the same name from different modules might be necessary and is allowed. To distinguish them in the local module, they have to be referred by qualified names. Importing identifiers not used in the local module is NOT RECOMMENDED.
推奨されていないが、同じモジュールのためではなく、識別子の互いに素リストを持つ複数の `インポート」文は、許可されています。同じモジュールから同じ識別子が複数回インポートしてはなりません。異なるモジュールから同じ名前の識別子をインポートするには必要になることがありますし、許可されています。ローカルモジュールでそれらを区別するために、彼らは修飾名で参照する必要があります。ローカルモジュールで使用されていない識別子をインポートすることはお勧めできません。
See the `importStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `import' statement.
声明 `importStatement「`輸入の正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The module's `organization' statement, which must be present, gets one argument which is used to specify a textual description of the organization(s) under whose auspices this module was developed.
存在していなければならないモジュールの `組織の声明は、このモジュールが開発されたその後援の下、組織（複数可）のテキスト記述を指定するために使用される一つの引数を取得します。
The module's `contact' statement, which must be present, gets one argument which is used to specify the name, postal address, telephone number, and electronic mail address of the person to whom technical queries concerning this module should be sent.
存在していなければならないモジュールの `接触」ステートメントは、名前、住所、電話番号、およびこのモジュールに関する技術的なクエリを送信する必要があります誰に人の電子メールアドレスを指定するために使用される一つの引数を取得します。
The module's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the contents of this module.
存在していなければならないモジュールの `記述」ステートメントは、このモジュールの内容の高レベルのテキスト記述を指定するために使用される一つの引数を取得します。
The module'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 management information, or some other document which provides additional information relevant to this module.
存在する必要はないモジュールの `リファレンス」ステートメントは、いくつかの他の文書へのテキストの相互参照を指定するために使用される一つの引数、関連する管理情報を定義する別のモジュール、またはそれに関連する追加情報を提供するいくつかの他の文書のいずれかを取得しますこのモジュール。
The module's `revision' statement is repeatedly used to specify the editorial revisions of the module, including the initial revision. It gets one argument which is a statement block that holds detailed information in an obligatory order. A module MUST have at least one initial `revision' statement. For every editorial change, a new one MUST be added in front of the revisions sequence, so that all revisions are in reverse chronological order.
モジュールの `リビジョン」文を繰り返し、最初の改正を含むモジュールの編集リビジョンを指定するために使用されます。それは義務順に詳細な情報を保持している文ブロック1つの引数を取得します。モジュールは、少なくとも一つの初期 `リビジョン」文を持たなければなりません。すべてのリビジョンが新しい順になるように、すべての編集上の変更のために、新しいものは、改正シーケンスの前に加えなければなりません。
See the `revisionStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `revision' statement.
声明 `revisionStatement「`改正の正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The revision's `date' statement, which must be present, gets one argument which is used to specify the date and time of the revision in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the time `00:00'. The time is always given in UTC.
または暗示 `YYYY-MM-DD」：リビジョンの`日付「MM存在していなければならない文は、形式 `YYYY-MM-DD HHに改訂の日付と時刻を指定するために使用される一つの引数を取得します」時間 `午前0' 時。時間は常にUTCに与えられています。
See the `date' rule of the SMIng grammar (Appendix B) for the formal syntax of the revision's `date' statement.
声明「リビジョンの `日付の正式な構文についてはSMIng文法（付録B）のルール」`日付を参照してください。
The revision's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the revision.
存在しなければなりませんリビジョンの `記述」ステートメントは、改正の高レベルのテキスト記述を指定するために使用される一つの引数を取得します。
Consider how a skeletal module might be constructed:
骨格モジュールが構築されるかもしれない方法を考えてみましょう：
module ACME-MIB {
モジュールACME-MIB {
import NMRG-SMING (DisplayString);
インポートNMRG-SMING（のDisplayString）。
organization "IRTF Network Management Research Group (NMRG)";
組織「IRTFネットワーク管理研究グループ（NMRG）」。
contact "IRTF Network Management Research Group (NMRG) http://www.ibr.cs.tu-bs.de/projects/nmrg/
接触「IRTFネットワーク管理研究グループ（NMRG）http://www.ibr.cs.tu-bs.de/projects/nmrg/
Joe L. User
ジョーL.ユーザー
ACME, Inc. 42 Anywhere Drive Nowhere, CA 95134 USA
どこどこにもドライブしないACME社42、CA 95134 USA
Phone: +1 800 555 0815 EMail: joe@acme.example.com";
電話：+1 800 555 0815 Eメール：joe@acme.example.com ";
description "The module for entities implementing the ACME protocol.
説明「ACMEプロトコルを実装するエンティティのためのモジュール。
Copyright (C) The Internet Society (2004).
All Rights Reserved.
This version of this MIB module is part of RFC 3780,
see the RFC itself for legal notices.";
revision {
date "2003-12-16";
description
"Initial revision, published as RFC 3780.";
};
// ... further definitions ...
// ...さらに定義...
}; // end of module ACME-MIB.
}。 //モジュールACME-MIBの終わり。
The `extension' statement defines new statements to be used in the local module following this extension statement definition or in external modules that may import this extension statement definition. The `extension' statement gets two arguments: a lower-case extension statement identifier and a statement block that holds detailed extension information in an obligatory order.
`拡張」ステートメントは、この拡張文の定義や、この拡張文の定義をインポートする外部モジュールで、次のローカルモジュールで使用される新しいステートメントを定義します。小文字拡張文識別子と義務順に詳細な拡張情報を保持しているステートメントブロック： `拡張」ステートメントは2つの引数を取得します。
Extension statement identifiers SHOULD NOT contain any upper-case characters.
拡張文の識別子は、任意の大文字の文字を含めることはできません。
Note that the SMIng extension feature does not allow the formal specification of the context, or argument syntax and semantics of an extension. Its only purpose is to declare the existence of an extension and to allow a unique reference to an extension. See Section 11 for detailed information on extensions and [RFC3781] for mappings of SMIng definitions to SNMP, which is formally defined as an extension.
SMIng拡張機能は拡張の正式な文脈の仕様、または引数の構文とセマンティクスを許可しないことに注意してください。その唯一の目的は、拡張機能の存在を宣言するとエクステンションへの固有の参照を可能にすることです。正式に拡張として定義されているSNMPにSMIng定義のマッピングのための拡張機能の詳細については、セクション11および[RFC3781]を参照してください。
See the `extensionStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `extension' statement.
声明 `extensionStatement「`拡張の正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The extension's `status' statement, which must be present, gets one argument which is used to specify whether this extension 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.
存在していなければならない拡張子の `状態ステートメントは、この拡張定義は、現在または歴史的であるかどうかを指定するために使用されている一つの引数を取得します。 「`電流値は定義が現在、有効であることを意味しています。値「'時代遅れの定義は廃止され、実施されるべきではない及び/又は以前に実施された場合に除去することができることを意味します。 `」非推奨値も時代遅れの定義を示しますが、それは/古い既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
The extension's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the extension statement.
存在していなければならない拡張機能の `記述」ステートメントは、拡張文のハイレベルのテキスト記述を指定するために使用される一つの引数を取得します。
It is RECOMMENDED that information on the extension's context, its semantics, and implementation conditions be included. See also Section 11.
拡張機能のコンテキスト、その意味論、および実装条件に関する情報が含まれることが推奨されます。第11節も参照してください。
The extension'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 extension definitions, or some other document which provides additional information relevant to this extension.
存在する必要はない拡張子の `リファレンス」ステートメントは、1つのいくつかの他の文書へのテキストの相互参照を指定するために使用される引数のいずれかに関連する拡張定義を定義する別のモジュール、またはそれに関連する追加情報を提供する他のいくつかのドキュメントを取得しますこの拡張機能。
The extension's `abnf' statement, which need not be present, gets one argument which is used to specify a formal ABNF [RFC2234] grammar definition of the extension. This grammar can reference rule names from the core SMIng grammar (Appendix B).
存在する必要はない拡張機能の `「ABNF文、拡張子の正式なABNF [RFC2234]文法定義を指定するために使用される一つの引数を取得します。この文法は、コアSMIng文法（付録B）からルール名を参照することができます。
Note that the `abnf' statement should contain only pure ABNF and no additional text, though comments prefixed by a semicolon are allowed but should probably be moved to the description statement. Note that double quotes within the ABNF grammar have to be represented as `\"' according to Section 4.2.
`ABNF」ステートメントは、セミコロンで始まるコメントは許可されているものの、純粋なABNFなし追加のテキストが含まれている必要がありますが、おそらく説明書に移動する必要があることに注意してください。 ABNF文法内の二重引用符は、セクション4.2によると、 `\"」と表現する必要があることに注意してください。
extension severity {
status current;
description
"The optional severity extension statement can only
be applied to the statement block of an SMIng class'
event definition. If it is present it denotes the
severity level of the event in a range from 0
(emergency) to 7 (debug).";
abnf
"severityStatement = severityKeyword sep number optsep \";\"
severityKeyword = \"severity\"";
};
The `typedef' statement defines new data types to be used in the local module or in external modules. It gets two arguments: an upper-case type identifier and a statement block that holds detailed type information in an obligatory order.
`」のtypedef文は、ローカルモジュールまたは外部モジュールで使用される新しいデータ型を定義します。大文字のタイプ識別子と義務順に詳細な型情報を保持しているステートメントブロック：それは2つの引数を取得します。
Type identifiers SHOULD NOT consist of all upper-case characters and SHOULD NOT contain hyphens.
タイプ識別子はすべて大文字で構成されてはならず、ハイフンを含めることはできません。
See the `typedefStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `typedef' statement.
声明 `typedefStatement「` typedefでの正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The typedef's `type' statement, which must be present, gets one argument which is used to specify the type from which this type is derived. Optionally, type restrictions may be applied to the new type by appending subtyping information according to the rules of the base type. See Section 3 for SMIng base types and their type restrictions.
存在していなければならないのtypedefの `型」ステートメントは、このタイプが由来するタイプを指定するために使用される一つの引数を取得します。必要に応じて、型の制限は、基本タイプの規則に従ってサブタイプ情報を付加することにより、新しいタイプに適用することができます。 SMIngの基本型とその型の制限については、セクション3を参照してください。
The typedef's `default' statement, which need not be present, gets one argument which is used to specify an acceptable default value for attributes of this type. A default value may be used when an attribute instance is created. That is, the value is a "hint" to implementors.
存在する必要はないのtypedefの `デフォルトの」ステートメントは、このタイプの属性のための許容可能なデフォルト値を指定するために使用される一つの引数を取得します。属性インスタンスの作成時にデフォルト値を使用することができます。つまり、値は実装者への「ヒント」です。
The value of the `default' statement must, of course, correspond to the (probably restricted) type specified in the typedef's `type' statement.
`デフォルトの値は声明「ステートメントは、当然のことながら、（おそらく制限）のtypedefの` typeで指定された型に対応している必要があります」。
The default value of a type may be overwritten by a default value of an attribute of this type.
タイプのデフォルト値は、このタイプの属性のデフォルト値で上書きすることができます。
Note that for some types, default values make no sense.
いくつかのタイプのために、デフォルト値は意味をなさないことに注意してください。
The typedef's `format' statement, which need not be present, gets one argument which is used to give a hint as to how the value of an instance of an attribute of this type might be displayed. See Section 3.13 for a description of format specifications.
存在する必要はないのtypedefの `フォーマット」ステートメントは、このタイプの属性のインスタンスの値が表示される場合があります方法についてのヒントを与えるために使用される一つの引数を取得します。フォーマット仕様の説明については、3.13節を参照してください。
If no format is specified, it is inherited from the type given in the `type' statement. On the other hand, the format specification of a type may be semantically refined by a format specification of an attribute of this type.
形式が指定されていない場合は、 `タイプ」文で指定された型から継承されます。一方、タイプのフォーマット仕様は意味的にこのタイプの属性のフォーマット仕様によって精製することができます。
The typedef's `units' statement, which need not be present, gets one argument which is used to specify a textual definition of the units associated with attributes of this type.
存在する必要はないのtypedefの `ユニットの文は、このタイプの属性に関連付けられているユニットのテキストの定義を指定するために使用される一つの引数を取得します。
If no units are specified, they are inherited from the type given in the `type' statement. On the other hand, the units specification of a type may be semantically refined by a units specification of an attribute of this type.
単位を指定しない場合、それらは `タイプ」文で指定された型から継承されます。一方、型のユニット仕様は意味的にこのタイプの属性のユニット仕様によって精製することができます。
The units specification has to be appropriate for values displayed according to the typedef's format specification, if present. For example, if the type defines frequency values of type Unsigned64 measured in thousands of Hertz, the format specification should be `d-3' and the units specification should be `Hertz' or `Hz'. If the format specification would be omitted, the units specification should be `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay attention to keep format and units specifications in sync. Application implementors MUST NOT implement units specifications without implementing format specifications.
ユニット仕様は存在する場合、型定義のフォーマット指定に従って表示される値のために適切でなければなりません。型はヘルツの数千で測定タイプUnsigned64に周波数値を定義する場合、例えば、形式仕様はD-3' または `ヘルツ '及び単位仕様が`ヘルツであるべきである `であるべきです。フォーマット指定が省略される場合、単位仕様は `ミリヘルツ「または`メガヘルツ」でなければなりません。 SMIngモジュールの作者は、同期形式とユニットの仕様を維持するために注意を払う必要があります。アプリケーションの実装は、形式仕様を実装せずにユニットの仕様を実装してはなりません。
The typedef's `status' statement, which must be present, gets one argument which is used to specify whether this type 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.
存在していなければならないのtypedefの `状態ステートメントは、この種の定義は、現在または歴史的であるかどうかを指定するために使用されている一つの引数を取得します。 「`電流値は定義が現在、有効であることを意味しています。値「'時代遅れの定義は廃止され、実施されるべきではない及び/又は以前に実施された場合に除去することができることを意味します。 `」非推奨値も時代遅れの定義を示しますが、それは/古い既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
Derived types SHOULD NOT be defined as `current' if their underlying type is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if their underlying type is `obsolete'. Nevertheless, subsequent revisions of the underlying type cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module.
「その基になる型が `廃止されている場合」または「`時代遅れの派生型は `現在のように定義されるべきではありません。同様に、彼らは `「その基になる型が`廃止された場合に」非推奨のように定義されるべきではありません。それにも関わらず、基になる型のその後の改正を回避することはできませんが、ローカルモジュールのその後の改正に考慮されるべきです。
The typedef's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the newly defined type.
存在していなければならないのtypedefの `記述」ステートメントは、新たに定義されたタイプの高レベルのテキスト記述を指定するために使用される一つの引数を取得します。
It is RECOMMENDED that all semantic definitions necessary for implementation, and to embody any information which would otherwise be communicated in any commentary annotations associated with this type definition be included.
これは、実装のために必要な、全ての意味論的定義が推奨され、そうでなければ含まれるこのタイプの定義に関連する任意の論評注釈で通信される情報を具現化します。
The typedef'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 type definitions, or some other document which provides additional information relevant to this type definition.
存在する必要はないのtypedefの `リファレンス」ステートメントは、いくつかの他の文書へのテキストの相互参照を指定するために使用される一つの引数、関連する型定義を定義する別のモジュール、またはそれに関連する追加情報を提供するいくつかの他の文書のいずれかを取得しますこのタイプの定義。
typedef RptrOperStatus {
type Enumeration (other(1), ok(2), rptrFailure(3),
groupFailure(4), portFailure(5),
generalFailure(6));
default other; // undefined by default.
status deprecated;
description
"A type to indicate the operational state
of a repeater.";
reference
"[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState.";
};
typedef SnmpTransportDomain {
type Pointer (snmpTransportDomain);
status current;
description
"A pointer to an SNMP transport domain identity.";
};
typedef DateAndTime {
type OctetString (8 | 11);
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
status current;
description
"A date-time specification.
...
Note that if only local time is known, then timezone
information (fields 8-10) is not present.";
reference
"RFC 2579, SNMPv2-TC.DateAndTime.";
};
typedef Frequency {
type Unsigned64;
format "d-3"
units "Hertz";
status current;
description
"A wide-range frequency specification measured
in thousands of Hertz.";
};
The `identity' statement is used to define a new abstract and untyped identity. Its only purpose is to denote its name, semantics, and existence. An identity can be defined either from scratch or derived from a parent identity. The `identity' statement gets the following two arguments: The first argument is a lower-case identity identifier. The second argument is a statement block that holds detailed identity information in an obligatory order.
`アイデンティティ」ステートメントは、新たな抽象的で型なしアイデンティティを定義するために使用されます。その唯一の目的は、その名前、意味論、および存在を示すためにです。アイデンティティは最初からまたは親アイデンティティ由来のいずれかに定義することができます。 `アイデンティティ」ステートメントは、次の2つの引数を取得します：最初の引数は小文字のアイデンティティ識別子です。第二引数は必須のために詳細な識別情報を保持している文ブロックです。
See the `identityStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `identity' statement.
声明 `identityStatement「`アイデンティティの正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The identity's `parent' statement must be present for a derived identity and must be absent for an identity defined from scratch. It gets one argument which is used to specify the parent identity from which this identity shall be derived.
アイデンティティの `親の文は派生アイデンティティのために存在している必要がありますし、最初から定義されたアイデンティティのために存在してはなりません。これは、このアイデンティティの派生元になる親IDを指定するために使用される一つの引数を取得します。
The identity's `status' statement, which must be present, gets one argument which is used to specify whether this identity 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.
存在している必要がありますアイデンティティの `状態ステートメントは、このアイデンティティの定義は、現在または歴史的であるかどうかを指定するために使用されている一つの引数を取得します。 「`電流値は定義が現在、有効であることを意味しています。値「'時代遅れの定義は廃止され、実施されるべきではない及び/又は以前に実施された場合に除去することができることを意味します。 `」非推奨値も時代遅れの定義を示しますが、それは/古い既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
Derived identities SHOULD NOT be defined as `current' if their parent identity is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if their parent identity is `obsolete'. Nevertheless, subsequent revisions of the parent identity cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module.
「親のアイデンティティが `廃止されている場合」または「`時代遅れ派生アイデンティティは `現在のように定義されるべきではありません。同様に、彼らは `「親のIDが`廃止されている場合は、」非推奨のように定義されるべきではありません。それにもかかわらず、親アイデンティティのその後の改正を回避することはできませんが、ローカルモジュールのその後の改正に考慮されるべきです。
The identity's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the newly defined identity.
存在している必要がありますアイデンティティの `記述」ステートメントは、新しく定義されたアイデンティティの高レベルのテキスト記述を指定するために使用される一つの引数を取得します。
It is RECOMMENDED that all semantic definitions necessary for implementation, and to embody any information which would otherwise be communicated in any commentary annotations associated with this identity definition be included.
これは、実装するために必要なことすべてのセマンティックの定義推奨され、それ以外の場合、このアイデンティティの定義が含まれて関連付けられた任意の論評注釈でも伝えられるどんな情報を具現化します。
The identity'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 identity definitions, or some other document which provides additional information relevant to this identity definition.
存在する必要はないアイデンティティの `リファレンス」ステートメントは、1つのいくつかの他の文書へのテキストの相互参照を指定するために使用される引数のいずれかの関連アイデンティティの定義を定義する別のモジュール、またはそれに関連する追加情報を提供する他のいくつかのドキュメントを取得しますこのアイデンティティの定義。
identity null {
status current;
description
"An identity used to represent null pointer values.";
};
identity snmpTransportDomain {
status current;
description
"A generic SNMP transport domain identity.";
};
identity snmpUDPDomain {
parent snmpTransportDomain;
status current;
description
"The SNMP over UDP transport domain.";
};
The `class' statement is used to define a new class that represents a container of related attributes and events (Section 9.2, Section 9.4). A class can be defined either from scratch or derived from a parent class. A derived class inherits all attributes and events of the parent class and can be extended by additional attributes and events.
`クラスステートメントは、関連する属性やイベント（9.2節、9.4節）のコンテナを表す新しいクラスを定義するために使用されます。クラスは、どちらか最初から定義されたか、親クラスから派生することができます。派生クラスは親クラスのすべての属性やイベントを継承し、追加の属性やイベントによって拡張することができます。
The `class' statement gets the following two arguments: The first argument is an upper-case class identifier. The second argument is a statement block that holds detailed class information in an obligatory order.
`クラスステートメントは、次の2つの引数を取得します：最初の引数は大文字のクラス識別子です。第二引数は必須のために、詳細なクラス情報を保持している文ブロックです。
See the `classStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `class' statement.
声明 `classStatement」`クラスの正式な構文についてはSMIng文法（付録B）のルールを参照してください。
The class' `extends' statement must be present for a class derived from a parent class and must be absent for a class defined from scratch. It gets one argument which is used to specify the parent class from which this class shall be derived.
拡張 `クラスは、ステートメントは、親クラスから派生したクラスのために存在している必要がありますし、最初から定義されたクラスのために存在してはなりません。それは、このクラスの派生元になる親クラスを指定するために使用される一つの引数を取得します。
The class' `attribute' statement, which can be present zero, one or multiple times, gets two arguments: the attribute name and a statement block that holds detailed attribute information in an obligatory order.
属性名と義務順に詳細な属性情報を保持しているステートメントブロック：現在、ゼロ、1または複数回、することができ、クラス `属性」ステートメントは、2つの引数を受け取ります。
The attribute's `type' statement must be present. It gets at least one argument which is used to specify the type of the attribute: either a type name or a class name. In case of a type name, it may be restricted by a second argument according to the restriction rules described in Section 3.
属性の `タイプ」ステートメントが存在している必要があります。タイプ名またはクラス名のいずれか：それは属性の種類を指定するために使用され、少なくとも一つの引数を取得します。タイプ名の場合には、第3節で説明した制限ルールに従って第二の引き数によって制限されてもよいです。
The attribute's `access' statement must be present for attributes typed by a base type or derived type, and must be absent for attributes typed by a class. It gets one argument which is used to specify whether it makes sense to read and/or write an instance of the attribute, or to include its value in an event. This is the maximal level of access for the attribute. This maximal level of access is independent of any administrative authorization policy.
属性の `アクセスステートメントは、基本型または派生型で入力された属性のために存在しなければならない、とクラスによって入力された属性の不在でなければなりません。それは読んで/または属性のインスタンスを作成し、またはイベントで、その値が含まれるようにするために理にかなっているかどうかを指定するために使用される一つの引数を取得します。これは、属性のアクセスの最大レベルです。アクセスのこの最大レベルは、どの行政許可ポリシーとは無関係です。
The value `readwrite' indicates that read and write access makes sense. The value `readonly' indicates that read access makes sense, but write access is never possible. The value `eventonly' indicates an object which is accessible only via an event.
値 `読み書きは」は読み取りおよび書き込みアクセスが理にかなって示しています。値は `読み取り専用」読み取りアクセスが理にかなっていることを示しますが、アクセスが可能になることはありません書きます。値は `eventonly」唯一のイベントを介してアクセス可能なオブジェクトを示します。
These values are ordered, from least to greatest access level: `eventonly', `readonly', `readwrite'.
これらの値は、少なくともからの最大のアクセスレベルに、注文されている： `eventonly「`読み取り専用」、「`READWRITE。
The attribute's `default' statement need not be present for attributes typed by a base type or derived type, and must be absent for attributes typed by a class. It gets one argument which is used to specify an acceptable default value for this attribute. A default value may be used when an attribute instance is created. That is, the value is a "hint" to implementors.
属性の `デフォルトの」ステートメントは、基本型または派生型で入力された属性の存在である必要はなく、クラスによって入力された属性の不在でなければなりません。これは、この属性の許容デフォルト値を指定するために使用される一つの引数を取得します。属性インスタンスの作成時にデフォルト値を使用することができます。つまり、値は実装者への「ヒント」です。
The value of the `default' statement must, of course, correspond to the (probably restricted) type specified in the attribute's `type' statement.
`デフォルトの値は声明「ステートメントは、当然のことながら、（おそらく制限）属性の` typeで指定された型に対応している必要があります」。
The attribute's default value overrides the default value of the underlying type definition if both are present.
両方が存在する場合、属性のデフォルト値は、基礎となる型定義のデフォルト値を上書きします。
The attribute's `format' statement need not be present for attributes typed by a base type or derived type, and must be absent for attributes typed by a class. It gets one argument which is used to give a hint as to how the value of an instance of this attribute might be displayed. See Section 3.13 for a description of format specifications.
属性の `フォーマット」ステートメントは、基本型または派生型で入力された属性の存在である必要はなく、クラスによって入力された属性の不在でなければなりません。これは、この属性のインスタンスの値が表示される場合があります方法についてのヒントを与えるために使用される一つの引数を取得します。フォーマット仕様の説明については、3.13節を参照してください。
The attribute's format specification overrides the format specification of the underlying type definition if both are present.
両方が存在する場合、属性の形式仕様は、基本的な型定義の書式指定を上書きします。
The attribute's `units' statement need not be present for attributes typed by a base type or derived type, and must be absent for attributes typed by a class. It gets one argument which is used to specify a textual definition of the units associated with this attribute.
属性の `台ステートメントは、基本型または派生型で入力された属性の存在である必要はなく、クラスによって入力された属性の不在でなければなりません。それは、この属性に関連付けられているユニットのテキストの定義を指定するために使用される一つの引数を取得します。
The attribute's units specification overrides the units specification of the underlying type definition if both are present.
両方が存在する場合、属性のユニットの仕様は、基本的な型定義の単位の指定を上書きします。
The units specification has to be appropriate for values displayed according to the attribute's format specification if present. For example, if the attribute represents a frequency value of type Unsigned64 measured in thousands of Hertz, the format specification should be `d-3' and the units specification should be `Hertz' or `Hz'. If the format specification would be omitted, the units specification should be `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay attention to keep format and units specifications of type and attribute definitions in sync. Application implementors MUST NOT implement units specifications without implementing format specifications.
ユニット仕様は存在する場合、属性のフォーマット指定に従って表示される値のために適切でなければなりません。属性はヘルツの数千で測定タイプUnsigned64に周波数の値を表す場合、例えば、形式仕様はD-3' または `ヘルツ '及び単位仕様が`ヘルツであるべきである `であるべきです。フォーマット指定が省略される場合、単位仕様は `ミリヘルツ「または`メガヘルツ」でなければなりません。 SMIngモジュールの作者は、同期タイプと属性の定義の形式やユニットの仕様を維持するために注意を払う必要があります。アプリケーションの実装は、形式仕様を実装せずにユニットの仕様を実装してはなりません。
The attribute's `status' statement must be present. It gets one argument which is used to specify whether this attribute 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.
属性の `状態ステートメントが存在しなければなりません。これは、この属性の定義は、現在または歴史的であるかどうかを指定するために使用されている一つの引数を取得します。 「`電流値は定義が現在、有効であることを意味しています。値「'時代遅れの定義は廃止され、実施されるべきではない及び/又は以前に実施された場合に除去することができることを意味します。 `」非推奨値も時代遅れの定義を示しますが、それは/古い既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
Attributes SHOULD NOT be defined as `current' if their type or their containing class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if their type or their containing class is `obsolete'. Nevertheless, subsequent revisions of used type definition cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module.
「自分のタイプやそれを含むクラスは `廃止されている場合」または「`時代遅れの属性は、現在の `のように定義されるべきではありません。同様に、彼らは `「その種類やそれを含むクラスは`廃止されている場合は、」非推奨のように定義されるべきではありません。それにもかかわらず、使用されるタイプ定義のその後の改正を回避することはできませんが、ローカルモジュールのその後の改正に考慮されるべきです。
The attribute's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this attribute.
存在していなければならない属性の `記述」ステートメントは、この属性の高レベルのテキスト記述を指定するために使用される一つの引数を取得します。
It is RECOMMENDED that all semantic definitions necessary for the implementation of this attribute be included.
この属性の実装に必要なすべての意味定義を含めることが推奨されます。
The attribute'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 attribute definitions, or some other document which provides additional information relevant to this attribute definition.
存在する必要はない属性の `リファレンス」ステートメントは、1つのいくつかの他の文書へのテキストの相互参照を指定するために使用される引数のいずれかの関連属性の定義を定義する別のモジュール、またはそれに関連する追加情報を提供する他のいくつかのドキュメントを取得しますこの属性定義。
The class' `unique' statement, which need not be present, gets one argument that specifies a comma-separated list of attributes of this class, enclosed in parenthesis. If present, this list of attributes makes up a unique identification of all possible instances of this class. It can be used as a unique key in underlying protocols.
存在する必要はないクラス `ユニークな」ステートメントは、括弧で囲まれたこのクラスの属性のカンマ区切りリストを指定する一つの引数を取得します。存在する場合、属性のリストは、このクラスのすべての可能なインスタンスの一意の識別を構成します。これは、基礎となるプロトコルで一意のキーとして使用することができます。
If the list is empty, the class should be regarded as a scalar class with only a single instance.
リストが空の場合、クラスは、単一のインスタンスだけでスカラークラスとしてみなされるべきです。
If the `unique' statement is not present, the class is not meant to be instantiated directly, but to be contained in other classes or the parent class of other refining classes.
`ユニークな」文が存在しない場合、クラスは直接インスタンス化されることを意味しないが、他のクラスや他の精製クラスの親クラスに含まれます。
If present, the attribute list MUST NOT contain any attribute more than once and the attributes should be ordered where appropriate so that the attributes that are most significant in most situations appear first.
存在する場合、属性リストは、複数回任意の属性を含んではならないと、ほとんどの状況で最も重要な属性は、最初に表示されるように属性が適切な場合に注文する必要があります。
The class' `event' statement is used to define an event related to an instance of this class that can occur asynchronously. It gets two arguments: a lower-case event identifier and a statement block that holds detailed information in an obligatory order.
クラス `イベント」ステートメントは非同期に発生する可能性があり、このクラスのインスタンスに関連するイベントを定義するために使用されます。小文字のイベント識別子と義務順に詳細な情報を保持しているステートメントブロック：それは2つの引数を取得します。
See the `eventStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `event' statement.
声明 `eventStatement「`イベントの正式な構文についてはSMIng文法（付録B）のルール」を参照してください。
The event's `status' statement, which must be present, gets one argument which is used to specify whether this event 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.
存在していなければならないイベントの `状態ステートメントは、このイベントの定義は、現在または歴史的であるかどうかを指定するために使用されている一つの引数を取得します。 「`電流値は定義が現在、有効であることを意味しています。値「'時代遅れの定義は廃止され、実施されるべきではない及び/又は以前に実施された場合に除去することができることを意味します。 `」非推奨値も時代遅れの定義を示しますが、それは/古い既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
The event's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this event.
存在していなければならないイベントの `記述」ステートメントは、このイベントのハイレベルのテキスト記述を指定するために使用される一つの引数を取得します。
It is RECOMMENDED that all semantic definitions necessary for the implementation of this event be included. In particular, which instance of the class is associated with an event of this type SHOULD be documented.
このイベントの実装に必要なすべての意味定義を含めることが推奨されます。具体的には、そのクラスのインスタンスが、このタイプのイベントに関連付けられているが文書化されるべきです。
The event'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 event definitions, or some other document which provides additional information relevant to this event definition.
存在する必要はないイベントの `リファレンス」ステートメントは、1つのいくつかの他の文書へのテキストの相互参照を指定するために使用される引数のいずれかの関連イベント定義を定義する別のモジュール、またはそれに関連する追加情報を提供する他のいくつかのドキュメントを取得しますこのイベント定義。
The class' `status' statement, which must be present, gets one argument which is used to specify whether this class 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.
存在していなければならないクラス `状態ステートメントは、このクラス定義が現在または歴史的であるかどうかを指定するために使用されている一つの引数を取得します。 「`電流値は定義が現在、有効であることを意味しています。値「'時代遅れの定義は廃止され、実施されるべきではない及び/又は以前に実施された場合に除去することができることを意味します。 `」非推奨値も時代遅れの定義を示しますが、それは/古い既存の実装との相互運用性を促進するために、継続的な/新しい実装を可能にします。
Derived classes SHOULD NOT be defined as `current' if their parent class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if their parent class is `obsolete'. Nevertheless, subsequent revisions of the parent class cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module.
「自分の親クラスが `廃止されている場合」または「`時代遅れの派生クラスは `現在のように定義されるべきではありません。同様に、彼らは `「親クラスは`廃止されている場合は、」非推奨のように定義されるべきではありません。それにもかかわらず、親クラスのその後の改正を回避することはできませんが、ローカルモジュールのその後の改正に考慮されるべきです。
The class' `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the newly defined class.
存在していなければならないクラス `記述」ステートメントは、新たに定義されたクラスの高レベルのテキスト記述を指定するために使用される一つの引数を取得します。
It is RECOMMENDED that all semantic definitions necessary for implementation, and to embody any information which would otherwise be communicated in any commentary annotations associated with this class definition be included.
これは、実装のために必要な、全ての意味論的定義が推奨され、そうでなければ含まれるこのクラス定義に関連する任意の論評注釈で通信される情報を具現化します。
The class' `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 class definitions, or some other document which provides additional information relevant to this class definition.
存在する必要はないクラス `リファレンス」文は、いくつかの他の文書へのテキストの相互参照を指定するために使用される一つの引数、関連するクラス定義を定義する別のモジュール、または関連する追加情報を提供するいくつかの他の文書のいずれかを取得しますこのクラス定義へ。
Consider how an event might be described that signals a status change of an interface:
インタフェースの状態変化を知らせるそのイベントが記述されているかもしれない方法を考えてみましょう：
class Interface {
// ...
attribute speed {
type Gauge32;
access readonly;
units "bps";
status current;
description
"An estimate of the interface's current bandwidth
in bits per second.";
};
// ...
attribute adminStatus {
type AdminStatus;
access readwrite;
status current;
description
"The desired state of the interface.";
};
attribute operStatus {
type OperStatus;
access readonly;
status current;
description
"The current operational state of the interface.";
};
event linkDown {
status current;
description
"A linkDown event signifies that the ifOperStatus
attribute for this interface instance 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.";
};
｝；
status current;
description
"A physical or logical network interface.";
};
｝；
As experience is gained with a module, it may be desirable to revise that module. However, changes are not allowed if they have any potential to cause interoperability problems between an implementation using an original specification and an implementation using an updated specification(s).
経験がモジュールで獲得されるので、そのモジュールを改訂することが望ましい場合があります。彼らは更新仕様（複数可）を使用して、元の仕様と実装を使用して実装間の相互運用性の問題を引き起こすあらゆる可能性を持っている場合は、変更が許可されていません。
For any change, some statements near the top of the module MUST be updated to include information about the revision: specifically, a new `revision' statement (Section 5.6) must be included in front of the `revision' statements. Furthermore, any necessary changes MUST be applied to other statements, including the `organization' and `contact' statements (Section 5.2, Section 5.3).
具体的には、新しい `リビジョン文「文（5.6節）は`改正の前に含まれていなければならない」：任意の変更については、モジュールの上部付近にいくつかのステートメントは、リビジョンについての情報を含むように更新されなければなりません。また、必要な変更は `組織「と`コンタクト」文（5.2節、5.3節）を含む、他のステートメントに適用されなければなりません。
Note that any definition contained in a module is available to be imported by any other module, and is referenced in an `import' statement via the module name. Thus, a module name MUST NOT be changed. Specifically, the module name (e.g., `ACME-MIB' in the example of Section 5.7) MUST NOT be changed when revising a module (except to correct typographical errors), and definitions MUST NOT be moved from one module to another.
モジュールに含まれるすべての定義は、他のモジュールによってインポートすることが可能で、モジュール名を経由して `インポート」ステートメントで参照されることに注意してください。このように、モジュール名を変更してはいけません。具体的には、（入力ミスを修正する以外）モジュールを修正するとき、モジュール名（5.7節の例では、例えば、 `ACME-MIB」）は変更してはならない、と定義が一つのモジュールから別のものに移動してはいけません。
Also note that obsolete definitions MUST NOT be removed from modules since their identifiers may still be referenced by other modules.
また、その識別子は、まだ他のモジュールによって参照することができるので、時代遅れの定義はモジュールから削除してはならないことに注意してください。
A definition may be revised in any of the following ways:
定義は、以下のいずれかの方法で変更することがあります。
o In `typedef' statement blocks, a `type' statement containing an `Enumeration' or `Bits' type may have new named numbers added.
Oのtypedef `で「ステートメント・ブロック、`タイプ」 `列挙」または`ビットタイプを含む文は、新しい名前の数字が追加されています。
o In `typedef' statement blocks, the value of a `type' statement may be replaced by another type if the new type is derived (directly or indirectly) from the same base type, has the same set of values, and has identical semantics.
新しいタイプは、同じ基本型から（直接または間接的に）誘導される場合、Oのtypedef 'で「文ブロック、'タイプ」の値ステートメントは、別の型で置き換えられてもよく、値の同じセットを有しており、同一の意味を有します。
o In `attribute' statements where the `type' sub-statement specifies a class, the class may be replaced by another class if the new class is derived (directly or indirectly) from the base class and both classes have identical semantics.
Oサブステートメントクラスを指定 `属性「'タイプ文」は、新たなクラスを派生された場合にクラスは、ベースクラスから（直接または間接的に）別のクラスで置き換えられてもよく、両方のクラスが同じ意味を有します。
o In `attribute' statements where the `type' sub-statement specifies a base type, a defined type, or an implicitly derived type (i.e., not a class), that type may be replaced by another type if the new type is derived (directly or indirectly) from the same base type, has the same set of values, and has identical semantics.
新しい型が派生されている場合、Oサブステートメント基本型、定義された型、または暗黙的に派生型（すなわち、ないクラス）を指定する `属性「`タイプが文」は、その型は別の型に置き換えることができます（直接的または間接的に）同じ基本型から、同じ値のセットを有しており、同一の意味を有します。
o In any statement block, a `status' statement value of `current' may be revised as `deprecated' or `obsolete'. Similarly, a `status' statement value of `deprecated' may be revised as `obsolete'. When making such a change, the `description' statement SHOULD be updated to explain the rationale.
O任意のステートメントブロックで、 `ステータス`現在の文の値が「`非推奨」または`時代遅れ」として改訂されてもよいです。同様に、 `状態`廃止予定の声明値は「」 `時代遅れように変更することがあります。このような変更を行う場合には、 `記述」ステートメントは論理的根拠を説明するために更新する必要があります。
o In `typedef' and `attribute' statement blocks, a `default' statement may be added or updated.
O `のtypedef「と`属性」文ブロックでは、 `デフォルトの」ステートメントが追加または更新することができます。
o In `typedef' and `attribute' statement blocks, a `units' statement may be added.
O `のtypedef「と`属性」文ブロックでは、 `台ステートメントを追加してもよいです。
o A class may be augmented by adding new attributes.
Oクラスには、新しい属性を追加することによって拡張することができます。
o In any statement block, clarifications and additional information may be included in the `description' statement.
O任意の命令ブロックは、明確化及び付加情報が '記述」ステートメントに含まれてもよいです。
o In any statement block, a `reference' statement may be added or updated.
任意の命令ブロック中のO、 `リファレンス」ステートメントが追加または更新されてもよいです。
o Entirely new extensions, types, identities, and classes may be defined, using previously unassigned identifiers.
O全く新しい拡張機能、タイプ、アイデンティティ、およびクラスは、以前に割り当てられていない識別子を使用して、定義してもよいです。
Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier. In case of a class where the semantics of any attributes are changed, the new class can be defined by derivation from the old class and refining the changed attributes.
以前の定義のセマンティクスが変更された場合（非編集上の変更は、特に上記許可以外の任意の定義がなされた場合、すなわち、）そうでなければ、これは新しい識別子と新しい定義によって達成されなければなりません。任意の属性のセマンティクスが変更されたクラスの場合は、新しいクラスが古いクラスから派生し、変更された属性を精製して定義することができます。
Note that changing the identifier associated with an existing definition is considered a semantic change, as these strings may be used in an `import' statement.
これらの文字列は `インポート」ステートメントで使用することができるよう、既存の定義に関連付けられた識別子を変更すると、セマンティック変更と見なされることに注意してください。
While the core SMIng language has a well defined set of statements (Section 5 through Section 9.4) that are used to specify those aspects of management information commonly regarded as necessary without management protocol specific information, there may be further information people wish to express. Describing additional information informally in description statements has a disadvantage in that this information cannot be parsed by any program.
コアSMIng言語が共通管理プロトコル固有の情報なしに必要とみなす管理情報のこれらの態様を指定するために使用されるステートメント（セクション9.4を介してセクション5）のよく定義されたセットを有しているが、人が表現したい、さらに情報が存在してもよいです。説明文に非公式に追加の情報を記述すると、この情報は、任意のプログラムで解析することができないという欠点があります。
SMIng allows modules to include statements that are unknown to a parser but fulfil some core grammar rules (Section 4.3). Furthermore, additional statements may be defined by the `extension' statement (Section 6). Extensions can be used in the local module or in other modules that import the extension. This has some advantages:
SMIngは、モジュールは、パーサーに不明であるが、いくつかのコア文法規則（4.3節）を満たす文を含めることができます。さらに、付加的な文は `拡張」文（第6節）によって定義することができます。拡張機能は、ローカルモジュールまたは拡張をインポートする他のモジュールで使用することができます。これは、いくつかの利点があります。
o A parser can differentiate between statements known as extensions and unknown statements. This enables the parser to complain about unknown statements, e.g., due to typos.
Oパーサは、拡張機能や、未知の文として知られている文を区別することができます。これは、タイプミスに不明文、例えば、文句を言うためにパーサを可能にします。
o If an extension's definition contains a formal ABNF grammar definition and a parser is able to interpret this ABNF definition, this enables the parser to also complain about the wrong usage of an extension.
拡張機能の定義が正式なABNF文法の定義とパーサは、このABNFの定義を解釈することができます含まれている場合は、O、これはまた、拡張の誤った使用方法に文句を言うためにパーサを可能にします。
o Since there might be some common need for extensions, there is a relatively high probability of extension name collisions originated by different organizations, as long as there is no standardized extension for that purpose. The requirement to explicitly import extension statements allows those extensions to be distinguished.
機能拡張のためのいくつかの一般的な必要性があるかもしれませんので、O、限り、その目的のための標準化の拡張が存在しないとして、異なる組織によって発信拡張子名の衝突の比較的高い可能性があります。明示的に拡張文をインポートするための要件は、これらの拡張子を区別することができます。
o The supported extensions of an SMIng implementation, e.g., an SMIng module compiler, can be clearly expressed.
SMIng実装のサポート拡張O、例えば、SMIngモジュールコンパイラは、明確に表現することができます。
The only formal effect of an extension statement definition is to declare its existence and status, and optionally its ABNF grammar. All additional aspects SHOULD be described in the `description' statement:
拡張文の定義の唯一の正式な影響は、その存在と状態を宣言し、そのABNF文法を任意にあります。すべての追加の態様は、 `記述」ステートメントに記述する必要があります。
o The detailed semantics of the new statement SHOULD be described.
新しい文の詳細なセマンティクスoを説明するべきです。
o The contexts in which the new statement can be used SHOULD be described, e.g., a new statement may be designed to be used only in the statement block of a module, but not in other nested statement blocks. Others may be applicable in multiple contexts. In addition, the point in the sequence of an obligatory order of other statements, where the new statement may be inserted, might be prescribed.
新しいステートメントを使用することができるコンテキストを記述することO、例えば、新しいステートメントは、モジュールの命令ブロックではなく、他のネストされたステートメントのブロックで使用されるように設計されてもよいです。その他は、複数のコンテキストに適用することができます。また、新しい文が挿入されてもよい他の文の義務順のシーケンスのポイントは、処方されることがあります。
o The circumstances that make the new statement mandatory or optional SHOULD be described.
新しい文が必須またはオプションにする状況が記述されるべきであるO。
o The syntax of the new statement SHOULD at least be described informally, if not supplied formally in an `abnf' statement.
`ABNF」文で正式に供給されていない場合は、O、新たな文の構文は、少なくとも、非公式に記述されるべきです。
o It might be reasonable to give some suggestions under which conditions the implementation of the new statement is adequate and how it could be integrated into existent implementations.
O新しい文の実装が適切であるとどのようにそれが存在しない実装に統合することができた条件の下でいくつかの提案を与えることが合理的であるかもしれません。
Some possible extension applications are:
いくつかの可能な拡張アプリケーションは、次のとおりです。
o The formal mapping of SMIng definitions into the SNMP [RFC3781] framework is defined as an SMIng extension. Other mappings may follow in the future.
SNMP [RFC3781]のフレームワークにSMIng定義の正式なマッピングoをSMIng拡張として定義されます。他のマッピングは、将来的に従うことができます。
o Inlined annotations to definitions. For example, a vendor may wish to describe additional information to class and attribute definitions in private modules. An example are severity levels of events in the statement block of an `event' statement.
Oの定義に注釈をインライン化。例えば、ベンダーがプライベートモジュール内のクラスと属性の定義に追加情報を記述することを望むかもしれません。たとえば `イベント」ステートメントのステートメントブロック内のイベントの重大度レベルです。
o Arbitrary annotations to external definitions. For example, a vendor may wish to describe additional information to definitions in a "standard" module. This allows a vendor to implement "standard" modules as well as additional private features, without redundant module definitions, but on top of "standard" module definitions.
外部定義にO任意の注釈。例えば、ベンダーは、「標準」モジュールの定義に追加情報を記述することを望むかもしれません。これは、ベンダーが冗長モジュール定義せずに、しかし、「標準」モジュール定義の上に、「標準」モジュールだけでなく、追加のプライベートな機能を実装することができます。
This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
この文書では、書き込みと管理情報の記述を読むことで言語を定義します。言語自体は、インターネット上ではセキュリティへの影響はありません。
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]、ジェフケース、キースMcCloghrie、デビッド・パーキンス、マーシャルT.ローズ、ユルゲンSchoenwaelderによって書かれた[RFC2580]から取得されます、そしてスティーブン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.
作者はこのメモ、すなわちハイコDassow、デビッド・ダーラム、キースMcCloghrie、およびバートWijnenの現在の状態に向けた大きな一歩だった2000年9月6-8からシュロスクラインホイバッハで開催された第七NMRG会議の参加者全員に感謝したいと思います。
Furthermore, several discussions within the SMING Working Group reflected experience with SMIv2 and influenced this specification at some points.
さらに、SMINGワーキンググループ内のいくつかの議論がSMIv2の経験を反映して、いくつかの点で、この仕様に影響を与えました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC3216] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J., Strauss, F. and W. Weiss, "SMIng Objectives", RFC 3216, December 2001.
[RFC3216]エリオット、C.、ハリントン、D.、ジェイソン、J.、Schoenwaelder、J.、シュトラウス、F.およびW.ワイス、 "SMIng目的"、RFC 3216、2001年12月。
[RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)", RFC 3781, May 2004.
[RFC3781]シュトラウス、F.およびJ. Schoenwaelder、RFC 3781、2004年5月 "管理情報（SMIng）簡易ネットワーク管理プロトコル（SNMP）へのマッピングの次世代構造"。
[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、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[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のためのテキストの表記法"、STD 59、RFC 2579、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のための適合性宣言"、STD 60、RFC 2580、1999年4月。
[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 ）」、RFC 3159、2001年8月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[RFC1155]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[ASN1] International Organization for Standardization, "Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987.
[ASN1]国際標準化機構、国際標準8824、1987年12月「抽象構文記法1（ASN.1）の仕様」。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、PresuhnとR.とB. Wijnen、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985.
[IEEE754]電気電子技術者協会、「バイナリ浮動小数点演算のためのIEEE規格」、ANSI / IEEE規格754-1985、1985年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning", RFC 3084, March 2001.
[RFC3084]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.およびA.スミスは、「使用をCOPSポリシープロビジョニング」、RFC 3084、2001年3月のため。
Appendix A. NMRG-SMING Module
付録A. NMRG-SMINGモジュール
Most SMIng modules are built on top of the definitions of some commonly used derived types. The definitions of these derived types are contained in the NMRG-SMING module which is defined below. Its derived types are generally applicable for modeling all areas of management information. Among these derived types are counter types, string types, and date and time related types.
ほとんどのSMIngモジュールは、いくつかの一般的に使用される派生型の定義の上に構築されています。これらの派生型の定義は以下に定義されるNMRG-SMINGモジュールに含まれています。その派生型は、一般的に管理情報のすべての領域をモデル化するために適用可能です。これらの派生型の中でカウンタータイプ、文字列型、日付と時刻に関連する種類があります。
This module is derived from RFC 2578 [RFC2578] and RFC 2579 [RFC2579].
このモジュールは、RFC 2578 [RFC2578]及びRFC 2579 [RFC2579]に由来します。
module NMRG-SMING {
モジュールNMRG-SMING {
organization "IRTF Network Management Research Group (NMRG)";
組織「IRTFネットワーク管理研究グループ（NMRG）」。
contact "IRTF Network Management Research Group (NMRG) http://www.ibr.cs.tu-bs.de/projects/nmrg/
接触「IRTFネットワーク管理研究グループ（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
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国際大学ブレーメン私書箱+49 421 200 3587 Eメール：：750 561 28725ブレーメンドイツの電話ボックスj.schoenwaelder@iu-bremen.deを「。
description "Core type definitions for SMIng. Several type definitions are SMIng versions of similar SMIv2 or SPPI definitions.
SMIngの説明「コアタイプ定義。いくつかの型定義は、類似のSMIv2又はSPPI定義のバージョンをSMIngれます。
Copyright (C) The Internet Society (2004).
All Rights Reserved.
This version of this module is part of
RFC 3780, see the RFC itself for full
legal notices.";
revision {
date "2003-12-16";
description "Initial revision, published as RFC 3780.";
};
typedef Gauge32 {
type Unsigned32;
description
"The Gauge32 type represents a non-negative integer,
which may increase or decrease, but shall never
exceed a maximum value, nor fall below a minimum
value. The maximum value can not be greater than
2^32-1 (4294967295 decimal), and the minimum value
can not be smaller than 0. The value of a Gauge32
has its maximum value whenever the information
being modeled is greater than or equal to its
maximum value, and has its minimum value whenever
the information being modeled is smaller than or
equal to its minimum value. If the information
being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
Gauge32 also decreases (increases).";
reference
"RFC 2578, Sections 2. and 7.1.7.";
};
typedef Counter32 { type Unsigned32; description "The Counter32 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^32-1 (4294967295 decimal), when it wraps around and starts increasing again from zero.
typedefのCounter32の{タイプUnsigned32の。説明は「Counter32のタイプは、それがラップアラウンドし、ゼロから再び増加し始めるとき、それは、2 ^ 32-1（4294967295小数）の最大値に達するまで単調に増加する非負の整数を表します。
Counters have no defined `initial' value, and thus, a
single value of a Counter has (in general) no information
content. Discontinuities in the monotonically increasing
value normally occur at re-initialization of the
management system, and at other times as specified in the
description of an attribute using this type. If such
other times can occur, for example, the creation of a
class instance that contains an attribute of type
Counter32 at times other than re-initialization, then a
corresponding attribute should be defined, with an
appropriate type, to indicate the last discontinuity.
Examples of appropriate types include: TimeStamp32,
TimeStamp64, DateAndTime, TimeTicks32 or TimeTicks64
(other types defined in this module).
The value of the access statement for attributes with a type value of Counter32 should be either `readonly' or `eventonly'.
Counter32の種類の値を持つ属性のアクセス文の値は、 `読み取り専用「または` eventonly」のいずれかでなければなりません。
A default statement should not be used for attributes
with a type value of Counter32.";
reference
"RFC 2578, Sections 2. and 7.1.6.";
};
typedef Gauge64 {
type Unsigned64;
description
"The Gauge64 type represents a non-negative integer,
which may increase or decrease, but shall never
exceed a maximum value, nor fall below a minimum
value. The maximum value can not be greater than
2^64-1 (18446744073709551615), and the minimum value
can not be smaller than 0. The value of a Gauge64
has its maximum value whenever the information
being modeled is greater than or equal to its
maximum value, and has its minimum value whenever
the information being modeled is smaller than or
equal to its minimum value. If the information
being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
Gauge64 also decreases (increases).";
};
typedef Counter64 { type Unsigned64; description "The Counter64 type represents a non-negative integer which monotonically increases until it reaches a maximum value of 2^64-1 (18446744073709551615), when it wraps around and starts increasing again from zero.
typedefのCounter64の{タイプUnsigned64に。説明は「Counter64のタイプは、それがラップアラウンドし、ゼロから再び増加し始めるとき、それは、2 ^ 64-1（18446744073709551615）の最大値に達するまで単調に増加する非負の整数を表します。
Counters have no defined `initial' value, and thus, a
single value of a Counter has (in general) no
information content. Discontinuities in the
monotonically increasing value normally occur at
re-initialization of the management system, and at
other times as specified in the description of an
attribute using this type. If such other times can
occur, for example, the creation of a class
instance that contains an attribute of type Counter32
at times other than re-initialization, then
a corresponding attribute should be defined, with an appropriate type, to indicate the last discontinuity.
Examples of appropriate types include: TimeStamp32,
TimeStamp64, DateAndTime, TimeTicks32 or TimeTicks64
(other types defined in this module).
The value of the access statement for attributes with a type value of Counter64 should be either `readonly' or `eventonly'.
Counter64の種類の値を持つ属性のアクセス文の値は、 `読み取り専用「または` eventonly」のいずれかでなければなりません。
A default statement should not be used for attributes
with a type value of Counter64.";
reference
"RFC 2578, Sections 2. and 7.1.10.";
};
typedef Opaque {
type OctetString;
status obsolete;
description
"******* THIS TYPE DEFINITION IS OBSOLETE *******
The Opaque type is provided solely for
backward-compatibility, and shall not be used for
newly-defined attributes and derived types.
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 OctetString, in effect `double-wrapping' the original ASN.1 value.
不透明タイプは、任意のASN.1構文を渡す機能をサポートしています。値はオクテットの列にASN.1基本符号化規則を使用してエンコードされます。これは、今度は、OctetStringに、実質的に `二重包装」オリジナルASN.1値として符号化されます。
Note that a conforming implementation need only be able to accept and recognize opaquely-encoded data. It need not be able to unwrap the data and then interpret its contents.
準拠した実装が唯一受け入れて、不透明でエンコードされたデータを認識することができる必要があることに注意してください。データのラップを解除してから、その内容を解釈することである必要はありません。
A requirement on `standard' modules is that no
attribute may have a type value of Opaque and no
type may be derived from the Opaque type.";
reference
"RFC 2578, Sections 2. and 7.1.9.";
};
typedef IpAddress {
type OctetString (4);
status deprecated;
description
"******* THIS TYPE DEFINITION IS DEPRECATED *******
「*******このタイプの定義は推奨され*******
The IpAddress type represents a 32-bit Internet IPv4 address. It is represented as an OctetString of length 4, in network byte-order.
IPアドレスのタイプは、32ビットインターネットIPv4アドレスを表します。これは、ネットワークバイト順に、長さ4のOctetStringにとして表されます。
Note that the IpAddress type is present for
historical reasons.";
reference
"RFC 2578, Sections 2. and 7.1.5.";
};
typedef TimeTicks32 { type Unsigned32; description "The TimeTicks32 type represents a non-negative integer which represents the time, modulo 2^32 (4294967296 decimal), in hundredths of a second between two epochs. When attributes are defined which use this type, the description of the attribute identifies both of the reference epochs.
typedefをTimeTicks32 {タイプUnsigned32の。説明「TimeTicks32タイプはモジュロ2 ^ 32（4294967296小数）、時間を表す非負整数を表すが、このタイプを使用する属性が定義されている2つのエポックの間の第二の百。で、属性の記述は、両方の識別します参照エポックの。
For example, the TimeStamp32 type (defined in this
module) is based on the TimeTicks32 type.";
reference
"RFC 2578, Sections 2. and 7.1.8.";
};
typedef TimeTicks64 { type Unsigned64; description "The TimeTicks64 type represents a non-negative integer which represents the time, modulo 2^64 (18446744073709551616 decimal), in hundredths of a second between two epochs. When attributes are defined which use this type, the description of the attribute identifies both of the reference epochs.
typedefをTimeTicks64 {タイプUnsigned64に。説明「TimeTicks64タイプはモジュロ2 ^ 64（18446744073709551616 10進数）、時間を表す非負整数を表すが、このタイプを使用する属性が定義されている2つのエポックの間の第二の百。で、属性の記述は、両方の識別します参照エポックの。
For example, the TimeStamp64 type (defined in this
module) is based on the TimeTicks64 type.";
};
typedef TimeStamp32 { type TimeTicks32; description "The value of an associated TimeTicks32 attribute at which a specific occurrence happened. The specific occurrence must be defined in the description of any attribute defined using this type. When the specific occurrence occurred prior to the last time the associated TimeTicks32 attribute was zero, then the TimeStamp32 value is zero. Note that this requires all TimeStamp32 values to be reset to zero when the value of the associated TimeTicks32 attribute reaches 497+ days and wraps around to zero.
typedefをTimeStamp32 {型TimeTicks32。説明は「関連TimeTicks32属性の値は、特定の発生が起こっれる。特定の発生は、このタイプを使用して定義された任意の属性の記述で定義されなければならない。特定の発生が関連TimeTicks32属性がゼロであった最後の時間の前に発生した場合、次いでTimeStamp32値はゼロである。関連TimeTicks32属性の値が497+日に達し、ゼロにラップアラウンドするとき、これはゼロにリセットされるすべてTimeStamp32値を必要とすることに留意されたいです。
The associated TimeTicks32 attribute should be specified
in the description of any attribute using this type.
If no TimeTicks32 attribute has been specified, the
default scalar attribute sysUpTime is used.";
reference
"RFC 2579, Section 2.";
};
typedef TimeStamp64 {
type TimeTicks64;
description
"The value of an associated TimeTicks64 attribute at which
a specific occurrence happened. The specific occurrence
must be defined in the description of any attribute
defined using this type. When the specific occurrence
occurred prior to the last time the associated TimeTicks64
attribute was zero, then the TimeStamp64 value is zero.
The associated TimeTicks64 attribute must be specified in
the description of any attribute using this
type. TimeTicks32 attributes must not be used as
associated attributes.";
};
typedef TimeInterval32 { type Integer32 (0..2147483647); description "A period of time, measured in units of 0.01 seconds.
TimeInterval32 {タイプInteger32の（0 2147483647）のtypedef。説明「0.01秒の単位で測定された時間の期間、。
The TimeInterval32 type uses Integer32 rather than
Unsigned32 for compatibility with RFC 2579.";
reference
"RFC 2579, Section 2.";
};
typedef TimeInterval64 {
type Integer64;
description
"A period of time, measured in units of 0.01 seconds.
Note that negative values are allowed.";
}; typedef DateAndTime {
type OctetString (8 | 11);
default 0x0000000000000000000000;
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
description
"A date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65535
2 3 month 1..12 | 0
3 4 day 1..31 | 0
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes: - the value of year is in big-endian encoding - daylight saving time in New Zealand is +13
*注： - 年の値はビッグエンディアンエンコーディングである - ニュージーランドの夏時間は13です
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:
例えば、1時30分15秒PM EDTで火曜日1992年5月26日は次のように表示されます：
1992-5-26,13:30:15.0,-4:0
１９９２ー５ー２６、１３：３０：１５。０、ー４：０
Note that if only local time is known, then timezone information (fields 8-10) is not present.
唯一のローカル時刻が既知であれば、その後、タイムゾーン情報（フィールド8-10）が存在しないことに留意されたいです。
The two special values of 8 or 11 zero bytes denote an
unknown date-time specification.";
reference
"RFC 2579, Section 2.";
};
typedef TruthValue {
type Enumeration (true(1), false(2));
description
"Represents a boolean value.";
reference
"RFC 2579, Section 2.";
};
typedef PhysAddress {
typedefをPhysAddress {
type OctetString;
format "1x:";
description
"Represents media- or physical-level addresses.";
reference
"RFC 2579, Section 2.";
};
typedef MacAddress {
type OctetString (6);
format "1x:";
description
"Represents an IEEE 802 MAC address represented in the
`canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though
802.5 (in contrast to other 802.x protocols) requires MAC
addresses to be transmitted most significant bit first.";
reference
"RFC 2579, Section 2.";
};
// The DisplayString definition below does not impose a size // restriction and is thus not the same as the DisplayString // definition in RFC 2579. The DisplayString255 definition is // provided for mapping purposes.
// DisplayStringの定義は、以下のサイズ//制限を課さないとDisplayString255定義が//マッピングのために設けられているRFC 2579.にこうしてDisplayStringの//定義と同じではありません。
typedef DisplayString {
type OctetString;
format "1a";
description
"Represents textual information taken from the NVT ASCII
character set, as defined in pages 4, 10-11 of RFC 854.
To summarize RFC 854, the NVT ASCII repertoire specifies:
RFC 854を要約すると、NVT ASCIIのレパートリーを指定します。
- the use of character codes 0-127 (decimal)
- 文字コードの使用0-127（10進数）
- the graphics characters (32-126) are interpreted as US ASCII
- グラフィック文字（32-126）は、米国ASCIIとして解釈されています
- NUL, LF, CR, BEL, BS, HT, VT and FF have the special meanings specified in RFC 854
- NUL、LF、CR、BEL、BS、HT、VTおよびFFは、RFC 854で指定された特別な意味を有します
- the other 25 codes have no standard interpretation
- 他の25個のコードは、標準的な解釈を持っていません
- the sequence 'CR LF' means newline
- シーケンス「CR LF」は改行を意味し、
- the sequence 'CR NUL' means carriage-return
- シーケンス「CR NUL」はキャリッジリターンを意味します
- an 'LF' not preceded by a 'CR' means moving to the same column on the next line.
- 「LF」は次の行の同じ列に移動する「CR」によって先行されません。
- the sequence 'CR x' for any x other than LF or NUL is
illegal. (Note that this also means that a string may
end with either 'CR LF' or 'CR NUL', but not with CR.)
";
};
typedef DisplayString255 { type DisplayString (0..255); description "A DisplayString with a maximum length of 255 characters. Any attribute defined using this syntax may not exceed 255 characters in length.
DisplayString255 {型のDisplayString（0..255）のtypedef。説明「255文字の最大長のDisplayString。この構文を使用して定義された任意の属性は、長さが255文字を超えることはできません。
The DisplayString255 type has the same semantics as the
DisplayString textual convention defined in RFC 2579.";
reference
"RFC 2579, Section 2.";
};
// The Utf8String and Utf8String255 definitions below facilitate // internationalization. The definition is consistent with the // definition of SnmpAdminString in RFC 2571.
//以下UTF8STRINGとUtf8String255定義は//国際化を促進します。定義は、RFC 2571でれるSnmpAdminStringの//定義と一致しています。
typedef Utf8String { type OctetString; format "65535t"; // is there a better way ? description "A human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in RFC 3629.
typedefをUTF8STRING {はタイプOctetString。フォーマット「65535トン」。 //より良い方法はありますか？説明「人間が読み取り可能な文字列は、ISO / IECは、RFC 3629に記載されUTF-8変換フォーマットを使用してオクテット文字列として符号化10646-1文字セット、IS使用して表現しました。
Since additional code points are added by amendments to
the 10646 standard from time to time, implementations must
be prepared to encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not correspond to the
valid UTF-8 encoding of a code point or are outside this
range are prohibited.
The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used.
制御コードの使用は避けるべきです。それは改行を表すために必要である場合、制御コードシーケンスCR LFが使用されるべきです。
The use of leading or trailing white space should be avoided.
ホワイトスペースを先頭または末尾の使用は避けるべきです。
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
直接ユーザ・インターフェース・ハードウェアまたはソフトウェアでサポートされていないコードポイントのために、16進法のような入力と表示の代替手段は、提供されてもよいです。
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
7ビットUS-ASCIIで符号化については、UTF-8エンコーディングは、US-ASCII符号化と同一です。
UTF-8 may require multiple bytes to represent a single
character / code point; thus the length of a Utf8String in
octets may be different from the number of characters
encoded. Similarly, size constraints refer to the number
of encoded octets, not the number of characters
represented by an encoding.";
};
typedef Utf8String255 {
type Utf8String (0..255);
format "255t";
description
"A Utf8String with a maximum length of 255 octets. Note
that the size of an Utf8String is measured in octets, not
characters.";
};
identity null {
description
"An identity used to represent null pointer values.";
};
};
｝；
Appendix B. SMIng ABNF Grammar
付録B. SMIng ABNF文法
The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF) [RFC2234].
SMIng文法は、拡張バッカス・ナウアフォーム（ABNF）[RFC2234]に準拠します。
;;
;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234).
;;
;; @(#) $Id: sming.abnf,v 1.33 2003/10/23 19:31:55 strauss Exp $
;;
;; Copyright (C) The Internet Society (2004). All Rights Reserved.
;;
smingFile = optsep *(moduleStatement optsep)
smingFile = optsep *（moduleStatement optsep）
;; ;; Statement rules.
;; ;;文のルール。
;;
；；
moduleStatement = moduleKeyword sep ucIdentifier optsep "{" stmtsep *(importStatement stmtsep) organizationStatement stmtsep contactStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) 1*(revisionStatement stmtsep) *(extensionStatement stmtsep) *(typedefStatement stmtsep) *(identityStatement stmtsep) *(classStatement stmtsep) "}" optsep ";"
moduleStatement = moduleKeyword 9月ucIdentifier optsep "{" stmtsep *（importStatement stmtsep）organizationStatement stmtsep contactStatement stmtsep descriptionStatement stmtsep * 1（referenceStatement stmtsep）1 *（revisionStatement stmtsep）*（extensionStatement stmtsep）*（typedefStatement stmtsep）*（identityStatementのstmtsep）（* classStatement stmtsep） "}" optsep ";"
extensionStatement = extensionKeyword sep lcIdentifier optsep "{" stmtsep statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) *1(abnfStatement stmtsep) "}" optsep ";"
extensionStatement = extensionKeyword 9月lcIdentifierのoptsep "{" stmtsep statusStatement stmtsep descriptionStatement stmtsep * 1（referenceStatement stmtsep）* 1（abnfStatement stmtsep） "}" optsep ";"
typedefStatement = typedefKeyword sep ucIdentifier optsep "{" stmtsep typedefTypeStatement stmtsep *1(defaultStatement stmtsep) *1(formatStatement stmtsep) *1(unitsStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
typedefStatement = typedefKeyword 9月ucIdentifier optsep "{" stmtsep typedefTypeStatement stmtsep * 1（defaultStatement stmtsep）* 1（formatStatement stmtsep）* 1（unitsStatement stmtsep）statusStatement stmtsep descriptionStatement stmtsep * 1（referenceStatement stmtsep） "}" optsep ";"
identityStatement = identityStmtKeyword sep lcIdentifier optsep "{" stmtsep *1(parentStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
identityStatement = identityStmtKeyword 9月lcIdentifierのoptsep "{" stmtsep * 1（parentStatement stmtsep）statusStatement stmtsep descriptionStatement stmtsep * 1（referenceStatement stmtsep） "}" optsep ";"
classStatement = classKeyword sep ucIdentifier optsep "{" stmtsep *1(extendsStatement stmtsep) *(attributeStatement stmtsep) *1(uniqueStatement stmtsep)
classStatement = classKeyword 9月ucIdentifier optsep "{" stmtsep * 1（extendsStatement stmtsep）*（attributeStatement stmtsep）* 1（uniqueStatementのstmtsep）
*(eventStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
attributeStatement = attributeKeyword sep lcIdentifier optsep "{" stmtsep typeStatement stmtsep *1(accessStatement stmtsep) *1(defaultStatement stmtsep) *1(formatStatement stmtsep) *1(unitsStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
attributeStatement = attributeKeyword 9月lcIdentifierのoptsep "{" stmtsep typeStatement stmtsep * 1（accessStatement stmtsep）* 1（defaultStatement stmtsep）* 1（formatStatement stmtsep）* 1（unitsStatement stmtsep）statusStatement stmtsep descriptionStatement stmtsep * 1（referenceStatement stmtsep） "}" optsep ";"
uniqueStatement = uniqueKeyword optsep "(" optsep qlcIdentifierList optsep ")" optsep ";"
uniqueStatement = uniqueKeyword optsep "（" optsep qlcIdentifierList optsep "）" optsep ";"
eventStatement = eventKeyword sep lcIdentifier optsep "{" stmtsep statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
eventStatement = eventKeywordのSEP lcIdentifierのoptsep "{" stmtsep statusStatement stmtsep descriptionStatement stmtsep * 1（referenceStatement stmtsep） "}" optsep ";"
importStatement = importKeyword sep ucIdentifier optsep "(" optsep identifierList optsep ")" optsep ";"
importStatement = importKeyword 9月ucIdentifier optsep "（" optsep identifierList optsep "）" optsep ";"
revisionStatement = revisionKeyword optsep "{" stmtsep dateStatement stmtsep descriptionStatement stmtsep "}" optsep ";"
revisionStatement = revisionKeyword optsep "{" stmtsep dateStatementのSTMT 9月説明書STMT 9月 "}" optsep ";"
typedefTypeStatement = typeKeyword sep refinedBaseType optsep ";"
typedefTypeStatement = typeKeyword 9月refinedBaseTypeのoptsep ";"
typeStatement = typeKeyword sep (refinedBaseType / refinedType) optsep ";"
typeStatement = typeKeyword 9月（refinedBaseType / refinedType）optsep ";"
parentStatement = parentKeyword sep qlcIdentifier optsep ";"
parentStatement = parentKeyword 9月qlcIdentifierのoptsep ";"
extendsStatement = extendsKeyword sep qucIdentifier optsep ";" dateStatement = dateKeyword sep date optsep ";"
extendsStatement = extendsKeyword 9月qucIdentifierのoptsep ";" dateStatement = dateKeyword 9月の日付optsep ";"
organizationStatement = organizationKeyword sep text optsep ";"
組織の声明=組織キーワード9月テキストオプト9月「;」
contactStatement = contactKeyword sep text optsep ";"
contactStatement = contactKeyword 9月テキストoptsep ";"
formatStatement = formatKeyword sep format optsep ";"
formatStatement = formatKeyword 9月フォーマットoptsep ";"
unitsStatement = unitsKeyword sep units optsep ";"
unitsStatement = unitsKeyword 9月ユニットoptsep ";"
statusStatement = statusKeyword sep status optsep ";"
statusStatement = statusKeyword 9月ステータスoptsep ";"
accessStatement = accessKeyword sep access optsep ";"
accessStatement = accessKeyword 9月のアクセスoptsep ";"
defaultStatement = defaultKeyword sep anyValue optsep ";"
default文=デフォルトのキーワードは任意の値オプト9月の月「;」
descriptionStatement = descriptionKeyword sep text optsep ";"
descriptionStatement = descriptionKeyword 9月テキストoptsep ";"
referenceStatement = referenceKeyword sep text optsep ";"
参照文=リファレンスキーワード9月テキストオプト9月「;」
abnfStatement = abnfKeyword sep text optsep ";"
abnfStatement = abnfKeyword 9月テキストoptsep ";"
;;
;;
;;
refinedBaseType = ObjectIdentifierKeyword / OctetStringKeyword *1(optsep numberSpec) / PointerKeyword *1(optsep pointerSpec) / Integer32Keyword *1(optsep numberSpec) / Unsigned32Keyword *1(optsep numberSpec) / Integer64Keyword *1(optsep numberSpec) / Unsigned64Keyword *1(optsep numberSpec) / Float32Keyword *1(optsep floatSpec) / Float64Keyword *1(optsep floatSpec) / Float128Keyword *1(optsep floatSpec) / EnumerationKeyword optsep namedSignedNumberSpec / BitsKeyword optsep namedNumberSpec
refinedBaseType = ObjectIdentifierKeyword / OctetStringKeyword * 1（numberSpec optsep）/ PointerKeyword * 1 / Integer32Keyword * 1（pointerSpec optsep）/ Unsigned32Keyword * 1 / Integer64Keyword * 1（numberSpec optsep）（numberSpec optsep）/ Unsigned64Keyword * 1（numberSpec optsep）（numberSpec optsep ）/ Float32Keyword * 1（）floatSpec optsep / Float64Keyword * 1（）floatSpec optsep / Float128Keyword * 1（）floatSpec optsep / EnumerationKeyword optsep namedSignedNumberSpec / BitsKeyword optsep namedNumberSpec
refinedType = qucIdentifier *1(optsep anySpec)
refinedType = qucIdentifier * 1（optsep anySpec）
anySpec = pointerSpec / numberSpec / floatSpec
anySpec = pointerSpec / numberSpec / floatSpec
pointerSpec = "(" optsep qlcIdentifier optsep ")" numberSpec = "(" optsep numberElement *furtherNumberElement optsep ")"
pointerSpec = "（" optsep qlcIdentifier optsep "）" numberSpec = "（" optsep numberElement * furtherNumberElementのoptsep "）"
furtherNumberElement = optsep "|" optsep numberElement
furtherNumberElement = optsep "|" optsep numberElement
numberElement = signedNumber *1numberUpperLimit
numberElement = signedNumber * 1numberUpperLimit
numberUpperLimit = optsep ".." optsep signedNumber
numberUpperLimit = optsep ".." optsepのsignedNumber
floatSpec = "(" optsep floatElement *furtherFloatElement optsep ")"
floatSpec = "（" optsep floatElement * furtherFloatElementのoptsep "）"
furtherFloatElement = optsep "|" optsep floatElement
furtherFloatElement = optsep "|" optsep floatElement
floatElement = floatValue *1floatUpperLimit
floatElement =に従ってFloatValue * 1floatUpperLimit
floatUpperLimit = optsep ".." optsep floatValue
floatUpperLimit = optsep ".." に従ってFloatValue optsep
namedNumberSpec = "(" optsep namedNumberList optsep ")"
namedNumberSpec = "（" optsep namedNumberList optsep "）"
namedNumberList = namedNumberItem *(optsep "," optsep namedNumberItem)
namedNumberList = namedNumberItem *（optsep "" namedNumberItem optsep）
namedNumberItem = lcIdentifier optsep "(" optsep number optsep ")"
namedNumberItem = lcIdentifier optsep "（" optsep番号optsep "）"
namedSignedNumberSpec = "(" optsep namedSignedNumberList optsep ")"
namedSignedNumberSpec = "（" optsep namedSignedNumberList optsep "）"
namedSignedNumberList = namedSignedNumberItem *(optsep "," optsep namedSignedNumberItem)
namedSignedNumberList = namedSignedNumberItem *（optsep "" namedSignedNumberItem optsep）
namedSignedNumberItem = lcIdentifier optsep "(" optsep signedNumber optsep ")"
namedSignedNumberItem = lcIdentifier optsep "（" optsep signedNumberのoptsep "）"
identifierList = identifier *(optsep "," optsep identifier)
identifierList識別= *（optsep "" optsepを識別）
qIdentifierList = qIdentifier *(optsep "," optsep qIdentifier)
qIdentifierList = qIdentifier *（optsep "" optsep qIdentifier）
qlcIdentifierList = qlcIdentifier *(optsep "," optsep qlcIdentifier)
qlcIdentifierList = qlcIdentifier *（optsep "" qlcIdentifier optsep）
bitsValue = "(" optsep bitsList optsep ")" bitsList = *1(lcIdentifier *(optsep "," optsep lcIdentifier))
bitsValue = "（" optsep bitsList optsep "）" bitsList = * 1（lcIdentifier *（optsep "" optsepのlcIdentifier））
;;
;; Other basic rules.
;;
identifier = ucIdentifier / lcIdentifier
= ucIdentifier / lcIdentifier識別
qIdentifier = qucIdentifier / qlcIdentifier
qIdentifier = qucIdentifier / qlcIdentifier
ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-")
ucIdentifier = ucAlpha * 63（ALPHA / DIGIT / " - "）
qucIdentifier = *1(ucIdentifier "::") ucIdentifier
qucIdentifier = * 1（ucIdentifier "::"）ucIdentifier
lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-")
lcIdentifier = lcAlpha * 63（ALPHA / DIGIT / " - "）
qlcIdentifier = *1(ucIdentifier "::") lcIdentifier
qlcIdentifier = * 1（ucIdentifier "::"）lcIdentifier
attrIdentifier = lcIdentifier *("." lcIdentifier)
attrIdentifier = lcIdentifier *（ "" lcIdentifier）
qattrIdentifier = *1(ucIdentifier ".") attrIdentifier
qattrIdentifier = * 1（ucIdentifier ""）attrIdentifier
cattrIdentifier = ucIdentifier "." lcIdentifier *("." lcIdentifier)
cattrIdentifier ucIdentifier = "" lcIdentifier *（ "" lcIdentifier）
qcattrIdentifier = qucIdentifier "." lcIdentifier *("." lcIdentifier)
qcattrIdentifier = qucIdentifier "" lcIdentifier *（ "" lcIdentifier）
text = textSegment *(optsep textSegment)
（textSegment optsep）テキスト= textSegment *
textSegment = DQUOTE *textAtom DQUOTE ; See Section 4.2.
textSegment = DQUOTE * textAtom DQUOTE。 4.2節を参照してください。
textAtom = textVChar / HTAB / SP / lineBreak
テキスト= textVChar原子/ HTAB / SP /改行
date = DQUOTE 4DIGIT "-" 2DIGIT "-" 2DIGIT *1(" " 2DIGIT ":" 2DIGIT) DQUOTE ; always in UTC
日付= DQUOTE 4桁 " - " 2DIGIT " - " 2DIGIT * 1（」 "2DIGIT "：" 2DIGIT）DQUOTE。常にUTCで
format = textSegment
フォーマット= textSegment
units = textSegment
単位= textSegment
anyValue = bitsValue / signedNumber / hexadecimalNumber / floatValue / text / objectIdentifier ; Note: `objectIdentifier' includes the ; syntax of enumeration labels and ; identities. ; They are not named literally to ; avoid reduce/reduce conflicts when ; building LR parsers based on this ; grammar.
anyValue = bitsValue / signedNumber / hexadecimalNumber /に従ってFloatValue /テキスト/ objectIdentifier。注意： `objectIdentifier」が含まれます。列挙ラベルの構文と、アイデンティティ。 ;彼らは、文字通りに命名されていません。削減避ける/時に競合を減らします。これに基づいて建物のLRパーサ。文法。
status = currentKeyword / deprecatedKeyword / obsoleteKeyword
ステータス= currentKeyword / deprecatedKeyword / obsoleteKeyword
access = eventonlyKeyword / readonlyKeyword / readwriteKeyword
アクセス= eventonlyKeyword / readonlyKeyword / readwriteKeyword
objectIdentifier = (qlcIdentifier / subid "." subid) *127("." subid)
objectIdentifier =（qlcIdentifier /サブID "" サブID）* 127（ "" サブID）
subid = decimalNumber
サブID =のDecimalNumber
number = hexadecimalNumber / decimalNumber
数=進数/進数
negativeNumber = "-" decimalNumber
負の数=「 - 」進数
signedNumber = number / negativeNumber
符号付き数=数/負の数
decimalNumber = "0" / (nonZeroDigit *DIGIT)
十進数= "0" /（非ゼロの桁* DIGIT）
zeroDecimalNumber = 1*DIGIT
zeroDecimalNumber = 1 * DIGIT
hexadecimalNumber = %x30 %x78 ; "0x" with x only lower-case 1*(HEXDIG HEXDIG)
hexadecimalNumber =％X30％x78。 xは "0X" のみ小文字1 *（HEXDIG HEXDIG）
floatValue = neginfKeyword / posinfKeyword / snanKeyword / qnanKeyword / signedNumber "." zeroDecimalNumber *1("E" ("+"/"-") zeroDecimalNumber)
FloatValue = neginfKeyword / posinfKeyword / snanKeyword / qnanKeyword / signedNumber "" zeroDecimalNumber * 1（ "E"（ "+" / " - "）zeroDecimalNumber）
;; ;; Rules to skip unknown statements ;; with arbitrary arguments and blocks. ;; unknownStatement = unknownKeyword optsep *unknownArgument optsep ";"
;; ;;不明な文をスキップするルール;;任意の引数とブロックと。 ;; unknownStatement = unknownKeyword optsep * unknownArgumentのoptsep ";"
unknownArgument = ("(" optsep unknownList optsep ")") / ("{" optsep *unknownStatement optsep "}") / qucIdentifier / anyValue / anySpec
unknownArgument =（ "（" optsep unknownList optsep "）"）/（ "{" optsep * unknownStatementのoptsep "}"）/ qucIdentifier / anyValue / anySpec
unknownList = namedNumberList / qIdentifierList
unknownList = namedNumberList / qIdentifierList
unknownKeyword = lcIdentifier
未知のキーワード=識別子
;;
;; Keyword rules.
;;
;; Typically, keywords are represented by tokens returned from the
;; lexical analyzer. Note, that the lexer has to be stateful to
;; distinguish keywords from identifiers depending on the context
;; position in the input stream.
;;
moduleKeyword = %x6D %x6F %x64 %x75 %x6C %x65 importKeyword = %x69 %x6D %x70 %x6F %x72 %x74 revisionKeyword = %x72 %x65 %x76 %x69 %x73 %x69 %x6F %x6E dateKeyword = %x64 %x61 %x74 %x65 organizationKeyword = %x6F %x72 %x67 %x61 %x6E %x69 %x7A %x61 %x74 %x69 %x6F %x6E contactKeyword = %x63 %x6F %x6E %x74 %x61 %x63 %x74 descriptionKeyword = %x64 %x65 %x73 %x63 %x72 %x69 %x70 %x74 %x69 %x6F %x6E referenceKeyword = %x72 %x65 %x66 %x65 %x72 %x65 %x6E %x63 %x65 extensionKeyword = %x65 %x78 %x74 %x65 %x6E %x73 %x69 %x6F %x6E typedefKeyword = %x74 %x79 %x70 %x65 %x64 %x65 %x66 typeKeyword = %x74 %x79 %x70 %x65 parentKeyword = %x70 %x61 %x72 %x65 %x6E %x74 identityStmtKeyword = %x69 %x64 %x65 %x6E %x74 %x69 %x74 %x79 classKeyword = %x63 %x6C %x61 %x73 %x73 extendsKeyword = %x65 %x78 %x74 %x65 %x6E %x64 %x73 attributeKeyword = %x61 %x74 %x74 %x72 %x69 %x62 %x75 %x74 %x65 uniqueKeyword = %x75 %x6E %x69 %x71 %x75 %x65 eventKeyword = %x65 %x76 %x65 %x6E %x74 formatKeyword = %x66 %x6F %x72 %x6D %x61 %x74 unitsKeyword = %x75 %x6E %x69 %x74 %x73 statusKeyword = %x73 %x74 %x61 %x74 %x75 %x73 accessKeyword = %x61 %x63 %x63 %x65 %x73 %x73 defaultKeyword = %x64 %x65 %x66 %x61 %x75 %x6C %x74 abnfKeyword = %x61 %x62 %x6E %x66
moduleKeyword =％x6dは％x6F％のx64％X75％x6C％X65 importKeyword =％X69％x6dは％X70％x6F％X72％X74 revisionKeyword =％X72％X65％X76％X69％X73％X69％x6F％x6E dateKeyword =％のx64 ％X61％X74％X65 organizationKeyword =％x6F％X72％X67％X61％x6E％X69％X7A％X61％X74％X69％x6F％x6E contactKeyword =％X63％x6F％x6E％X74％X61％X63％X74 descriptionKeyword = ％のx64％X65％X73％X63％X72％X69％X70％X74％X69％x6F％x6E referenceKeyword =％X72％X65％X66％X65％X72％X65％x6E％X63％X65 extensionKeyword =％X65％x78％X74 ％X65％x6E％X73％X69％x6F％x6E typedefKeyword =％X74％X79％X70％X65％のx64％X65％X66 typeKeyword =％X74％X79％X70％X65 parentKeyword =％X70％X61％X72％X65％x6E ％X74 identityStmtKeyword =％X69％のx64％X65％x6E％X74％X69％X74％X79 classKeyword =％X63％x6C％X61％X73％X73 extendsKeyword =％X65％x78％X74％X65％x6E％のx64％X73 attributeKeyword = ％X61％X74％X74％X72％X69％X62％X75％X74％X65 uniqueKeyword =％X75％x6E％X69％X71％X75％X65 eventKeyword =％X65％X76％X65％x6E％X74 formatKeyword =％X66％x6F ％X72％x6dは％X61％ X74 unitsKeyword =％X75％x6E％X69％X74％X73 statusKeyword =％X73％X74％X61％X74％X75％X73 accessKeyword =％X61％X63％X63％X65％X73％X73 defaultKeyword =％のx64％X65％X66％ X61％X75％x6C％X74 abnfKeyword =％X61％X62％x6E％X66
;; Base type keywords.
;;基本タイプのキーワード。
OctetStringKeyword = %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69 %x6E %x67 PointerKeyword = %x50 %x6F %x69 %x6E %x74 %x65 %x72 ObjectIdentifierKeyword = %x4F %x62 %x6A %x65 %x63 %x74 %x49 %x64 %x65 %x6E %x74 %x69 %x66 %x69 %x65 %x72 Integer32Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x33 %x32 Unsigned32Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33 %x32 Integer64Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34 Unsigned64Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36 %x34 Float32Keyword = %x46 %x6C %x6F %x61 %x74 %x33 %x32 Float64Keyword = %x46 %x6C %x6F %x61 %x74 %x36 %x34 Float128Keyword = %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38 BitsKeyword = %x42 %x69 %x74 %x73 EnumerationKeyword = %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69 %x6F %x6E
OctetStringKeyword =％x4F％X63％X74％X65％X74％X53％X74％X72％X69％x6E％X67 PointerKeyword =％X50％x6F％X69％x6E％X74％X65％X72 ObjectIdentifierKeyword =％x4F％X62％X6A％X65 ％X63％X74％X49％のx64％X65％x6E％X74％X69％X66％X69％X65％X72 Integer32Keyword =％X49％x6E％X74％X65％X67％X65％X72％X33％X32 Unsigned32Keyword =％X55％x6E ％X73％X69％X67％x6E％X65％のx64％X33％X32 Integer64Keyword =％X49％x6E％X74％X65％X67％X65％X72％X36％X34 Unsigned64Keyword =％X55％x6E％X73％X69％X67％x6E ％X65％のx64％X36％X34 Float32Keyword =％X46％x6C％x6F％X61％X74％X33％X32 Float64Keyword =％X46％x6C％x6F％X61％X74％X36％X34 Float128Keyword =％X46％x6C％x6F％X61 ％X74％X31％X32％X38 BitsKeyword =％X42％X69％X74％X73 EnumerationKeyword =％X45％x6E％X75％x6dは％X65％X72％X61％X74％X69％x6F％x6E
;; Status keywords.
;;ステータスのキーワード。
currentKeyword = %x63 %x75 %x72 %x72 %x65 %x6E %x74 deprecatedKeyword = %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65 %x64 obsoleteKeyword = %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65
currentKeyword =％X63％X75％X72％X72％X65％x6E％X74 deprecatedKeyword =％のx64％X65％X70％X72％X65％X63％X61％X74％X65％のx64 obsoleteKeyword =％x6F％X62％X73％x6F％x6C ％X65％X74％X65
;; Access keywords.
;;アクセスキーワード。
eventonlyKeyword = %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79 readonlyKeyword = %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79 readwriteKeyword = %x72 %x65 %x61 %x64 %x77 %x72 %x69 %x74 %x65
eventonlyKeyword =％X65％X76％X65％x6E％X74％x6F％x6E％x6C％X79 readonlyKeyword =％X72％X65％X61％のx64％x6F％x6E％x6C％X79 readwriteKeyword =％X72％X65％X61％のx64％X77 ％X72％X69％X74％X65
;; Special floating point values' keywords.
;;特殊な浮動小数点値キーワード。
neginfKeyword = %x6E %x65 %x67 %x69 %x6E %x66 posinfKeyword = %x70 %x6F %x73 %x69 %x6E %x66 snanKeyword = %x73 %x6E %x61 %x6E qnanKeyword = %x71 %x6E %x61 %x6E
neginfKeyword =％x6E％X65％X67％X69％x6E％X66 posinfKeyword =％X70％x6F％X73％X69％x6E％X66 snanKeyword =％X73％x6E％X61％x6E qnanKeyword =％X71％x6E％X61％x6E
;; ;; Some low level rules. ;; These tokens are typically skipped by the lexical analyzer. ;; sep = 1*(comment / lineBreak / WSP) ; unconditional separator
;; ;;いくつかの低レベルのルール。 ;;これらのトークンは、通常、字句解析によってスキップされます。 ;; 9月= 1 *（コメント/改行/ WSP）。無条件のセパレータ
optsep = *(comment / lineBreak / WSP)
optsep = *（コメント/改行/ WSP）
stmtsep = *(comment / lineBreak / WSP / unknownStatement)
STMT 9月= *（コメント/ラインブレーク/ WSP /未知の声明）
comment = "//" *(WSP / VCHAR) lineBreak
コメント= "//" *（WSP / CHAR）改行
lineBreak = CRLF / LF
改行= CRLF / LF
;;
;; Encoding specific rules.
;;
textVChar = %x21 / %x23-7E ; any VCHAR except DQUOTE
textVChar =％X21 /％x23-7E。 DQUOTE以外の任意のVCHAR
ucAlpha = %x41-5A
ucAlpha =％x41-5A
lcAlpha = %x61-7A
= Kst1-7a％を超えます
nonZeroDigit = %x31-39
nonZeroDigit =％x31-39
;;
;; RFC 2234 core rules.
;;
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
ALPHA =％x41-5A /％x61-7A。 -Z / Z-
CR = %x0D ; carriage return
CR =％x0D。キャリッジリターン
CRLF = CR LF ; Internet standard newline
CRLF = CR LF。インターネット標準の改行
DIGIT = %x30-39 ; 0-9
DIGIT =％x30-39。 0-9
DQUOTE = %x22 ; " (Double Quote)
DQUOTE =％X22。 "（二重引用符）
HEXDIG = DIGIT / %x61 / %x62 / %x63 / %x64 / %x65 / %x66
HEXDIG = DIGIT /％X61 /％X62 / X63％/％のx64 /％X65 /％X66
; only lower-case a..f
;唯一の小文字のA〜F
HTAB = %x09 ; horizontal tab
HTAB =％X09。水平タブ
LF = %x0A ; linefeed
LF =％X0A。改行
SP = %x20 ; space
SP =％のX20。スペース
VCHAR = %x21-7E ; visible (printing) characters
VCHAR =％x21-7E。可視（印刷）文字
WSP = SP / HTAB ; white space
WSP = SP / HTAB;ホワイトスペース
;; End of ABNF
;; ABNFの終わり
Authors' Addresses
著者のアドレス
Frank Strauss TU Braunschweig Muehlenpfordtstrasse 23 38106 Braunschweig Germany
フランク・シュトラウスTUブラウンシュバイクMühlenpfordtstr23 38106ブラウンシュヴァイク、ドイツ
Phone: +49 531 391 3266 EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
電話：+49 531 391 3266 Eメール：strauss@ibr.cs.tu-bs.de URI：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 421 200 3587 Eメール：j.schoenwaelder@iu-bremen.de URI：http://www.eecs.iu-bremen.de/
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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。