[要約] RFC 3780は、SMIng（Next Generation Structure of Management Information）に関する規格であり、MIB（Management Information Base）の構造を改善することを目的としています。SMIngは、SNMP（Simple Network Management Protocol）の管理情報をより効果的に表現するための新しい形式です。
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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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は、管理情報にプロトコルに依存しない表現を提供するデータ定義言語です。個別のRFCは、SNMPを含む特定の管理プロトコルにスミングのマッピングを定義します。
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）は[RFC1155]、[RFC1212]、[RFC1215]、および[RFC2578]、[RFC2579]、および[RFC2580]の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.
同様に、ポリシープロビジョニング情報は、仮想情報ストアに居住するプロビジョニングクラス（PRC）およびプロビジョニングインスタンス（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.
SMIV1とSMIV2は、Simple Network Management Protocol（SNMP）[RFC3411]に結合し、SPPIは一般的なオープンポリシーサービスプロビジョニング（COPS-PR）プロトコル[RFC3084]に結合しています。言語には一般的なルールがありますが、両方のプロトコルで一般的なデータ定義を使用することは困難です。このドキュメントの目的は、特定のプロトコルとアプリケーションに依存しないデータモデルを正式に指定できる一般的なデータ定義言語である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]と互換性のあるスミング定義のSNMP固有マッピングを定義するスミング言語拡張が含まれています。追加の言語拡張機能は、たとえば、SPPI PIBSと互換性のある方法で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.
セクション2では、SMINGを使用したデータモデリングの基本概念の概要を説明しますが、その後のセクションでは、SMING言語の概念を詳細に示します。ベースタイプ、SMINGファイル構造、およびすべての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 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は、1999年に、管理情報ベースの現在のデータモデリング言語であるSMIV2のいくつかの欠点に対処するための研究プロジェクトとして始まりました。主に、ASN.1への部分的な依存性と多くの例外ルールが問題があることが判明しました。2000年に、この作業はIRTFネットワーク管理研究グループに引き渡され、そこで大幅に詳細になりました。COPS-PRとSPPIに関するRAPワーキンググループの作業が1999/200000に出現して以来、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.
新しいデータ定義言語の要件はIETF SMINGワーキンググループ内で数回議論され、時間の経過とともに大幅に変化した[RFC3216]ため、SMIデータ構造（SMI-DS）という名前の別の提案（SMI-DS）が提示されました。ワーキンググループに。最終的に、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.
これらのドキュメント全体で、「スミング」という用語は、このドキュメントで指定されている特定のデータモデリング言語を指しますが、「スミング」という用語は、新しい管理データ定義言語をとして定義するためのIETFワーキンググループ内の一般的な取り組みを指します。SMIV2の後継者であり、おそらく「スミング」と「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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
スミングのベースタイプには、署名済みおよび署名されていない整数、オクテット弦、列挙タイプ、ビットセットタイプ、ポインターが含まれます。ポインターは、クラスインスタンス、クラスインスタンスの属性、または任意のアイデンティティへの参照です。スミングタイプシステムについては、セクション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 ポインターの価値として機能するarbitrary意的な無型アイデンティティの定義、
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],
o スミング拡張機能の定義により、ローカルモジュールまたは他のモジュールが、機械の読み取り可能な表記でベーススミングの範囲を超えた情報を指定できるようにします。SNMPフレームワークでのスミングを適用するためのいくつかの拡張機能は、[RFC3781]で定義されています。
o the definition of information beyond the scope of the base SMIng statements, based on locally defined or imported SMIng extensions.
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:
識別子は、名前でさまざまな種類のスミングアイテムを識別するために使用されます。各識別子は、定義されているスミングアイテムのタイプに依存する名前空間で有効です。
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.
各識別子は、スミングアイテムの種類に依存して、ゼロ以上の文字、数字、およびハイフンが続く上級ケースまたは低ケースの文字から始まります。
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.
外部モジュールの識別子が参照されると、名前の衝突の可能性があります。そのため、同じ識別子を持つ異なるアイテムがインポートされている場合、またはインポートされた識別子がローカルで定義されたアイテムの識別子と衝突した場合、このあいまいさは、それらの識別子にモジュールの名前と名前空間演算子の名前を付けて `:: '、つまり`モジュール:: item '。もちろん、この表記は、名前の衝突がない場合でも識別子を参照するために使用できます。
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.
スミングコア言語キーワードをインポートしてはならないことに注意してください。これらのキーワードのリストについては、付録Bのスミング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 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.1）、数値タイプの範囲制限（セクション3.4からセクション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.
オクテット文字列の値は、二重引用符で囲まれたテキストデータ、または少なくとも2匹の16進数桁の偶数の六次元値として示される任意のバイナリデータとして示される場合があります。。16進数の文字は上のケースである場合がありますが、より低いケースの文字が推奨されます。テキストデータには、タブ文字、スペース、ラインターミネーター文字（NLまたはCR＆NL）など、7ビット表示可能なASCII文字の任意の数（ゼロ）が含まれる場合があります。一部の文字には、特別なエンコーディングが必要です（セクション4.2を参照）。テキストデータには複数の行に及ぶ場合があります。ここでは、最初の行のデータが開始される列までのホワイトスペースのみを含む後続の各行のプレフィックスは、より良いテキストのフォーマットのためにパーサーによってスキップする必要があります。
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.
オクテットストリングベースタイプから（直接的または間接的に）派生した型を定義する場合、オクテットのサイズは、パイプ「|」で区切られたサイズ範囲または明示的なサイズ値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。サイズの範囲は、下限、2つの連続したドット「..」、および上限で構成されています。各値は、小数点または「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
「これはマルチラインテキストデータの例です。」// legal "これは「違法に」引用されている」。//違法な引用「これは\ "法的に\「引用符」です。//法的にエンコードされた引用符「しかし、これも「OK」です。」//法的アポストロフィは "" //法律ゼロ長さ0x123 //違法な奇数六角形長さ0x534d496e670a // legal octet string
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）//リーガルサイズの仕様オクテッツストリング（4）//法律正確なサイズオクターストリング（-1 | 1）//違法ネガティブサイズオクターストリング（5 | 0）//違法な注文オクタストリング（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
null //法律識別名Snmpudpdomain //法的ID名
Restriction Examples:
制限例：
Pointer (snmpTransportDomain) // legal restriction
Pointer（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で使用する管理上割り当てされた名前を表します。このタイプは、プロトコルに依存しないスミングモジュールでは使用しないでください。タイプポインターの属性のSNMPおよびCOPS-PRマッピングで使用することを意図しています（セクション3.2）。
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」のofixadedededecimalで示される場合があります。それらは単一のドットで区切られ、中間の白い空間はありません。代わりに（およびほとんどの場合に優先される）、最初の要素は、静的オブジェクト識別子プレフィックスを表す、以前に定義またはインポートされた低ケース識別子である場合があります。
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
The Integer32 base type represents integer values between -2^31 (-2147483648) and 2^31-1 (2147483647).
integer32ベースタイプは、-2^31（-2147483648）と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のタイプの値は、小数または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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。文字、および括弧内に囲まれたリスト全体。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。各値は、小数点または「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 //違法な16進数長-0xff //六角値の違法な標識0x80000000 //違法な値、大きすぎる0xf00f //法的なhexadecimal値
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ベースタイプは、-2^63（-9223372036854775808）と2^63-1（922372036854775807）の間の整数値を表します。
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のタイプの値は、小数または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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。各値は、小数点または「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 // hex値の違法な標識0x800000 //法的値
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.
of type 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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。各値は、小数点または「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 //違法な六分位価値長さ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.
of sinsigned64の値は、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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。各値は、小数点または「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 //違法な六足数の長さ0x8080000000 //法的な六分子値
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].
float32ベースタイプは、[IEEE754]で説明されているように、単一精度の浮動小数点値を表します。
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の値は、多くのプログラミング言語で知られているように、オプションの指数を持つ10進数として示される場合があります。詳細な構文については、付録Bの文法ルール「FloatValue」を参照してください。特別な値は、「スナン」（シグナリングなし）、「Qnan」（静かではない）、「ネギン」（負の無限）、および「ポジンフ」（ポジティブインフィニティ）です。-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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。複数の値または範囲が与えられている場合、それらはすべてバラバラでなければならず、昇順でなければなりません。値制限が既に制限されているタイプに適用されている場合、新しい制限は、下限を上げ、上限を減らし、明示的な値または範囲を削除するか、中間ギャップを含む複数の範囲に分割することです。特別な値「スナン」、「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のオブジェクトを輸送するプロトコルによって説明する必要があります。また、ほとんどの浮動小数点エンコーディングは、人間の読みやすさのためにスミングで使用される10進数として記述できる多くの値の表現を禁止していることに注意してください。したがって、浮動点タイプの制限の明示的な値は、注意して処理する必要があります。
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 | 0 | 0）//違法なオーバーラップ
The Float64 base type represents floating point values of double precision as described by [IEEE754].
Float64ベースタイプは、[IEEE754]で説明されているように、二重精度の浮動小数点値を表します。
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の値は、多くのプログラミング言語で知られているように、オプションの指数を持つ10進数として示される場合があります。詳細な構文については、付録Bの文法ルール「FloatValue」を参照してください。特別な値は、「スナン」（シグナリングなし）、「Qnan」（静かではない）、「ネギン」（負の無限）、および「ポジンフ」（ポジティブインフィニティ）です。-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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。複数の値または範囲が与えられている場合、それらはすべてバラバラでなければならず、昇順でなければなりません。値制限が既に制限されているタイプに適用されている場合、新しい制限は、下限を上げ、上限を減らし、明示的な値または範囲を削除するか、中間ギャップを含む複数の範囲に分割することです。特別な値「スナン」、「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のオブジェクトを輸送するプロトコルによって説明する必要があります。また、ほとんどの浮動小数点エンコーディングは、人間の読みやすさのためにスミングで使用される10進数として記述できる多くの値の表現を禁止していることに注意してください。したがって、浮動点タイプの制限の明示的な値は、注意して処理する必要があります。
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 | 0 | 0）//違法なオーバーラップ
The Float128 base type represents floating point values of quadruple precision as described by [IEEE754].
float128ベースタイプは、[IEEE754]で説明されているように、四重精度のフローティングポイント値を表します。
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の値は、多くのプログラミング言語で知られているように、オプションの指数を持つ10進数として示される場合があります。詳細な構文については、付録Bの文法ルール「FloatValue」を参照してください。特別な値は、「スナン」（シグナリングなし）、「Qnan」（静かではない）、「ネギン」（負の無限）、および「ポジンフ」（ポジティブインフィニティ）です。-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ベースタイプから（直接的または間接的に）派生した型を定義する場合、可能な値のセットは、パイプ「|」で区切られた範囲または明示的な値のリストを追加することで制限される場合があります。キャラクター、リスト全体が括弧で囲まれています。範囲は、下限、2つの連続したドット「..」、および上限で構成されています。複数の値または範囲が与えられている場合、それらはすべてバラバラでなければならず、昇順でなければなりません。値制限が既に制限されているタイプに適用されている場合、新しい制限は、下限を上げ、上限を減らし、明示的な値または範囲を削除するか、中間ギャップを含む複数の範囲に分割することです。特別な値「スナン」、「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のオブジェクトを輸送するプロトコルによって説明する必要があります。また、ほとんどの浮動小数点エンコーディングは、人間の読みやすさのためにスミングで使用される10進数として記述できる多くの値の表現を禁止していることに注意してください。したがって、浮動点タイプの制限の明示的な値は、注意して処理する必要があります。
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 | 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）の範囲の整数セットからの値を表します。各値には割り当てられた名前があります。それらの指定された数字のリストは、括弧内に囲まれ、「列挙」キーワードに追加されたコンマ区切りされている必要があります。各指名された数値は、括弧内に囲まれた小数または「0x」で埋められた16進数として示される、割り当てられた整数値と、その後に割り当てられた整数値によって示されます。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.
列挙型の値は、小数または「0x」の六十年程度の16進数、またはできれば割り当てられた名前として示される場合があります。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
0 // legal (though not recommended) value up // legal value given by name 2 // legal value given by number
0 //リーガル（推奨されていませんが）価値UP //名前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から始まる小さな整数数で識別されるフラグのセットです。各ビット番号には割り当てられた名前があります。それらの指定された数字のリストは、括弧で囲まれ、「ビット」キーワードに追加されたコンマ区切り、囲まれている必要があります。各指名された数値は、括弧内に囲まれた小数または「0x」で埋められた16進数として示される、割り当てられた整数値と、その後に割り当てられた整数値によって示されます。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.
ビットタイプの値は、小数または `0x'pRefixed六分位数のコンマ分離リスト、または括弧内に囲まれた割り当てられた名前のリストとして示される場合があります。16進数には、少なくとも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.
ビット型から（直接的または間接的に）派生した型を定義する場合、名前の指定された数値を削除することにより、指定された数値のセットを制限することができますが、名前、値、またはその両方に関して名前付き番号を追加または変更することはできません。
Type and Value Examples:
タイプと値の例：
Bits (readable(0), writable(1), executable(2))
Bits (writable(1), readable(0) // illegal order
() // legal empty value
(readable, writable, 2) // legal value
(0, readable, executable) // illegal, readable(0) appears twice
(writable, 4) // illegal, element 4 out of range
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の基礎となるベースタイプがある場合、形式は2つの部分を含む整数形式の仕様で構成されます。最初の部分は、ディスプレイ形式を示唆する単一の文字です。どちらかです。ヘキサデシマルの「x」、小数点の「d」、オクタルの「o」、またはバイナリの「b」。すべてのタイプについて、値をレンダリングするとき、主要なゼロは省略され、負の値については、桁の直前にマイナス標識がレンダリングされます。2番目の部分は常に「x」、「o」、および「b」については省略されており、「d」に存在する必要はありません。存在する場合、2番目の部分はハイフンから始まり、その後10進数が続き、値をレンダリングするときに暗黙の小数点を定義します。たとえば、「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の基礎となるベースタイプがある場合、形式は1つ以上のオクテット形式の仕様で構成されます。各仕様は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. ディスプレイ形式は、次のようになります。16進数の `x '、10進数の場合は` d'、octalの `o '、asciiの場合は` a'、またはutf-8の場合は `t '[rfc3629]。オクテットの長さの部分が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.
一部のタイプでは、形式の仕様は定義されていないことに注意してください。このようなタイプに基づいた派生タイプと属性の場合、形式の仕様を省略する必要があります。実装は、解釈できないフォーマット仕様を無視する必要があります。また、スミング文法（付録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.
スミング情報の一番上のコンテナはファイルです。スミングファイルには、ゼロ、1つ以上のモジュールが含まれる場合があります。可能であれば、モジュールはモジュール名によって個別のファイルに保存することをお勧めします。ただし、専用の目的のために、単一のファイルに複数のモジュールを収集することが合理的かもしれません。
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.
上位レベルのスミングコンストラクトは、単一のスミングモジュールを定義する「モジュール」ステートメント（セクション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.
コメントは、引用された文字列の文字のような単一のトークンの文字の間に除き、スミングファイルの任意の位置に含めることができます。ただし、すべての実質的な説明を適切な説明条項内に配置することをお勧めします。これにより、情報はスミングパーサーが利用できるようにします。
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」、「フォーマット」、および「ユニット」は、テキストの引数を取得します。このテキストは、オクテットストリング値の表現と同様に、二重引用符で囲む必要があります。次の例外的なエンコードルールを持つ任意の文字が含まれる場合があります。
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 new line \ t tab Character \ "二重Quote \\単一のバックスラッシュ
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.
テキストにラインブレークが含まれていて、スミングファイルのレイアウトに応じてテキストをインデントするために使用されるWhitespaceが続いている場合、このプレフィックスホワイトスペースはテキストから剥がされます。
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:
「モジュール」ステートメントは、単一のスミングモジュールのすべての定義のコンテナとして使用されます。2つの引数が取得されます。上部ケースモジュール名と、必須およびオプションのステートメントとステートメントのセクションを義務的な順序で含むステートメントブロック：
module <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>
<Optional Typedefステートメント>
<optional identity statements>
<オプションのIDステートメント>
<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.1）の後に、必須の「組織」（セクション5.2）、「連絡先」（セクション5.3）、および「説明」（セクション5.4）ステートメントとオプションの「参照」ステートメント（セクション5.5が続きます。）、それに続いて、少なくとも1つの必須の「改訂」ステートメント（セクション5.6）が続きます。このポイントまでの部分は、モジュールのメタ情報、つまりモジュール全体を説明するが、最初のインスタンスでアプリケーションで使用されるアイテムを定義しない情報を定義します。モジュールのこの部分には、その主な定義、すなわちスミング拡張（セクション6）、派生タイプ（セクション7）、アイデンティティ（セクション8）、およびクラス（セクション9）が続きます。
See the `moduleStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `module' statement.
「モジュール」ステートメントの正式な構文については、スミング文法（付録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.
「インポート」ステートメントの正式な構文については、スミング文法（付録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.
存在しなければならないモジュールの「組織」ステートメントは、このモジュールが開発された任期の下にある組織のテキストの説明を指定するために使用される1つの引数を取得します。
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.
存在する必要があるモジュールの「連絡先」ステートメントは、このモジュールに関する技術的な質問を送信する人の名前、郵便住所、電話番号、および電子メールアドレスを指定するために使用される1つの引数を取得します。
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.
存在する必要があるモジュールの「説明」ステートメントは、このモジュールの内容の高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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.
存在する必要はないモジュールの「参照」ステートメントは、関連する管理情報を定義する別のモジュール、またはに関連する追加情報を提供する他のドキュメントのいずれかの他のドキュメントのテキスト相互参照を指定するために使用される1つの引数を取得します。このモジュール。
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つの引数を取得します。モジュールには、少なくとも1つの最初の「改訂」ステートメントが必要です。すべての編集上の変更について、すべての改訂が逆の時系列になるように、新しい編集の変更を改訂シーケンスの前に追加する必要があります。
See the `revisionStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `revision' statement.
「改訂」ステートメントの正式な構文については、スミング文法（付録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.
存在しなければならない改訂の「日付」ステートメントは、「yyyymm-dd hh：mm」または「yyyy-mm-dd」という形式で改訂の日付と時刻を指定するために使用される1つの引数を取得します。時間「00:00」。時間は常にUTCで与えられます。
See the `date' rule of the SMIng grammar (Appendix B) for the formal syntax of the revision's `date' statement.
改訂の「日付」ステートメントの正式な構文については、スミング文法（付録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.
存在する必要がある改訂の「説明」ステートメントは、改訂の高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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
Joe L.ユーザー
ACME, Inc. 42 Anywhere Drive Nowhere, CA 95134 USA
Acme、Inc。42どこでも運転する場所、CA 95134 USA
Phone: +1 800 555 0815
EMail: 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.";
著作権（c）The Internet Society（2004）。無断転載を禁じます。このMIBモジュールのこのバージョンはRFC 3780の一部です。法的通知については、RFC自体を参照してください。」;
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へのスミング定義のマッピングについては[RFC3781]については、セクション11を参照してください。これは正式に拡張として定義されています。
See the `extensionStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `extension' statement.
「拡張」ステートメントの正式な構文については、スミング文法（付録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.
存在する必要がある拡張機能の「ステータス」ステートメントは、この拡張定義が最新か履歴であるかを指定するために使用される1つの引数を取得します。値「現在」とは、定義が最新で有効であることを意味します。値「時代遅れ」とは、定義が時代遅れであり、以前に実装された場合は実装されたり、削除したりすることはできません。「非推奨」の値も時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
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.
存在する必要がある拡張機能の「説明」ステートメントは、拡張ステートメントの高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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]文法定義を指定するために使用される1つの引数を取得します。この文法は、コアスミング文法（付録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.
「typedef」ステートメントの正式な構文については、スミング文法（付録B）の「typedefstatement」ルールを参照してください。
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の「タイプ」ステートメントは、このタイプが導出されるタイプを指定するために使用される1つの引数を取得します。オプションで、ベースタイプのルールに従ってサブタイピング情報を追加することにより、タイプ制限を新しいタイプに適用できます。スミングベースタイプとそのタイプの制限については、セクション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の「デフォルト」ステートメントは、このタイプの属性の許容可能なデフォルト値を指定するために使用される1つの引数を取得します。属性インスタンスが作成されたときにデフォルト値を使用できます。つまり、値は実装者にとって「ヒント」です。
The value of the `default' statement must, of course, correspond to the (probably restricted) type specified in the typedef's `type' statement.
もちろん、「デフォルト」ステートメントの値は、Typedefの「タイプ」ステートメントで指定された（おそらく制限されている）タイプに対応する必要があります。
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の「形式」ステートメントは、このタイプの属性のインスタンスの値がどのように表示されるかについてのヒントを与えるために使用される1つの引数を取得します。フォーマット仕様の説明については、セクション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の「単位」ステートメントは、このタイプの属性に関連付けられた単位のテキスト定義を指定するために使用される1つの引数を取得します。
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.
ユニットの仕様は、存在する場合、Typedefの形式仕様に従って表示される値に適している必要があります。たとえば、タイプが数千のHERTZで測定されたタイプのunsigned64の周波数値を定義する場合、形式の仕様は「D-3」でなければならず、単位仕様は「HERTZ」または「HZ」である必要があります。形式の仕様が省略されている場合、ユニットの仕様は「Milli-Hertz」または「MHZ」でなければなりません。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の「ステータス」ステートメントは、このタイプ定義が最新か歴史的かを指定するために使用される1つの引数を取得します。値「現在」とは、定義が最新で有効であることを意味します。値「時代遅れ」とは、定義が時代遅れであり、以前に実装された場合は実装されたり、削除したりすることはできません。「非推奨」の値も時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
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の「説明」ステートメントは、新しく定義されたタイプの高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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の「参照」ステートメントは、関連するタイプ定義を定義する別のモジュール、またはに関連する追加情報を提供する他のドキュメントのいずれかの他のドキュメントに対するテキスト相互参照を指定するために使用される1つの引数を取得します。このタイプ定義。
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つの引数を取得します。最初の引数は低ケースIDの識別子です。2番目の引数は、詳細なID情報を義務的な順序で保持するステートメントブロックです。
See the `identityStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `identity' statement.
「アイデンティティ」ステートメントの正式な構文については、スミング文法（付録B）の「IDSTATEMENT」ルールを参照してください。
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.
アイデンティティの「親」ステートメントは、派生したアイデンティティに対して存在する必要があり、ゼロから定義されたアイデンティティの場合は存在しなければなりません。これは、このアイデンティティが導き出される親のアイデンティティを指定するために使用される1つの引数を取得します。
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.
存在しなければならないアイデンティティの「ステータス」ステートメントは、このアイデンティティの定義が最新か歴史的かを指定するために使用される1つの引数を取得します。値「現在」とは、定義が最新で有効であることを意味します。値「時代遅れ」とは、定義が時代遅れであり、以前に実装された場合は実装されたり、削除したりすることはできません。「非推奨」の値も時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
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.
派生したアイデンティティは、親のアイデンティティが「非推奨」または「時代遅れ」である場合、「現在」として定義されるべきではありません。同様に、親のアイデンティティが「時代遅れ」である場合、それらは「非推奨」として定義されるべきではありません。それにもかかわらず、親のアイデンティティのその後の改訂は避けることはできませんが、ローカルモジュールのその後の改訂で考慮する必要があります。
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.
存在する必要があるIDの「説明」ステートメントは、新たに定義されたアイデンティティの高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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.
存在する必要はないIDの「参照」ステートメントは、関連するID定義を定義する別のモジュール、またはに関連する追加情報を提供する他のドキュメントのいずれかに対するテキストの相互参照を指定するために使用される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つの引数を取得します。最初の引数は、上限クラスの識別子です。2番目の引数は、詳細なクラス情報を義務的な順序で保持するステートメントブロックです。
See the `classStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `class' statement.
「クラス」ステートメントの正式な構文については、スミング文法（付録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.
クラスの「拡張」ステートメントは、親クラスから派生したクラスに存在する必要があり、ゼロから定義されたクラスには存在しない必要があります。これは、このクラスが導き出される親クラスを指定するために使用される1つの引数を取得します。
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.
属性の「タイプ」ステートメントが存在する必要があります。属性のタイプを指定するために使用される少なくとも1つの引数を取得します。タイプ名またはクラス名のいずれかです。タイプ名の場合、セクション3で説明されている制限ルールに従って2番目の引数によって制限される場合があります。
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.
属性の「アクセス」ステートメントは、ベースタイプまたは派生型によって入力された属性に対して存在する必要があり、クラスによって入力された属性には存在しない必要があります。これは、属性のインスタンスを読み取り、および/またはイベントにその価値を含めることが理にかなっているかどうかを指定するために使用される1つの引数を取得します。これは、属性のアクセスの最大レベルです。この最大レベルのアクセスは、管理承認ポリシーとは無関係です。
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.
値「readwrite」は、読み取りと書き込みアクセスが理にかなっていることを示しています。値「readonly」は、読み取りアクセスが理にかなっていることを示しますが、書き込みアクセスは決して不可能です。値「eventonly」は、イベントでのみアクセスできるオブジェクトを示します。
These values are ordered, from least to greatest access level: `eventonly', `readonly', `readwrite'.
これらの値は、「eventonly」、「readonly」、「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.
属性の「デフォルト」ステートメントは、ベースタイプまたは派生型によって入力された属性に対して存在する必要はなく、クラスによって入力された属性には存在しない必要があります。この属性の許容可能なデフォルト値を指定するために使用される1つの引数を取得します。属性インスタンスが作成されたときにデフォルト値を使用できます。つまり、値は実装者にとって「ヒント」です。
The value of the `default' statement must, of course, correspond to the (probably restricted) type specified in the attribute's `type' statement.
もちろん、「デフォルト」ステートメントの値は、属性の「タイプ」ステートメントで指定されている（おそらく制限されている）タイプに対応する必要があります。
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.
属性の「フォーマット」ステートメントは、ベースタイプまたは派生型によって入力された属性に対して存在する必要はなく、クラスによって入力された属性には存在しない必要があります。これは、この属性のインスタンスの値がどのように表示されるかについてのヒントを与えるために使用される1つの引数を取得します。フォーマット仕様の説明については、セクション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.
属性の「ユニット」ステートメントは、ベースタイプまたは派生型によって入力された属性に対して存在する必要はなく、クラスによって入力された属性には存在しない必要があります。この属性に関連付けられた単位のテキスト定義を指定するために使用される1つの引数を取得します。
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.
ユニットの仕様は、存在する場合の属性の形式仕様に従って表示される値に適している必要があります。たとえば、属性が数千のHERTZで測定された型signed64の周波数値を表している場合、形式の仕様は「D-3」でなければならず、ユニット仕様は「HERTZ」または「HZ」でなければなりません。形式の仕様が省略されている場合、ユニットの仕様は「Milli-Hertz」または「MHZ」でなければなりません。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.
属性の「ステータス」ステートメントが存在する必要があります。この属性定義が最新か歴史的かを指定するために使用される1つの引数を取得します。値「現在」とは、定義が最新で有効であることを意味します。値「時代遅れ」とは、定義が時代遅れであり、以前に実装された場合は実装されたり、削除したりすることはできません。「非推奨」の値も時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
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.
存在する必要がある属性の「説明」ステートメントは、この属性の高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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.
存在する必要はないクラス「ユニーク」ステートメントは、括弧で囲まれたこのクラスの属性のコンマ分離されたリストを指定する1つの議論を取得します。存在する場合、この属性のリストは、このクラスのすべての可能なインスタンスの一意の識別を構成します。基礎となるプロトコルのユニークなキーとして使用できます。
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.
「イベント」ステートメントの正式な構文については、スミング文法（付録B）の「EventStatement」ルールを参照してください。
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.
存在する必要があるイベントの「ステータス」ステートメントは、このイベント定義が最新か歴史的かを指定するために使用される1つの引数を取得します。値「現在」とは、定義が最新で有効であることを意味します。値「時代遅れ」とは、定義が時代遅れであり、以前に実装された場合は実装されたり、削除したりすることはできません。「非推奨」の値も時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
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.
存在する必要があるイベントの「説明」ステートメントは、このイベントの高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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.
存在する必要があるクラス「ステータス」ステートメントは、このクラスの定義が最新か歴史的かを指定するために使用される1つの引数を取得します。値「現在」とは、定義が最新で有効であることを意味します。値「時代遅れ」とは、定義が時代遅れであり、以前に実装された場合は実装されたり、削除したりすることはできません。「非推奨」の値も時代遅れの定義を示しますが、古い/既存の実装との相互運用性を促進するために、新しい/継続的な実装を許可します。
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.
存在する必要があるクラス「説明」ステートメントは、新しく定義されたクラスの高レベルのテキスト説明を指定するために使用される1つの引数を取得します。
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.
存在する必要がないクラス「参照」ステートメントは、関連するクラス定義を定義する別のモジュール、または関連する追加情報を提供する他のドキュメントのいずれかのテキスト相互参照を指定するために使用される1つの引数を取得します。このクラスの定義に。
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.";
Event Linkdown {Status Current;説明「リンクダウンイベントは、このインターフェイスインスタンスの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.
コアスミング言語には、管理プロトコル固有の情報なしに一般的に必要と見なされる管理情報の側面を指定するために使用される、明確に定義された一連のステートメント（セクション5からセクション9.4）がありますが、人々が表現したいさらなる情報があるかもしれません。説明ステートメントでは、追加情報を非公式に説明することには、この情報がどのプログラムでも解析できないという点で不利な点があります。
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.
o 拡張機能の定義に正式なABNF文法定義が含まれており、パーサーがこのABNF定義を解釈できる場合、これによりパーサーは拡張機能の誤った使用について文句を言うことができます。
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.
o スミングの実装のサポートされている拡張機能、たとえば、スミングモジュールコンパイラを明確に表現できます。
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.
o 新しいステートメントの構文は、「ABNF」ステートメントで正式に提供されていない場合、少なくとも非公式に説明する必要があります。
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.
o SNMP [RFC3781]フレームワークへのスミング定義の正式なマッピングは、スミング拡張として定義されています。他のマッピングは将来的に続く可能性があります。
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の緊密な後継者として始まって以来、いくつかの段落とフレーズは、Jeff Case、Keith McCloghrie、David Perkins、Marshall T.によって書かれたSMIV2仕様[RFC2578]、[RFC2579]、[RFC2580]から直接取られます。、およびSteven 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.
著者は、2000年9月6日から8日までシュロスクラインハウバッハで開催された第7回NMRG会議のすべての参加者に感謝します。。
Furthermore, several discussions within the SMING Working Group reflected experience with SMIv2 and influenced this specification at some points.
さらに、SMINGワーキンググループ内のいくつかの議論は、SMIV2の経験を反映し、いくつかの点でこの仕様に影響を与えました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D.、ed。および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] Elliott、C.、Harrington、D.、Jason、J.、Schoenwaelder、J.、Strauss、F。and W. Weiss、「Sming Wincongives」、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] Strauss、F。およびJ. Schoenwaelder、「Simple Network Management Protocol（SNMP）への管理情報の次世代構造（SMING）マッピング」、RFC 3781、2004年5月。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 59, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、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.、Perkins、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.、Fine、M.、Seligson、J.、Chan、K.、Hahn、S.、Sahita、R.、Smith、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] Rose、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] Rose、M。およびK. McCloghrie、「Concise MIB Definitions」、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215] Rose、M。、「SNMPで使用するためのトラップを定義するための条約」、RFC 1215、1991年3月。
[ASN1] International Organization for Standardization, "Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987.
[ASN1]国際標準化機関、「抽象的構文表記の仕様（ASN.1）」、国際標準8824、1987年12月。
[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] Harrington、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 Standard 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] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。ポリシープロビジョニングの場合」、RFC 3084、2001年3月。
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.
ほとんどのスミングモジュールは、一般的に使用されるいくつかの派生タイプの定義の上に構築されています。これらの派生タイプの定義は、以下に定義されている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
フランク・シュトラウス・トゥ・ブラウンシュヴァイグ・ムエレンプフォードストラス23 38106ブラウンシュヴァイグ・ドイツ電話：49 531 391 3266電子メール：strauss@ibr.cs.tu-bs.de
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de";
Juergen Schoenwaelder International University Bremen P.O.Box 750 561 28725ブレーメンドイツ電話：49 421 200 3587メール：j.schoenwaelder@iu-bremen.de ";
description "Core type definitions for SMIng. Several type definitions are SMIng versions of similar SMIv2 or SPPI definitions.
説明「スミングのコアタイプ定義。いくつかのタイプ定義は、同様のSMIV2またはSPPI定義のスミングバージョンです。
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.";
著作権（c）The Internet Society（2004）。無断転載を禁じます。このモジュールのこのバージョンはRFC 3780の一部です。完全な法的通知については、RFC自体を参照してください。」;
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 {type unsigned32;説明 "カウンター32タイプは、最大値が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).
カウンターには「初期」値が定義されていないため、カウンターの単一の値には（一般的に）情報コンテンツはありません。単調に増加する値の不連続性は、管理システムの再初期化で通常、このタイプを使用した属性の説明で指定されている場合に発生します。たとえば、そのような他の時間が発生する可能性がある場合、再初期化を示すために、適切なタイプで対応する属性を定義する必要があります。適切なタイプの例には、Timestamp32、Timestamp64、Dateandtime、Timeticks32、またはTimeticks64（このモジュールで定義されている他のタイプ）が含まれます。
The value of the access statement for attributes with a type value of Counter32 should be either `readonly' or `eventonly'.
counter32のタイプ値を持つ属性のアクセスステートメントの値は、「readonly」または「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 {type unsigned64;説明 "Counter64タイプは、最大値が2^64-1（1844674407373709551615）に達するまで単調に増加する非陰性整数を表します。
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).
カウンターには「初期」値が定義されていないため、カウンターの単一の値には（一般的に）情報コンテンツはありません。単調に増加する値の不連続性は、管理システムの再初期化で通常、このタイプを使用した属性の説明で指定されている場合に発生します。たとえば、そのような他の時間が発生する可能性がある場合、再初期化を示すために、適切なタイプで対応する属性を定義する必要があります。適切なタイプの例には、Timestamp32、Timestamp64、Dateandtime、Timeticks32、またはTimeticks64（このモジュールで定義されている他のタイプ）が含まれます。
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の基本エンコードルールを使用してオクテットの文字列にエンコードされます。これは、順番に、オクテットストリングとしてエンコードされ、実際には元の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
typedef iPaddress {type octetString（4）;ステータスが非推奨。説明
"******* 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.
iPaddressタイプは、32ビットのインターネットIPv4アドレスを表します。ネットワークバイトオーダーの長さ4のオクテットストリングとして表されます。
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 {type unsigned32;説明 "Timeticks32タイプは、時間を表す非陰性整数を表します、Modulo 2^32（4294967296小数）、2つのエポックの間の100分の1秒で。参照エポックの。
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 {type unsigned64;説明 "TimeTicks64タイプは、2つのエポックの間の100分の1で、このタイプの両方の属性が定義されている場合、属性を使用する場合、属性を使用する場合、時間を表す、時間を表す非陰性整数を表します。参照エポックの。
For example, the TimeStamp64 type (defined in this module) is based on the TimeTicks64 type."; };
たとえば、Timestamp64タイプ（このモジュールで定義）は、Timeticks64タイプに基づいています。 ";};
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 {Type Timeticks32;説明 "特定の発生が発生した関連するTimeticks32属性の値。このタイプを使用して定義された属性の説明で特定の発生を定義する必要があります。次に、Timestamp32値はゼロになります。これには、関連するTimeticks32属性の値が497日に達し、ゼロにラップすると、すべてのタイムスタンプ32値をゼロにリセットする必要があることに注意してください。
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.
typedef TimeInterval32 {type integer32（0..2147483647）;説明「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:
たとえば、1992年5月26日火曜日午後1時30分15分にEDTが表示されます。
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.
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.
typedef displayString {type octetString;フォーマット "1a";説明 "RFC 854の4、10〜11ページで定義されているように、NVT ASCII文字セットから取得したテキスト情報を表します。
To summarize RFC 854, the NVT ASCII repertoire specifies:
RFC 854を要約すると、NVT ASCIIレパートリーが指定します。
- the use of character codes 0-127 (decimal)
- 文字コードの使用0-127（小数）
- 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」はNewlineを意味します
- 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.) "; };
-LFまたはNUL以外のxのシーケンス「Cr X」は違法です。（これはまた、文字列が「cr lf」または「cr nul」で終わる可能性があることを意味するが、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.
typedef displayString255 {type displayString（0..255）;説明 "最大長さ255文字のディスプレイストリング。この構文を使用して定義されている属性は、長さが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.
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 {type octetString;フォーマット "65535t";//より良い方法はありますか？説明「ISO/IECを使用して表される人間の読み取り可能な文字列は10646-1文字セットで、RFC 3629で説明されているUTF-8変換形式を使用してオクテット文字列としてエンコードされています。
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.
追加のコードポイントは、10646規格の修正により随時追加されるため、0x00000000から0x7ffffffffまでのコードポイントに遭遇するために実装を準備する必要があります。コードポイントの有効なUTF-8エンコードに対応しない、またはこの範囲外にあるバイトシーケンスは禁止されています。
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.
ユーザーインターフェイスハードウェアまたはソフトウェアで直接サポートされていないコードポイントの場合、ヘキサデシマルなどのエントリとディスプレイの代替手段が提供される場合があります。
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."; };
UTF-8は、単一の文字 /コードポイントを表すために複数のバイトを必要とする場合があります。したがって、オクテットのUTF8ストリングの長さは、エンコードされた文字の数とは異なる場合があります。同様に、サイズの制約は、エンコードで表される文字の数ではなく、エンコードされたオクテットの数を指します。 ";};
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."; };
ID null {説明 "nullポインター値を表すために使用されるアイデンティティ。";};
};
};
The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF) [RFC2234].
スミング文法は、増強されたバックスノール形式（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 sep ucidentifier optsep "{" stmtsep *（importStatement stmtsep）gunitiantStatement stmtsep contactStatement stmtsep descriptatement statement stmtsep *1（参照測定stmtsep）1 *（redisedtatementementementementementementementementementementementementementementementementementmen （IDSTATEMENT STMTSEP） *（classStatement stmtsep） "}" optsep ";"
extensionStatement = extensionKeyword sep lcIdentifier optsep "{" stmtsep statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) *1(abnfStatement stmtsep) "}" optsep ";"
extension -statement = extensionKeyword sep lcidentifier optsep "{" stmtsep status -statement stmtsep description 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 ";"
identityStatement = identityStmtKeyword sep lcIdentifier optsep "{" stmtsep *1(parentStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
IDSTATEMENT = IDSTMTKEYWORD SEP LCIDENTIFIER OPTSEP "{" STMTSEP *1（ParentStatement STMTSEP）STATESSTATEMENT STMTSEP説明STMTSEP *1（参照測定STMTSEP） ""} "optsep"; "
classStatement = classKeyword sep ucIdentifier optsep
"{" stmtsep
*1(extendsStatement stmtsep)
*(attributeStatement stmtsep)
*1(uniqueStatement stmtsep)
*(eventStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
*（eventStatement stmtsep）status -statement stmtsep description -statement 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 ";"
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説明stmtsep *1（参照測定stmtsep） "}" optsep ";"
importStatement = importKeyword sep ucIdentifier optsep "(" optsep identifierList optsep ")" optsep ";"
ImportStatement = ImportKeyWord sep ucidentifier optsep "（" optsep識別子リストoptsep "）" optsep ";"
revisionStatement = revisionKeyword optsep "{" stmtsep dateStatement stmtsep descriptionStatement stmtsep "}" optsep ";"
RevisionStatement = RevisionKeyWord OptSep "{" stmtsep DateStatement stmtsep descriptionStatement stmtsep "}" optsep ";"
typedefTypeStatement = typeKeyword sep refinedBaseType optsep ";"
typedeftypestatement = typekeyword sep refinedbaseType optsep ";"
typeStatement = typeKeyword sep (refinedBaseType / refinedType) optsep ";"
TypeStatement = TypeKeyWord SEP（RefinedBaseType / RefinedType）OptSep ";"
parentStatement = parentKeyword sep qlcIdentifier optsep ";"
parentStatement = parentKeyword sep qlcidentifier optsep ";"
extendsStatement = extendsKeyword sep qucIdentifier optsep ";"
dateStatement = dateKeyword sep date optsep ";"
organizationStatement = organizationKeyword sep text optsep ";"
gunitionStatement = guristanykeyword sep text optsep ";"
contactStatement = contactKeyword sep text optsep ";"
contactStatement = ContactKeyWord SEP TEXT OPTSEP ";"
formatStatement = formatKeyword sep format optsep ";"
formatstatement = formatkeyword sep形式optsep ";"
unitsStatement = unitsKeyword sep units optsep ";"
unitsStatement = unitskeyword sep units optsep ";"
statusStatement = statusKeyword sep status optsep ";"
statusStatement = statuseyword sep status optsep ";"
accessStatement = accessKeyword sep access optsep ";"
AccessStatement = AccessKeyWord SEP Access OptSep ";"
defaultStatement = defaultKeyword sep anyValue optsep ";"
defaultStatement = defaultKeyWord sep anyvalue optsep ";"
descriptionStatement = descriptionKeyword sep text optsep ";"
説明Statement =説明KeyWord SEP TEXT OPTSEP ";"
referenceStatement = referenceKeyword sep text optsep ";"
ReferenceStatement = ReferenceKeyWord SEP TEXT OPTSEP ";"
abnfStatement = abnfKeyword sep text optsep ";"
abnfstatement = abnfkeyword sep text 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
refinedType = qucIdentifier *1(optsep anySpec)
anySpec = pointerSpec / numberSpec / floatSpec
pointerSpec = "(" optsep qlcIdentifier optsep ")"
numberSpec = "(" optsep numberElement
*furtherNumberElement
optsep ")"
furtherNumberElement = optsep "|" optsep numberElement
frudernumberelement = 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 *さらなるfloatelement optsep "）"
furtherFloatElement = optsep "|" optsep floatElement
さらにfloatelement = optsep "|"OptSep Floatelement
floatElement = floatValue *1floatUpperLimit
floatelement = floatvalue *1floatupperlimit
floatUpperLimit = optsep ".." optsep floatValue
floatupperlimit = optsep ".." optsep floatvalue
namedNumberSpec = "(" optsep namedNumberList optsep ")"
namednumberspec = "（" optsep namednumberlist optsep "）"
namedNumberList = namedNumberItem *(optsep "," optsep namedNumberItem)
namednumberlist = namednumberitem *（optsep "、" optsep namednumberitem）
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 = namedsignednumbumberitem *（optsep "、" optsep namedsignednumbumberitem）
namedSignedNumberItem = lcIdentifier optsep "(" optsep signedNumber optsep ")"
namedsignednumberitem = lcidentifier optsep "（" optsep signednumber optsep "）"
identifierList = identifier *(optsep "," optsep identifier)
識別子リスト=識別子 *（optsep "、" optsep識別子）
qIdentifierList = qIdentifier *(optsep "," optsep qIdentifier)
QidentifierList = Qidentifier *（optsep "、" optsep qidentifier）
qlcIdentifierList = qlcIdentifier *(optsep "," optsep qlcIdentifier)
qlcidentifierlist = qlcidentifier *（optsep "、" optsep qlcidentifier）
bitsValue = "(" optsep bitsList optsep ")"
bitsList = *1(lcIdentifier
*(optsep "," optsep lcIdentifier))
;;
;; Other basic rules.
;;
identifier = ucIdentifier / lcIdentifier
qIdentifier = qucIdentifier / qlcIdentifier
ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-")
qucIdentifier = *1(ucIdentifier "::") ucIdentifier
lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-")
qlcIdentifier = *1(ucIdentifier "::") lcIdentifier
attrIdentifier = lcIdentifier *("." lcIdentifier)
qattrIdentifier = *1(ucIdentifier ".") attrIdentifier
cattrIdentifier = ucIdentifier "."
lcIdentifier *("." lcIdentifier)
qcattrIdentifier = qucIdentifier "."
lcIdentifier *("." lcIdentifier)
text = textSegment *(optsep textSegment)
text = textsegment *（optsep textsegment）
textSegment = DQUOTE *textAtom DQUOTE ; See Section 4.2.
Textsegment = dquote *textatom dquote;セクション4.2を参照してください。
textAtom = textVChar / HTAB / SP / lineBreak
date = DQUOTE 4DIGIT "-" 2DIGIT "-" 2DIGIT *1(" " 2DIGIT ":" 2DIGIT) DQUOTE ; always in UTC
date = dquote 4digit " - " 2digit " - " 2digit *1（ "" 2digit "：" 2digit）dquote;常にUTCで
format = textSegment
units = 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.
status = currentKeyword / deprecatedKeyword / obsoleteKeyword
status = currentKeyword / deprecatedkeyword / obsoletekeyword
access = eventonlyKeyword / readonlyKeyword / readwriteKeyword
Access = eventOnlyKeyWord / readOnlyKeyword / readwritekeyword
objectIdentifier = (qlcIdentifier / subid "." subid)
*127("." subid)
subid = decimalNumber
number = hexadecimalNumber / decimalNumber
negativeNumber = "-" decimalNumber
負の数字= " - " 10進数
signedNumber = number / negativeNumber
decimalNumber = "0" / (nonZeroDigit *DIGIT)
zeroDecimalNumber = 1*DIGIT
hexadecimalNumber = %x30 %x78 ; "0x" with x only lower-case
1*(HEXDIG HEXDIG)
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 ";"
不明なステートメント=不明キーワードoptsep *nownownedargument optsep ";"
unknownArgument = ("(" optsep unknownList optsep ")") /
("{" optsep *unknownStatement optsep "}") /
qucIdentifier /
anyValue /
anySpec
unknownList = namedNumberList / qIdentifierList
不明list = 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
;; 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
;; 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
;; 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
;; 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
;;
;; Some low level rules.
;; These tokens are typically skipped by the lexical analyzer.
;;
sep = 1*(comment / lineBreak / WSP)
; unconditional separator
optsep = *(comment / lineBreak / WSP)
stmtsep = *(comment /
lineBreak /
WSP /
unknownStatement)
comment = "//" *(WSP / VCHAR) lineBreak
lineBreak = CRLF / LF
;;
;; Encoding specific rules.
;;
textVChar = %x21 / %x23-7E
; any VCHAR except DQUOTE
ucAlpha = %x41-5A
lcAlpha = %x61-7A
nonZeroDigit = %x31-39
;;
;; RFC 2234 core rules.
;;
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
CR = %x0D
; carriage return
CRLF = CR LF ; Internet standard newline
crlf = cr lf;インターネット標準のNewline
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT /
%x61 / %x62 / %x63 / %x64 / %x65 / %x66
; only lower-case a..f
;低ケースa..fのみ
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
SP = %x20
; space
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB ; white space
wsp = sp / htab;空白
;; End of ABNF
;;ABNFの終わり
Authors' Addresses
著者のアドレス
Frank Strauss TU Braunschweig Muehlenpfordtstrasse 23 38106 Braunschweig Germany
フランク・シュトラウス・トゥ・ブラウンシュヴァイグ・ムエレンプフォードストラッシ23 38106ブラウンシュヴァイグドイツ
Phone: +49 531 391 3266
EMail: 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
Juergen Schoenwaelder International University Bremen P.O.ボックス750 561 28725ブレーメンドイツ
Phone: +49 421 200 3587
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。