RFC3780 日本語訳
3780 SMIng - Next Generation Structure of Management Information. F.Strauss, J. Schoenwaelder. May 2004. (Format: TXT=141049 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group F. Strauss
Request for Comments: 3780 TU Braunschweig
Category: Experimental J. Schoenwaelder
International University Bremen
May 2004
ストラウスがコメントのために要求するワーキンググループF.をネットワークでつないでください: 3780年のTUブラウンシュバイクカテゴリ: 大学ブレーメン2004年5月の国際の実験的なJ.Schoenwaelder
SMIng - Next Generation Structure of Management Information
SMIng--経営情報の次世代構造
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
Abstract
要約
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(Management情報、Next Generationの構造)言語を定義します。 SMIngは経営情報のプロトコルから独立している表現を提供するデータ定義言語です。 別々のRFCsはSNMPを含む特定の管理プロトコルとSMIngに関するマッピングを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The History of SMIng . . . . . . . . . . . . . . . . . . 4
1.2. Terms of Requirement Levels. . . . . . . . . . . . . . . 5
2. SMIng Data Modeling. . . . . . . . . . . . . . . . . . . . . . 5
2.1. Identifiers. . . . . . . . . . . . . . . . . . . . . . . 6
3. Base Types and Derived Types . . . . . . . . . . . . . . . . . 7
3.1. OctetString. . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Pointer. . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . 9
3.4. Integer32. . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Integer64. . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 13
3.8. Float32. . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9. Float64. . . . . . . . . . . . . . . . . . . . . . . . . 14
3.10. Float128 . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11. Enumeration. . . . . . . . . . . . . . . . . . . . . . . 17
3.12. Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 SMIng. . . . . . . . . . . . . . . . . . 4 1.2の歴史。 要件レベルの用語。 . . . . . . . . . . . . . . 5 2. SMIngデータのモデル化。 . . . . . . . . . . . . . . . . . . . . . 5 2.1. 識別子。 . . . . . . . . . . . . . . . . . . . . . . 6 3. タイプと派生型. . . . . . . . . . . . . . . . . 7 3.1を基礎づけてください。 OctetString。 . . . . . . . . . . . . . . . . . . . . . . 8 3.2. ポインタ。 . . . . . . . . . . . . . . . . . . . . . . . . 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。 列挙。 . . . . . . . . . . . . . . . . . . . . . . 17 3.12. ビット. . . . . . . . . . . . . . . . . . . . . . . . . . 17
Strauss & Schoenwaelder Experimental [Page 1] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[1ページ]RFC3780SMIng2004年5月
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
3.13. 書式を表示してください。 . . . . . . . . . . . . . . . . . . . . 18 4. SMIngは構造. . . . . . . . . . . . . . . . . . . 20 4.1をファイルします。 コメント. . . . . . . . . . . . . . . . . . . . . . . . 20 4.2。 原文のデータ. . . . . . . . . . . . . . . . . . . . . . 21 4.3。 声明と議論. . . . . . . . . . . . . . . . 21 5。 モジュールStatement. . . . . . . . . . . . . . . . . . . . . 21 5.1。 モジュールの輸入Statement。 . . . . . . . . . . . . . 22 5.2. モジュールの組織Statement。 . . . . . . . . . . 23 5.3. モジュールの接触Statement. . . . . . . . . . . . . 23 5.4。 モジュールの記述Statement. . . . . . . . . . . 23 5.5。 モジュールの参照Statement. . . . . . . . . . . . 23 5.6。 モジュールの改正Statement。 . . . . . . . . . . . . 23 5.6.1. 改正の日付Statement. . . . . . . . . . 24 5.6.2。 改正の記述Statement。 . . . . . . 24 5.7. 使用例。 . . . . . . . . . . . . . . . . . . . . . 24 6. 拡大Statement。 . . . . . . . . . . . . . . . . . . . 25 6.1. 拡大の状態Statement. . . . . . . . . . . . 25 6.2。 拡大の記述Statement。 . . . . . . . . . 26 6.3. 拡大の参照Statement。 . . . . . . . . . . 26 6.4. 拡大のabnf Statement. . . . . . . . . . . . . 26 6.5。 使用例。 . . . . . . . . . . . . . . . . . . . . . 26 7. typedef Statement。 . . . . . . . . . . . . . . . . . . . . 27 7.1. typedefのタイプStatement. . . . . . . . . . . . . . 27 7.2。 typedefのデフォルトStatement。 . . . . . . . . . . . . 27 7.3. typedefの形式Statement. . . . . . . . . . . . . 27 7.4。 typedefのユニットStatement。 . . . . . . . . . . . . . 28 7.5. typedefの状態Statement. . . . . . . . . . . . . 28 7.6。 typedefの記述Statement。 . . . . . . . . . . 29 7.7. typedefの参照Statement。 . . . . . . . . . . . 29 7.8. 使用例. . . . . . . . . . . . . . . . . . . . . 29 8。 アイデンティティStatement. . . . . . . . . . . . . . . . . . . . 30 8.1。 アイデンティティの親Statement。 . . . . . . . . . . . . 30 8.2. アイデンティティの状態Statement。 . . . . . . . . . . . . 30 8.3. 'アイデンティティ'記述Statement。 . . . . . . . . . . 31 8.4. アイデンティティの参照Statement. . . . . . . . . . . 31 8.5。 使用例. . . . . . . . . . . . . . . . . . . . . 31 9。 クラスStatement。 . . . . . . . . . . . . . . . . . . . . . 32 9.1. クラスのものはStatement. . . . . . . . . . . . . . 32 9.2を広げています。 クラスの属性Statement. . . . . . . . . . . . . 32 9.2.1。 属性のタイプStatement。 . . . . . . . . . 32 9.2.2. 属性のアクセスStatement。 . . . . . . . . 32 9.2.3. 属性のデフォルトStatement. . . . . . . . 33 9.2.4。 属性の形式Statement。 . . . . . . . . 33 9.2.5. 属性のユニットStatement. . . . . . . . . 33 9.2.6。 属性の状態Statement。 . . . . . . . . 34 9.2.7. 属性の記述Statement. . . . . . 34 9.2.8。 属性の参照Statement. . . . . . . 34 9.3。 クラスのユニークなStatement。 . . . . . . . . . . . . . . 35
Strauss & Schoenwaelder Experimental [Page 2] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[2ページ]RFC3780SMIng2004年5月
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
9.4. クラスの出来事Statement. . . . . . . . . . . . . . . 35 9.4.1。 出来事の状態Statement。 . . . . . . . . . . 35 9.4.2. 出来事の記述Statement. . . . . . . . 35 9.4.3。 出来事の参照Statement. . . . . . . . . 36 9.5。 クラスの状態Statement。 . . . . . . . . . . . . . . 36 9.6. クラスの記述Statement. . . . . . . . . . . . 36 9.7。 クラスの参照Statement. . . . . . . . . . . . . 37 9.8。 使用例。 . . . . . . . . . . . . . . . . . . . . . 37 10. モジュール. . . . . . . . . . . . . . . . . . . . . . 38 11を広げています。 SMIng言語伸展性. . . . . . . . . . . . . . . . . 39 12。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 41 13. 承認. . . . . . . . . . . . . . . . . . . . . . . 41 14。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.1。 引用規格. . . . . . . . . . . . . . . . . . 42 14.2。 有益な参照. . . . . . . . . . . . . . . . . 42付録A.NMRG-SMINGモジュール. . . . . . . . . . . . . . . . . . 44付録B.SMIng ABNF文法53………………作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 63の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 64
1. Introduction
1. 序論
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].
伝統的なマネージメントシステムでは、仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連する物の収集はMIBモジュールで定義されます。 これらのモジュールは仕様言語、Management情報のStructure(SMI)との順応に書かれています。 SMIの異なった見解があります。 SMIバージョン1(SMIv1)は[RFC2578]、[RFC2579]、および[RFC2580]の[RFC1155]、[RFC1212]、[RFC1215]、およびSMIバージョン2(SMIv2)で定義されます。 両方がOSIの抽象的なSyntax Notation One、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.
Policy Information基地(PIB)は、同様に、情報に食糧を供給する方針が仮想情報店に住みながらProvisioning Classes(PRCs)とProvisioning Instances(PRIs)の収集として見なされると呼びました。 関連するProvisioning Classesの収集はPIBモジュールで定義されます。 PIBモジュールは、SMIv2の適合している部分集合であるPolicy Provisioning情報(SPPI)[RFC3159]のStructureを使用することで書かれています。
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
SMIv1とSMIv2はSimple Network Managementプロトコル(SNMP)[RFC3411]に縛られます、SPPIがCommonオープンPolicy Service Provisioning(COPS-PR)プロトコル[RFC3084]に縛られますが。 言語には、共通規則がありますが、両方のプロトコルによる一般的なデータ定義を使用しにくいです。 一般的なSMIngというそうすることができるデータ定義言語を定義するのは、このドキュメントの目的です。
Strauss & Schoenwaelder Experimental [Page 3] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[3ページ]RFC3780SMIng2004年5月
formally specify data models independent of specific protocols and applications. The appendix of this document defines a core module that supplies common SMIng definitions.
特定のプロトコルとアプリケーションの如何にかかわらず正式にデータモデルを指定してください。 このドキュメントの付録は一般的なSMIng定義を供給するコアモジュールを定義します。
A companion document contains an SMIng language extension to define SNMP specific mappings of SMIng definitions in compatibility with SMIv2 MIB modules [RFC3781]. Additional language extensions may be added in the future, e.g., to define COPS-PR specific mappings of SMIng definitions in a way that is compatible with SPPI PIBs.
仲間ドキュメントはSMIv2 MIBモジュール[RFC3781]との互換性とのSMIng定義のSNMPの特定のマッピングを定義するSMIng言語拡張を含んでいます。 追加言語拡張は、将来、例えばSPPI 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の文法を含んでいます。
1.1. The History of SMIng
1.1. SMIngの歴史
SMIng started in 1999 as a research project to address some drawbacks of SMIv2, the current data modeling language for management information bases. Primarily, its partial dependence on ASN.1 and a number of exception rules turned out to be problematic. In 2000, the work was handed over to the IRTF Network Management Research Group where it was significantly detailed. Since the work of the RAP Working Group on COPS-PR and SPPI emerged in 1999/2000, SMIng was split into two parts: a core data definition language (defined in this document) and protocol mappings to allow the application of core definitions through (potentially) multiple management protocols. The replacement of SMIv2 and SPPI by a single merged data definition language was also a primary goal of the IETF SMING Working Group that was chartered at the end of 2000.
SMIngは研究計画としての1999年にSMIv2(管理情報ベースのための現在のデータのモデル化言語)のいくつかの欠点を記述し始めました。 主として、ASN.1への部分的な依存と多くの例外の原則が問題が多いと判明しました。 2000年に、仕事はそれがかなり詳細であったIRTF Network Management Research Groupに引き渡されました。 COPS-PRとSPPIへのRAP作業部会の作業が1999/2000で現れたので、SMIngは2つの部品に分割されました: コアデータ定義言語(本書では定義される)と(潜在的に)複数の管理プロトコルにコア定義の応用の通ることを許すプロトコルマッピング。 また、ただ一つの合併しているデータ定義言語によるSMIv2とSPPIの交換は2000年の終わりでチャーターされたIETF SMING作業部会の第一の目標でした。
The requirements for a new data definition language were discussed several times within the IETF SMING Working Group and changed significantly over time [RFC3216], so that another proposal (in addition to SMIng), named SMI Data Structures (SMI-DS), was presented to the Working Group. In the end, neither of the two proposals found enough consensus and support, and the attempt to merge the existing concepts did not succeed, resulting in the Working Group being closed down in April 2003.
新しいデータ定義言語のための要件は、IETF SMING作業部会の中で何度か議論して、時間[RFC3216]をかなり切り替えました、SMI Data Structures(SMI-DS)という別の提案(SMIngに加えた)が作業部会に提示されたように。 結局、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.
NMRG(ネットワークManagement Research Group)のSMIngへの作業を記録して、[RFC3781]を写像するSNMPプロトコルのこのメモと付随のメモは情報の目的のために発表されました。
Strauss & Schoenwaelder Experimental [Page 4] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[4ページ]RFC3780SMIng2004年5月
Note that throughout these documents, the term "SMIng" refers to the specific data modeling language that is specified in this document, whereas the term "SMING" refers to the general effort within the IETF Working Group to define a new management data definition language as an SMIv2 successor and probably an SPPI merger, for which "SMIng" and "SMI-DS" were two specific proposals.
これらのドキュメント中では、"SMIng"という用語が"SMING"という用語が新しい管理データ定義言語をSMIv2後継者と定義するためのIETF作業部会の中の一般的な努力とたぶん"SMIng"と「SMI-DS」が2つの明確な提案であったSPPI合併について言及しますが、本書では指定される特定のデータのモデル化言語を示すことに注意してください。
1.2. Terms of Requirement Levels
1.2. 要件レベルの用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. SMIng Data Modeling
2. SMIngデータのモデル化
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.
各クラスには、多くの属性があります。 各属性はベースタイプ、ベースタイプのサブタイプ、またはもう1人のクラスの原子情報を表します。 属性の概念はセクション9.2で説明されます。
The base types of SMIng include signed and unsigned integers, octet strings, enumeration types, bitset types, and pointers. Pointers are references to class instances, attributes of class instances, or arbitrary identities. The SMIng type system is described in Section 3.
SMIngのベースタイプはサインされるのと符号のない整数、八重奏ストリング、列挙タイプ、bitsetタイプ、およびポインタを入れます。 ポインタは、クラス例の参照、クラス例の属性、または任意のアイデンティティです。 SMIngタイプシステムはセクション3で説明されます。
Related class and type definitions are defined in modules. A module may refer to definitions from other modules by importing identifiers from those modules. Each module may serve one or multiple purposes:
関連クラスと型定義はモジュールで定義されます。 それらのモジュールから識別子を輸入することによって、モジュールは他のモジュールから定義について言及するかもしれません。 各モジュールは1か複数の目的に役立つかもしれません:
o the definition of management classes,
o 管理の定義は属します。
o the definition of events,
o 出来事の定義
o the definition of derived types,
o 派生型の定義
o the definition of arbitrary untyped identities serving as values
of pointers,
o 任意の定義はポインタの値として機能するアイデンティティを非タイプしました。
Strauss & Schoenwaelder Experimental [Page 5] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[5ページ]RFC3780SMIng2004年5月
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 地方にモジュールを許容するか、またはマシンのベースSMIngの範囲を超えて情報を指定する他のモジュールに読み込み可能な記法を許容するSMIng拡張子の定義。 SNMP枠組みにおける、SMIngのアプリケーションのためのいくつかの拡大が[RFC3781]で定義されます。
o the definition of information beyond the scope of the base SMIng
statements, based on locally defined or imported SMIng extensions.
o 局所的に定義されたか、または輸入されたSMIng拡張子に基づいたベースSMIng声明の範囲を超えた情報の定義。
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.
各モジュールは大文字識別子によって特定されます。 すべての標準のモジュールの名前はユニークであるに違いありません(同じモジュールの異なった見解には、同じ名前があるべきです)。 企業モジュールの開発者が標準の、または、他の企業モジュールと衝突するという低い確率を持っているそれらのモジュールのための名前を選ぶよう奨励されます、例えば、接頭語として企業か組織名を使用することによって。
2.1. Identifiers
2.1. 識別子
Identifiers are used to identify different kinds of SMIng items by name. Each identifier is valid in a namespace which depends on the type of the SMIng item being defined:
識別子は、異種の名前のSMIngの品目を特定するのに使用されます。 それぞれの識別子は定義されるSMIngの品目のタイプに頼る名前空間で有効です:
o The global namespace contains all module identifiers.
o グローバルな名前空間はすべてのモジュール識別子を含んでいます。
o Each module defines a new namespace. A module's namespace may
contain definitions of extension identifiers, derived type
identifiers, identity identifiers, and class identifiers.
Furthermore, a module may import identifiers of these kinds from
other modules. All these identifiers are also visible within all
inner namespaces of the module.
o 各モジュールは新しい名前空間を定義します。 モジュールの名前空間は拡大識別子、派生型識別子、アイデンティティ識別子、およびクラス識別子の定義を含むかもしれません。 その上、モジュールは他のモジュールからこれらの種類に関する識別子を意味するかもしれません。 また、これらのすべての識別子もモジュールのすべての内側の名前空間の中で目に見えます。
o Each class within a module defines a new namespace. A class'
namespace may contain definitions of attribute identifiers and
event identifiers.
o モジュールの中の各クラスは新しい名前空間を定義します。 クラスの名前空間は属性識別子と事象IDの定義を含むかもしれません。
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 それぞれの列挙タイプとbitsetタイプは命名された番号の新しい名前空間を定義します。 数というこれらは換算値の各表現、例えば、デフォルト値とサブタイプ制限で目に見えます。
o Extensions may define additional namespaces and have additional
rules of other namespaces' visibility.
o 拡大は、追加名前空間を定義して、他の名前空間の目に見えることの付則を持っているかもしれません。
Within every namespace each identifier MUST be unique.
あらゆる名前空間の中では、それぞれの識別子はユニークであるに違いありません。
Strauss & Schoenwaelder Experimental [Page 6] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[6ページ]RFC3780SMIng2004年5月
Each identifier starts with an upper-case or lower-case character, dependent on the kind of SMIng item, followed by zero or more letters, digits, and hyphens.
各識別子は大文字か小文字から始まります、ゼロがあとに続いたSMIngの品目か、より多くの手紙と、ケタと、ハイフンの種類に依存しています。
All identifiers defined in a namespace MUST be unique and SHOULD NOT only differ in case. Identifiers MUST NOT exceed 64 characters in length. Furthermore, the set of all identifiers defined in all modules of a single standardization body or organization SHOULD be unique and mnemonic. This promotes a common language for humans to use when discussing a module.
名前空間で定義されたすべての識別子がユニークであるに違いありません、そして、SHOULD NOTは場合において異なるだけです。 識別子は長さで64のキャラクタを超えてはいけません。 その上、すべての識別子のセットは単一の標準化本体か組織のすべてのモジュールでSHOULDを定義しました。ユニークであって、簡略記憶になってください。 これはモジュールについて議論するとき人間が使用する共通語を促進します。
To reference an item that is defined in the local module, its definition MUST sequentially precede the reference. Thus, there MUST NOT be any forward references.
ローカルのモジュール、定義で定義される項目がそうしなければならない参照に、参照に連続して先行してください。 したがって、少しの前進の参照もあるはずがありません。
To reference an item that is defined in an external module it MUST be imported (Section 5.1). Identifiers that are neither defined nor imported MUST NOT be visible in the local module.
参照への輸入していて、それがそうしなければならない外部のモジュール(セクション5.1)で定義される項目。 定義されないで、また輸入されない識別子はローカルのモジュールで目に見えるはずがありません。
When identifiers from external modules are referenced, there is the possibility of name collisions. As such, if different items with the same identifier are imported or if imported identifiers collide with identifiers of locally defined items, then this ambiguity is resolved by prefixing those identifiers with the names of their modules and the namespace operator `::', i.e., `Module::item'. Of course, this notation can be used to refer to identifiers even when there is no name collision.
外部のモジュールからの識別子が参照をつけられるとき、名前衝突の可能性があります。 '同じ識別子がある異なった項目が意味されているか、または輸入された識別子が局所的に被定義項目に関する識別子と衝突するなら、そういうものとして、このあいまいさはそれらのモジュールの名前と名前空間オペレータがいるそれらの識別子を前に置くことによって、取り除かれている':、:'、すなわち、'モジュール:、:、''項目'。 もちろん、名前衝突全くないときさえ、識別子を示すのにこの記法を使用できます。
Note that SMIng core language keywords MUST NOT be imported. See the `...Keyword' rules of the SMIng ABNF grammar in Appendix B for a list of those keywords.
SMIngコア言語キーワードを輸入してはいけないことに注意してください。 '見てください、'…それらのキーワードのリストのためのAppendix BのSMIng ABNF文法の'キーワード'規則。
3. Base Types and Derived Types
3. 基地のタイプと派生型
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には、1セットのベースタイプがあります、多くのプログラミング言語のものと同様ですが、いくつかで、経営情報からの特別な要件による違いはモデル化されます。
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].
追加タイプは定義されるか、それらのベースタイプから派生するか、または他の派生型から来ているかもしれません。 派生型は、正式に可能な値のセットを制限するのに副タイプを使用するかもしれません。 1人の始発の一般的に使用された派生型はSMIngの標準のモジュールNMRG-SMING[RFC3781]で定義されます。
The different base types and their derived types allow different kinds of subtyping, namely size restrictions of octet strings (Section 3.1), range restrictions of numeric types (Section 3.4
異なったベースはタイプされます、そして、彼らの派生型は異種の副タイプ、すなわち、八重奏ストリングのサイズ制限(セクション3.1)を許します、数値型の範囲制限、(セクション3.4
Strauss & Schoenwaelder Experimental [Page 7] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[7ページ]RFC3780SMIng2004年5月
through Section 3.10), restricted pointer types (Section 3.2), and restrictions on the sets of named numbers for enumeration types (Section 3.11) and bit sets (Section 3.12).
通じて、セクション3.10) 制限されたポインタは(セクション3.2)をタイプして、列挙タイプ(セクション3.11)の命名された数のセットにおける制限とビットは(セクション3.12)を設定します。
3.1. OctetString
3.1. OctetString
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ベースタイプは任意の2進の、または、原文のデータを表します。 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進のデータが'0x'として指示したように原文の同封のデータが少なくとも2つの16進数字の偶数の16進値を前に置いたので、八重奏ストリングの値は指示されるかもしれません。そこでは、それぞれの組の16進数字がただ一つの八重奏を表します。 16進値における文字は大文字であるかもしれませんが、下側のケースキャラクタはRECOMMENDEDです。 原文のデータはどんな7ビットの表示可能ASCII文字のどんな数(ことによるとゼロ)も含むかもしれません、タブキャラクタ、空間、および線ターミネータキャラクタ(nlかcrとnl)を含んでいて。 キャラクタの中には特別なコード化を必要とする(セクション4.2を見てください)人もいます。 原文のデータは複数の線にかかるかもしれなくて、それぞれのその後の線接頭語含有がスペースを最初の行データがSHOULDを始動するコラムまで空白にするだけであるところで、より良いテキスト形式のためにパーサによってスキップされてください。
When defining a type derived (directly or indirectly) from the OctetString base type, the size in octets may be restricted by appending a list of size ranges or explicit size values, separated by pipe `|' characters, with the whole list enclosed in parenthesis. A size range consists of a lower bound, two consecutive dots `..', and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number of at least two digits. Size restricting values MUST NOT be negative. If multiple values or ranges are given, they all MUST be disjoint and MUST be in ascending order. If a size restriction is applied to an already size restricted octet string, the new restriction MUST be equal or more limiting, that is, raising the lower bounds, reducing the upper bounds, removing explicit size values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
'OctetStringベースタイプから引き出された(直接か間接的に)タイプを定義するとき、八重奏におけるサイズは、パイプ‘によって切り離されたサイズ範囲か明白なサイズ値のリストを追加することによって、制限されるかもしれません。|'全体のリストが挿入句に同封されているキャラクタ'。 'サイズ範囲は下界、2つの連続したドットから成ります'。'上限' 小数か'0x'前に置かれた16進法で各値を与えることができます。 16進数には、少なくとも2ケタの偶数がなければなりません。 値を制限するサイズは負であるはずがありません。 複数の値か範囲を与えるなら、それらは皆、ばらばらになることでなければならなく、昇順であるに違いありません。 サイズ制限が既にサイズ部外秘な八重奏ストリングに適用されるなら、新しい制限が等しいに違いありませんか、または、より多くの制限、すなわち、明白なサイズ値か範囲を取り除いて、上限を減少させて、下界を上げるか、または分かれることが中間的ギャップで複数の範囲に及びます。
Strauss & Schoenwaelder Experimental [Page 8] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[8ページ]RFC3780SMIng2004年5月
Value Examples:
例を評価してください:
"This is a multiline
textual data example." // legal
"This is "illegally" quoted." // illegal quotes
"This is \"legally\" quoted." // legally encoded quotes
"But this is 'ok', as well." // legal apostrophe quoting
"" // legal zero length
0x123 // illegal odd hex length
0x534d496e670a // legal octet string
「これはマルチラインの原文のデータの例です。」 //「これは「不法に」引用されます」法的な。 引用された「法的に「これは\である」という//不法な引用文の\」、」 「しかし、また、'OKに'と、これはそうです」という法的に//コード化された引用文。 //法的なアポストロフィ引用、「「//法的なゼロ・レングス0×123//不法な変な十六進法長さ0x534d496e670a//の法的な八重奏ストリング」
Restriction Examples:
制限の例:
OctetString (0 | 4..255) // legal size spec
OctetString (4) // legal exact size
OctetString (-1 | 1) // illegal negative size
OctetString (5 | 0) // illegal ordering
OctetString (1 | 1..10) // illegal overlapping
OctetString、(0|4. .255)//法的なサイズ仕様OctetString(4)//法的な実寸OctetString、(-1|1、)、//不法な否定的サイズOctetString(5|0)//不法な注文OctetString、(1|1. .10)//不法な重なること。
3.2. Pointer
3.2. ポインタ
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.
タイプが表すPointerベースはその参照クラス例、クラス例の属性、または任意のアイデンティティを評価します。 Pointerタイプの唯一のモジュールで存在する場合がある値がアイデンティティについて言及できます。 それらは関係があるアイデンティティに関する識別子として指示されます。
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.
Pointerベースタイプから引き出された(直接か間接的に)タイプを定義するとき、値は特定のクラス、属性またはアイデンティティに制限されたかもしれません、そして、すべて(直接か間接的である)が挿入句に同封された適切な構造物に関する識別子を追加することによって、それの項目を引き出しました。
Value Examples:
例を評価してください:
null // legal identity name
snmpUDPDomain // legal identity name
ヌル//法的なアイデンティティ名前snmpUDPDomain//法的なアイデンティティ名
Restriction Examples:
制限の例:
Pointer (snmpTransportDomain) // legal restriction
ポインタ(snmpTransportDomain)//法的な制限
3.3. ObjectIdentifier
3.3. ObjectIdentifier
The ObjectIdentifier base type represents administratively assigned names for use with SNMP and COPS-PR. This type SHOULD NOT be used in protocol independent SMIng modules. It is meant to be used in SNMP and COPS-PR mappings of attributes of type Pointer (Section 3.2).
ObjectIdentifierベースタイプはSNMPとの使用とCOPS-PRのために行政上割り当てられた名前を表します。 これは中古のコネがプロトコルの独立しているSMIngモジュールであったならSHOULD NOTをタイプします。 それはタイプPointer(セクション3.2)の属性に関するSNMPとCOPS-PRマッピングで使用されることになっています。
Strauss & Schoenwaelder Experimental [Page 9] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[9ページ]RFC3780SMIng2004年5月
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)を超えてはいけない数字の非否定的なサブ識別子値の系列として指示されるかもしれません。 サブ識別子は小数か'0x'--前に置かれた16進で指示されるかもしれません。 それらはただ一つのドットと少しも中間的余白なしで切り離されます。 あるいはまた(そして、多くの場合、好まれる)、最初の要素は定義されたか、以前に輸入された小文字の識別子であるかもしれません、静的な物の識別子接頭語を表して。
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
1.3.6.1 十六進法subids iso.-1//不法な否定的subid iso.org.6不法な非//見出し識別子がある識別子接頭語インターネット.4.1.0x0627.0x01//法的なoidと//法的な数字のoid mib-2.1//法的なoid、-、MIB、:、:ifNumber.0//法的な完全に適切な例のoid
3.4. Integer32
3.4. Integer32
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.
10進数だけが負である場合があるところでタイプInteger32の値は小数か16進数として指示されるかもしれません。 ゼロ以外の10進数には、先行ゼロケタがあってはいけません。 16進数は、'0x'によって前に置かれていて、少なくとも2つの16進数字の偶数を持たなければなりません。(文字は大文字であるかもしれませんが、そこでは、下側のケースキャラクタはRECOMMENDEDです)。
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
'Integer32ベースタイプから引き出された(直接か間接的に)タイプを定義するとき、可能な値のセットは、パイプ‘によって切り離された範囲か明白な値のリストを追加することによって、制限されるかもしれません。|'キャラクタ、および挿入句に同封された全体のリスト'。 '範囲は下界、2つの連続したドットから成ります'。'上限' 小数か'0x'前に置かれた16進法で各値を与えることができます。 16進数には、少なくとも2ケタの偶数がなければなりません。 複数の値か範囲を与えるなら、それらは皆、ばらばらになることでなければならなく、昇順であるに違いありません。 新しい制限が値の制限が既に制限されたタイプに適用されるか、等しいかまたは、より制限していなければならないなら、それは下側を上げています。
Strauss & Schoenwaelder Experimental [Page 10] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[10ページ]RFC3780SMIng2004年5月
bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps.
領域であり、上限を減少させるか、明白な値か範囲を取り除くか、または分かれることが中間的ギャップで複数の範囲に及びます。
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//の法的な負の数--十六進法価値0x80000000の//不法な値、大き過ぎる0xf00f//法的な16進価値の1//不法な中間的スペース0xabc//不法な16進値長さ-0xff//不法なサイン
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. Integer32を注文している.3)//不法入国者、(4、.8|5. .10)//不法な重なること。
3.5. Integer64
3.5. Integer64
The Integer64 base type represents integer values between -2^63 (-9223372036854775808) and 2^63-1 (9223372036854775807).
Integer64ベースタイプは2^63(-9223372036854775808)と2^63-1(9223372036854775807)の間の整数値を表します。
Values of type Integer64 may be denoted as decimal or hexadecimal numbers, where only decimal numbers can be negative. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
10進数だけが負である場合があるところでタイプInteger64の値は小数か16進数として指示されるかもしれません。 ゼロ以外の10進数には、先行ゼロケタがあってはいけません。 16進数は、'0x'によって前に置かれていて、16進数字の偶数を持たなければなりません。(手紙は大文字であるかもしれませんが、そこでは、小文字はRECOMMENDEDです)。
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ケタの偶数がなければなりません。 複数の値か範囲を与えるなら、それらは皆、ばらばらになることでなければならなく、昇順であるに違いありません。 値の制限が既に制限されたタイプに適用されるなら、新しい制限が等しいか、より制限していなければならない、すなわち、下界を上げて、上限を減少させるか、明白な値か範囲を取り除くか、または分かれることが中間的ギャップで複数の範囲に及びます。
Strauss & Schoenwaelder Experimental [Page 11] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[11ページ]RFC3780SMIng2004年5月
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//の法的な負の数--十六進法価値0x80000000の//法的な値の1//不法な中間的スペース0xabc//不法な16進値長さ-0xff//不法なサイン
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. Integer64を注文している.3)//不法入国者、(4、.8|5. .10)//不法な重なること。
3.6. Unsigned32
3.6. Unsigned32
The Unsigned32 base type represents positive integer values between 0 and 2^32-1 (4294967295).
Unsigned32ベースタイプは0と2^32-1(4294967295)の間の正の整数値を表します。
Values of type Unsigned32 may be denoted as decimal or hexadecimal numbers. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
タイプUnsigned32の値は小数か16進数として指示されるかもしれません。 ゼロ以外の10進数には、先行ゼロケタがあってはいけません。 16進数は、'0x'によって前に置かれていて、16進数字の偶数を持たなければなりません。(手紙は大文字であるかもしれませんが、そこでは、小文字はRECOMMENDEDです)。
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//不法な16進値長さ0×80000000//の法的な16進価値0×8080000000//の不法な値で、大き過ぎます。
Strauss & Schoenwaelder Experimental [Page 12] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[12ページ]RFC3780SMIng2004年5月
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. Unsigned32を注文している.3)//不法入国者、(4、.8|5. .10)//不法な重なること。
3.7. Unsigned64
3.7. Unsigned64
The Unsigned64 base type represents positive integer values between 0 and 2^64-1 (18446744073709551615).
Unsigned64ベースタイプは0と2^64-1(18446744073709551615)の間の正の整数値を表します。
Values of type Unsigned64 may be denoted as decimal or hexadecimal numbers. Decimal numbers other than zero MUST NOT have leading zero digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case, but lower-case characters are RECOMMENDED.
タイプUnsigned64の値は小数か16進数として指示されるかもしれません。 ゼロ以外の10進数には、先行ゼロケタがあってはいけません。 16進数は、'0x'によって前に置かれていて、16進数字の偶数を持たなければなりません。(手紙は大文字であるかもしれませんが、そこでは、小文字はRECOMMENDEDです)。
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//不法な16進値長さ0×8080000000//の法的な16進価値
Restriction Examples:
制限の例:
Unsigned64 (1..10000000000) // legal range spec
Unsigned64 (5..10 | 2..3) // illegal ordering
Unsigned64(1 .10000000000)//法的な範囲仕様Unsigned64、(5、.10|2. .3)//不法な注文
3.8. Float32
3.8. Float32
The Float32 base type represents floating point values of single precision as described by [IEEE754].
[IEEE754]によって説明されるようにFloat32ベースタイプは単精度の浮動小数点値を表します。
Strauss & Schoenwaelder Experimental [Page 13] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[13ページ]RFC3780SMIng2004年5月
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の値は任意の解説者と共に小数として指示されるかもしれません、多くのプログラミング言語から知られているように。 詳細な構文に関してAppendix Bの文法規則'floatValue'を見てください。 特別な値は、'snan'(合図Not a番号)と、'qnan'(静かなNot a番号)と、'neginf'(負の無限)と、'posinf'(陽の無限)です。 -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つの連続したドットから成ります'。'上限' 複数の値か範囲を与えるなら、それらは皆、ばらばらになることでなければならなく、昇順であるに違いありません。 値の制限が既に制限されたタイプに適用されるなら、新しい制限が等しいか、より制限していなければならない、すなわち、下界を上げて、上限を減少させるか、明白な値か範囲を取り除くか、または分かれることが中間的ギャップで複数の範囲に及びます。 それらが含まれているものとするなら、制限で明らかに特別な値の'snan'、'qnan'、'neginf'、および'posinf'を記載しなければなりません、範囲で'snan'と'qnan'を使用できないところで。
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の物を輸送するプロトコルによって説明されなければなりません。 また、最も浮動小数点encodingsが人間の読み易さにSMIngで使用される小数として書くことができる多くの値の表現を禁じることに注意してください。 したがって、浮動小数点タイプ制限における明白な値は慎重に扱われるべきです。
Value Examples:
例を評価してください:
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
00.1 3.1415//法定価格-2.5//不法な先行ゼロE+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.3Float32(neginf..-0.0)//法的な範囲仕様Float32、(-10.0、.10、.0|0、)、//不法な重なること。
Strauss & Schoenwaelder Experimental [Page 14] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[14ページ]RFC3780SMIng2004年5月
3.9. Float64
3.9. Float64
The Float64 base type represents floating point values of double precision as described by [IEEE754].
[IEEE754]によって説明されるようにFloat64ベースタイプは倍精度の浮動小数点値を表します。
Values of type Float64 may be denoted as a decimal fraction with an optional exponent, as known from many programming languages. See the grammar rule `floatValue' of Appendix B for the detailed syntax. Special values are `snan' (signalling Not-a-Number), `qnan' (quiet Not-a-Number), `neginf' (negative infinity), and `posinf' (positive infinity). Note that -0.0 and +0.0 are different floating point values. 0.0 is equal to +0.0.
タイプFloat64の値は任意の解説者と共に小数として指示されるかもしれません、多くのプログラミング言語から知られているように。 詳細な構文に関してAppendix Bの文法規則'floatValue'を見てください。 特別な値は、'snan'(合図Not a番号)と、'qnan'(静かなNot a番号)と、'neginf'(負の無限)と、'posinf'(陽の無限)です。 -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つの連続したドットから成ります'。'上限' 複数の値か範囲を与えるなら、それらは皆、ばらばらになることでなければならなく、昇順であるに違いありません。 値の制限が既に制限されたタイプに適用されるなら、新しい制限が等しいか、より制限していなければならない、すなわち、下界を上げて、上限を減少させるか、明白な値か範囲を取り除くか、または分かれることが中間的ギャップで複数の範囲に及びます。 それらが含まれているものとするなら、制限で明らかに特別な値の'snan'、'qnan'、'neginf'、および'posinf'を記載しなければなりません、範囲で'snan'と'qnan'を使用できないところで。
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の物を輸送するプロトコルによって説明されなければなりません。 また、最も浮動小数点encodingsが人間の読み易さにSMIngで使用される小数として書くことができる多くの値の表現を禁じることに注意してください。 したがって、浮動小数点タイプ制限における明白な値は慎重に扱われるべきです。
Value Examples:
例を評価してください:
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
00.1 3.1415//法定価格-2.5//不法な先行ゼロE+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.3Float64(neginf..-0.0)//法的な範囲仕様Float64、(-10.0、.10、.0|0、)、//不法な重なること。
Strauss & Schoenwaelder Experimental [Page 15] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[15ページ]RFC3780SMIng2004年5月
3.10. Float128
3.10. Float128
The Float128 base type represents floating point values of quadruple precision as described by [IEEE754].
[IEEE754]によって説明されるようにFloat128ベースタイプは4倍精度の浮動小数点値を表します。
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の値は任意の解説者と共に小数として指示されるかもしれません、多くのプログラミング言語から知られているように。 詳細な構文に関してAppendix Bの文法規則'floatValue'を見てください。 特別な値は、'snan'(合図Not a番号)と、'qnan'(静かなNot a番号)と、'neginf'(負の無限)と、'posinf'(陽の無限)です。 -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つの連続したドットから成ります'。'上限' 複数の値か範囲を与えるなら、それらは皆、ばらばらになることでなければならなく、昇順であるに違いありません。 値の制限が既に制限されたタイプに適用されるなら、新しい制限が等しいか、より制限していなければならない、すなわち、下界を上げて、上限を減少させるか、明白な値か範囲を取り除くか、または分かれることが中間的ギャップで複数の範囲に及びます。 それらが含まれているものとするなら、制限で明らかに特別な値の'snan'、'qnan'、'neginf'、および'posinf'を記載しなければなりません、範囲で'snan'と'qnan'を使用できないところで。
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の物を輸送するプロトコルによって説明されなければなりません。 また、最も浮動小数点encodingsが人間の読み易さにSMIngで使用される小数として書くことができる多くの値の表現を禁じることに注意してください。 したがって、浮動小数点タイプ制限における明白な値は慎重に扱われるべきです。
Value Examples:
例を評価してください:
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
00.1 3.1415//法定価格-2.5//不法な先行ゼロE+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.3Float128(neginf..-0.0)//法的な範囲仕様Float128、(-10.0、.10、.0|0、)、//不法な重なること。
Strauss & Schoenwaelder Experimental [Page 16] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[16ページ]RFC3780SMIng2004年5月
3.11. Enumeration
3.11. 列挙
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.
Enumerationベースタイプは2^31(-2147483648)と2^31-1(2147483647)の間の範囲の1セットの整数から値を表します。(そこでは、各値が割り当てられた名前を持っています)。 数というもののリストは、コンマで切り離されて、挿入句での同封にされて、'列挙'キーワードに添付されていなければなりません。 数というそれぞれが小数か'0x'が挿入句に同封された16進数を前に置いたので指示された割り当てられた整数値があとに続いた低いケース識別子によって指示されます。 16進数には、少なくとも2ケタの偶数がなければなりません。 列挙タイプのあらゆる名前とあらゆる数がユニークであるに違いありません。 値が積極的であり、1時に始まって、近接して付番されるのは、RECOMMENDEDです。 昇順に数というすべてを与えなければなりません。
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
列挙、((1) (2)へのテスト(3))列挙、((1))//不法なオーダーを(2)に上げてください。
0 // legal (though not recommended) value up // legal value given by name 2 // legal value given by number
0 数によって与えられた名前2//法的な値によって与えられた//法定価格への//法的な(推薦されませんが)値
3.12. Bits
3.12. ビット
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.
ベースタイプが表すBitsはセットに噛み付きました。 すなわち、Bits値は0時に始まるわずかな整数によって特定された1セットの旗です。 数には、各ビット単位で、割り当てられた名前があります。 数というもののリストは、コンマで切り離されて、挿入句での同封にされて、'ビット'キーワードに添付されていなければなりません。 数というそれぞれが小数か'0x'が挿入句に同封された16進数を前に置いたので指示された割り当てられた整数値があとに続いた小文字の識別子によって指示されます。 16進数には、少なくとも2ケタの偶数がなければなりません。 ビットタイプのあらゆる名前とあらゆる数がユニークであるに違いありません。 数が0時に始まって、近接して付番されるのは、RECOMMENDEDです。 負数は禁じられます。 昇順に数というすべてを与えなければなりません。
Strauss & Schoenwaelder Experimental [Page 17] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[17ページ]RFC3780SMIng2004年5月
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'のコンマで切り離されたリストが16進数か望ましくは挿入句に同封されたそれらの割り当てられた名前を前に置いたので、ビットタイプの値は指示されるかもしれません。 16進数には、少なくとも2ケタの偶数がなければなりません。 もう少し記載されたどんな要素(名前か数に従った)も一度よりあるはずがありません。 昇順にElementsを記載しなければなりません。
When defining a type derived (directly or indirectly) from a bits type, the set of named numbers may be restricted by removing one or more named numbers, but no named numbers may be added or changed regarding its name, value, or both.
ビットタイプから引き出された(直接か間接的に)タイプを定義するとき、命名された数のセットが1つを取り除くことによって制限されるかもしれないか、または名前、値、または両方に関して数と命名されましたが、それ以上命名されなかった数を、加えるか、変えるかもしれません。
Type and Value Examples:
例をタイプして、評価してください:
Bits (readable(0), writable(1), executable(2))
Bits (writable(1), readable(0) // illegal order
ビット、(読み込み可能な(0)、書き込み可能な(1)、実行可能な(2))ビット、(書き込み可能な(1)、読み込み可能な(0)//不法なオーダー
() // legal empty value
(readable, writable, 2) // legal value
(0, readable, executable) // illegal, readable(0) appears twice
(writable, 4) // illegal, element 4 out of range
() 不法で、//法的な空の値(読み込み可能で、書き込み可能な2)の//法定価格(実行可能な読み込み可能な0)//読み込み可能な(0)が二度現れる、(範囲からの書き込み可能で、4)//不法な要素4
3.13. Display Formats
3.13. システム出力表示形式
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つの部品を含む整数書式仕様から成ります。 最初の部分はシステム出力表示形式を勧める単独のキャラクタです: '16進のための'x'はバイナリーのための''小数、8進のための'o'、またはb'がそうするでしょう。 すべてのタイプのために、値をレンダリングするとき、先行ゼロは省略されて、負の数において、マイナス記号はケタ直前表されます。 '第二部が'x''、o'、および'b'のためにいつも省略されて、存在している必要はない、'であるだろう 存在しているなら、第二部からハイフンから始まって、10進数はあとに続いています。(値をレンダリングするとき、それは、暗示している小数点を定義します)。 '例えば、-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
属性かタイプにOctetStringの基本的なベースタイプがあるとき、形式は1つ以上の八重奏書式仕様から成ります。 各仕様は各部分がゼロを使用して、取り除いている5つの部品か次の八重奏の以上から成ります。
Strauss & Schoenwaelder Experimental [Page 18] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[18ページ]RFC3780SMIng2004年5月
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.
値と表示するために次のゼロか以上キャラクタを生産すること。 値の中の八重奏は意味、ほとんどの重要な1番目の順に処理されます。
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つ以上の10進数字。 八重奏の長さがゼロであるかもしれないことに注意してください。 この数の八重奏以下が値に残っているなら、八重奏の、より少ない数は使用されています。
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'、'小数、UTF-8のために'8進のためのo'、ASCIIのための'a'であるか否かに関係なく'[RFC3629]のために、そうするでしょう。 八重奏長さの部分が1以上であり、システム出力表示形式部分が値の書式について言及するなら、ネットワークバイト順(ビッグエンディアンコード化)は、値における八重奏を解釈するのに使用されます。 '八重奏が処理した、どんな'システム出力表示形式も必ず整数の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. (任意)の表示分離符キャラクタ。 存在しているなら、この部分はこの八重奏仕様の各適用の後に表示のために生産された単独のキャラクタです。 しかしながら、この八重奏仕様のための反復ターミネータキャラクタの表示がすぐにそれのあとに続くなら、このキャラクタは表示のために生産されません。 10進数字と'*'を除いて、このキャラクタはどんなキャラクタであるかもしれません。
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. (任意)の反復ターミネータキャラクタ、表示分離符キャラクタが出席している場合にだけどれが存在している場合があるか、そして、およびこの八重奏仕様は反復インディケータで始まります。 存在しているなら、この部分はすべてのゼロか以上がこの八重奏仕様のアプリケーション(繰返し回数で与えるように)を繰り返した後に生産された単独のキャラクタです。 10進数字と'*'を除いて、このキャラクタはどんなキャラクタであるかもしれません。
Output of a display separator character or a repeat terminator character is suppressed if it would occur as the last character of the display.
表示の最後のキャラクタとして起こるなら、表示分離符キャラクタか反復ターミネータキャラクタの出力は抑圧されます。
Strauss & Schoenwaelder Experimental [Page 19] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[19ページ]RFC3780SMIng2004年5月
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.
何人かのタイプにおいて、書式仕様が全く定義されないことに注意してください。 そのようなタイプ、書式仕様SHOULDに基づいている派生型と属性には、省略されてください。 実装は彼らが解釈できない書式仕様を無視しなければなりません。 また、SMIng文法(付録B)が書式仕様の構文を指定しないことに注意してください。
Display Format Examples:
形式の例を表示してください:
Base Type Format Example Value Rendered Value
----------- ------------------- ---------------- -----------------
OctetString 255a "Hello World." Hello World.
OctetString 1x: "Hello!" 48:65:6c:6c:6f:21
OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024
OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee
Integer32 d-2 1234 12.34
値がレンダリングされた基地のタイプ形式例の価値----------- ------------------- ---------------- ----------------- OctetString 255a、「こんにちは、世界的である、」 こんにちは、世界。 OctetString 1x: 「こんにちは!」 48:65:6c:6c:6f: 21 OctetString 1d: 1d: 1d.1d、1a1d: 1d 0x0d1e0f002d0400 13: 30:15.0 4:0OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024OctetString*1x: /1x: 0x02aabbccddee aa: bb/cc:dd: ee Integer32 d-2 1234 12.34
4. The SMIng File Structure
4. SMIngファイル構造
The topmost container of SMIng information is a file. An SMIng file may contain zero, one or more modules. It is RECOMMENDED that modules be stored into separate files by their module names, where possible. However, for dedicated purposes, it may be reasonable to collect several modules in a single file.
SMIng情報の最上のコンテナはファイルです。 SMIngファイルはゼロ、1つ以上のモジュールを含むかもしれません。 モジュールが可能であるところにそれらのモジュール名によって別々のファイルの中として保存されるのは、RECOMMENDEDです。 しかしながら、ひたむきな目的のために、一列でいくつかのモジュールを集めるのは妥当であるかもしれません。
The top level SMIng construct is the `module' statement (Section 5) that defines a single SMIng module. A module contains a sequence of sections in an obligatory order with different kinds of definitions. Whether these sections contain statements or remain empty mainly depends on the purpose of the module.
最高平らなSMIng構造物はただ一つのSMIngモジュールを定義する'モジュール'声明(セクション5)です。 モジュールは異種の定義で義務的なオーダーにおける、セクションの系列を含んでいます。 これらのセクションが声明を含んでいるか、または空のままで残っているかがモジュールの目的に主によります。
4.1. Comments
4.1. コメント
Comments can be included at any position in an SMIng file, except between the characters of a single token like those of a quoted string. However, it is RECOMMENDED that all substantive descriptions be placed within an appropriate description clause, so that the information is available to SMIng parsers.
SMIngファイルのどんな見解にもコメントを含むことができます、引用文字列のもののようなただ一つのトークンのキャラクタを除いて。 しかしながら、すべての実質的な記述が適切な記述節の中に置かれるのは、RECOMMENDEDです、情報がSMIngパーサに利用可能であるように。
Strauss & Schoenwaelder Experimental [Page 20] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[20ページ]RFC3780SMIng2004年5月
Comments commence with a pair of adjacent slashes `//' and end at the end of the line.
'1組の隣接しているスラッシュが行の'//'と終わりの終わりにある状態で、コメントは始まります。
4.2. Textual Data
4.2. 原文のデータ
Some statements, namely `organization', `contact', `description', `reference', `abnf', `format', and `units', get a textual argument. This text, as well as representations of OctetString values, have to be enclosed in double quotes. They may contain arbitrary characters with the following exceptional encoding rules:
いくつかの声明(すなわち、'組織'、'接触'、'記述'、'参照'、'abnf'、'形式'、および'ユニット')が、原文の議論を得ます。 本稿、およびOctetString値の表現は二重引用符に同封されなければなりません。 以下が例外的にそれらは規則をコード化しながら、気紛れな質を含むかもしれません:
A backslash character introduces a special character, which depends on the character that immediately follows the backslash:
バックスラッシュキャラクタは特殊文字を紹介します:(特殊文字はすぐにバックスラッシュに従うキャラクタに頼ります)。
\n new line
\t a tab character
\" a double quote
\\ a single backslash
「\n新しい系列\t aタブキャラクタ、」 aが倍にする\は\\aただ一つのバックスラッシュを引用します。
If the text contains a line break followed by whitespace which is used to indent the text according to the layout in the SMIng file, this prefixing whitespace is stripped from the text.
テキストが使用された空白があとに続いたラインブレイクを含んでいるなら、SMIngファイル、この前に置くことにおけるレイアウトに従ってテキストを字下がりにするために、テキストから空白を剥取ります。
4.3. Statements and Arguments
4.3. 声明と議論
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.
声明が予想されますが、未知の小文字の単語が読まれる場所では、それらの声明を適切なセミコロンまでスキップしなければなりません、入れ子にされた声明ブロックを含んでいて。
5. The module Statement
5. モジュールStatement
The `module' statement is used as a container of all definitions of a single SMIng module. It gets two arguments: an upper-case module name and a statement block that contains mandatory and optional statements and sections of statements in an obligatory order:
'モジュール'声明はただ一つのSMIngモジュールのすべての定義のコンテナとして使用されます。 それは2つの議論を得ます: 義務的なオーダーにおける、義務的で任意の声明とセクションの声明を含む大文字モジュール名と声明ブロック:
Strauss & Schoenwaelder Experimental [Page 21] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[21ページ]RFC3780SMIng2004年5月
module <MODULE-NAME> {
モジュール<MODULE-NAME>。
<optional import statements>
<organization statement>
<contact statement>
<description statement>
<optional reference statement>
<at least one revision statement>
任意の<の<接触声明><輸入声明><組織声明>記述任意の声明の>の<の参照の声明の>の<の少なくとも1つの改正の声明>。
<optional extension statements>
<の任意の拡張子声明>。
<optional typedef statements>
<の任意のtypedef声明>。
<optional identity statements>
<の任意のアイデンティティ声明>。
<optional class statements>
<の任意のクラス声明>。
};
};
The optional `import' statements (Section 5.1) are followed by the mandatory `organization' (Section 5.2), `contact' (Section 5.3), and `description' (Section 5.4) statements and the optional `reference' statement (Section 5.5), which in turn are followed by at least one mandatory `revision' statement (Section 5.6). The part up to this point defines the module's meta information, i.e., information that describes the whole module but does not define any items used by applications in the first instance. This part of a module is followed by its main definitions, namely SMIng extensions (Section 6), derived types (Section 7), identities (Section 8), and classes (Section 9).
任意の'輸入'声明(セクション5.1)は義務的な'組織'(セクション5.2)によって従われています、と(セクション5.3)、'記述'(セクション5.4)声明、および任意の'参照'声明(セクション5.5)は'連絡します'。(順番に、少なくとも1義務的な'改正'の声明(セクション5.6)はそれのあとに続きます)。 部分はこの時点までに、モジュールのメタ情報(すなわち、全体のモジュールを説明しますが、アプリケーションでまず使用されるどんな項目も定義しない情報)を定義します。 モジュールのこの部分は主な定義、すなわち、SMIng拡張子(セクション6)、派生型(セクション7)、アイデンティティ(セクション8)、およびクラス(セクション9)によって後をつけられています。
See the `moduleStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `module' statement.
'モジュール'声明の正式な構文に関してSMIng文法(付録B)の'moduleStatement'規則を見てください。
5.1. The module's import Statement
5.1. モジュールの輸入Statement
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
識別子のリストをばらばらにならせてください。しかし、倍数が同じモジュールのために声明を'インポートする'、NOT RECOMMENDEDですが、許容されています。 複数の回であると同じモジュールからの同じ識別子をインポートしてはいけません。 同じ名前で異なったモジュールから識別子をインポートするのは、必要であるかもしれなく、許されています。 区別するために
Strauss & Schoenwaelder Experimental [Page 22] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[22ページ]RFC3780SMIng2004年5月
them in the local module, they have to be referred by qualified names. Importing identifiers not used in the local module is NOT RECOMMENDED.
それら、ローカルのモジュールで、それらは適切な名前によって参照されなければなりません。 ローカルのモジュールで使用されない識別子をインポートするのは、NOT RECOMMENDEDです。
See the `importStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `import' statement.
'輸入'声明の正式な構文に関してSMIng文法(付録B)の'importStatement'規則を見てください。
5.2. The module's organization Statement
5.2. モジュールの組織Statement
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つの議論を得ます。
5.3. The module's contact Statement
5.3. モジュールの接触Statement
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つの議論を得ます。
5.4. The module's description Statement
5.4. モジュールの記述Statement
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つの議論を得ます。
5.5. The module's reference Statement
5.5. モジュールの参照Statement
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つの議論を得ます。
5.6. The module's revision Statement
5.6. モジュールの改正Statement
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.
'改正'声明の正式な構文に関してSMIng文法(付録B)の'revisionStatement'規則を見てください。
Strauss & Schoenwaelder Experimental [Page 23] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[23ページ]RFC3780SMIng2004年5月
5.6.1. The revision's date Statement
5.6.1. 改正の日付Statement
The revision's `date' statement, which must be present, gets one argument which is used to specify the date and time of the revision in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the time `00:00'. The time is always given in UTC.
改正は''声明(存在していなければならない)は時間を含意する形式の'YYYY-MM-DD 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.
改正の'日付'声明の正式な構文に関してSMIng文法(付録B)の'日付'規則を見てください。
5.6.2. The revision's description Statement
5.6.2. 改正の記述Statement
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つの議論を得ます。
5.7. Usage Example
5.7. 使用例
Consider how a skeletal module might be constructed:
骨格のモジュールがどのように構成されるかもしれないか考えてください:
module ACME-MIB {
モジュールACME-MIB
import NMRG-SMING (DisplayString);
NMRG-SMING(DisplayString)をインポートしてください。
organization
"IRTF Network Management Research Group (NMRG)";
組織「IRTFネットワークマネージメント研究グループ(NMRG)」。
contact "IRTF Network Management Research Group (NMRG)
http://www.ibr.cs.tu-bs.de/projects/nmrg/
接触「IRTFネットワークマネージメント研究グループ(NMRG) http://www.ibr.cs.tu-bs.de/projects/nmrg/ 」
Joe L. User
ジョーL.ユーザ
ACME, Inc.
42 Anywhere Drive
Nowhere, CA 95134
USA
どこでもInc.42がどこにも追い立てない頂上、カリフォルニア95134米国
Phone: +1 800 555 0815
EMail: joe@acme.example.com";
以下に電話をしてください。 +1 0815年の800 555メール: " 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.";
Copyright(C)インターネット協会(2004)。 All rights reserved。 「RFC自身は、法定の通知に関してこのMIBモジュールのこのバージョンがRFC3780の一部であると考えます。」
Strauss & Schoenwaelder Experimental [Page 24] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[24ページ]RFC3780SMIng2004年5月
revision {
date "2003-12-16";
description
"Initial revision, published as RFC 3780.";
};
改正、「2003年12月16日」のときに、デートしてください; 「初期の改正であって、RFC3780として発行された」記述。
// ... further definitions ...
//…より遠い定義…
}; // end of module ACME-MIB.
}; モジュールACME-MIBの//端。
6. The extension Statement
6. 拡大Statement
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.
拡大文名標SHOULD NOTはどんな大文字キャラクタも含んでいます。
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において拡大の詳細な情報のためのセクション11とSMIng定義に関するマッピングのための[RFC3781]を見てください。(SNMPは正式に拡大と定義されます)。
See the `extensionStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `extension' statement.
'拡大'声明の正式な構文に関してSMIng文法(付録B)の'extensionStatement'規則を見てください。
6.1. The extension's status Statement
6.1. 拡大の状態Statement
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つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
Strauss & Schoenwaelder Experimental [Page 25] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[25ページ]RFC3780SMIng2004年5月
6.2. The extension's description Statement
6.2. 拡大の記述Statement
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.
拡大の文脈、意味論、および実装条件の情報が含まれているのは、RECOMMENDEDです。 また、セクション11を見てください。
6.3. The extension's reference Statement
6.3. 拡大の参照Statement
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つの議論を得ます。
6.4. The extension's abnf Statement
6.4. 拡大のabnf Statement
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つの議論を得ます。 この文法はコアSMIng文法(付録B)からの参照規則名をそうすることができます。
Note that the `abnf' statement should contain only pure ABNF and no additional text, though comments prefixed by a semicolon are allowed but should probably be moved to the description statement. Note that double quotes within the ABNF grammar have to be represented as `\"' according to Section 4.2.
純粋なABNFだけを含んでいますが、'abnf'声明がどんな追加テキストも含むべきでないことに注意してください、セミコロンによって前に置かれたコメントが、許容されていますが、たぶん記述声明に動かされるべきですが。 セクション4.2に従った「ABNF文法の中の二重引用符が'\」として表されなければならないことに注意してください。'
6.5. Usage Example
6.5. 使用例
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\"";
};
拡大の厳しさ{ 状態電流。 記述、「SMIngのクラスのイベント定義の声明ブロックに任意の厳しさ拡大声明を適用できるだけです」。 「存在しているなら、0からの範囲(非常時)のイベントの厳しさレベルを7(デバッグする)に指示します。」 「abnfに、「severityStatementはseverityKeyword sep数のoptsep\と等しい」; \」というseverityKeywordが\と等しい、「厳しさ、\、」、」、。 };
Strauss & Schoenwaelder Experimental [Page 26] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[26ページ]RFC3780SMIng2004年5月
7. The typedef Statement
7. typedef Statement
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.
タイプ識別子SHOULD NOTはすべての大文字キャラクタから成ります、そして、SHOULD NOTはハイフンを含んでいます。
See the `typedefStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `typedef' statement.
'typedef'声明の正式な構文に関してSMIng文法(付録B)の'typedefStatement'規則を見てください。
7.1. The typedef's type Statement
7.1. typedefのタイプStatement
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つの議論を得ます。 任意に、タイプ制限は、ベースタイプの規則に従って副タイプ情報を追加することによって、新しいタイプに適用されるかもしれません。 SMIngベースタイプと彼らのタイプ制限に関してセクション3を見てください。
7.2. The typedef's default Statement
7.2. typedefのデフォルトStatement
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.
何人かのタイプのために、デフォルト値が意味をなさないことに注意してください。
7.3. The typedef's format Statement
7.3. typedefの形式Statement
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を見てください。
Strauss & Schoenwaelder Experimental [Page 27] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[27ページ]RFC3780SMIng2004年5月
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.
形式が全く指定されないなら、それは'タイプ'声明で与えられているタイプから引き継がれます。 他方では、タイプの書式仕様はこのタイプの属性の書式仕様によって意味的に洗練されるかもしれません。
7.4. The typedef's units Statement
7.4. typedefのユニットStatement
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の頻度値を定義するなら、書式仕様が定義するべきである、-3、'ユニット仕様は、'ヘルツ'か'Hz'であるべきでしょう。 書式仕様が省略されるなら、ユニット仕様は、'ミリHertz'か'mHz'であるべきです。 SMIngモジュールの作者は、注意が、形式とユニットが同時性で仕様であることを保つのを支払うべきです。 書式仕様を実装しないで、アプリケーション作成者は、ユニットが仕様であると実装してはいけません。
7.5. The typedef's status Statement
7.5. typedefの状態Statement
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.
派生型SHOULD NOT、彼らの基底型が'推奨しない'か'時代遅れである'なら、'電流'と定義されてください。 同様である、それら、SHOULD NOT、彼らの基底型が'時代遅れである'なら、'推奨しなく'定義されてください。 それにもかかわらず、基底型のその後の改正を避けることができないで、唯一のSHOULDはアカウントに連れていかれたコネです。ローカルのモジュールのその後の改正。
Strauss & Schoenwaelder Experimental [Page 28] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[28ページ]RFC3780SMIng2004年5月
7.6. The typedef's description Statement
7.6. typedefの記述Statement
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.
実装、そうでなければこの型定義に関連しているどんな論評注釈でも伝えられるどんな情報も具体化するのに必要なすべての意味定義が含まれているのは、RECOMMENDEDです。
7.7. The typedef's reference Statement
7.7. typedefの参照Statement
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つの議論を得ます。
7.8. Usage Examples
7.8. 使用例
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.";
};
Enumerationをタイプしてください。typedef RptrOperStatus、(他の(1)、OK(2)、rptrFailure(3)、groupFailure(4)、portFailure(5)(デフォルト他のデフォルトで//未定義のgeneralFailure(6)))、状態推奨しない、; 「Aはリピータの操作上の状態を示すためにタイプする」記述、参照、「[IEEE802.3Mgt]、30.4、.1 .1 .5、aRepeaterHealthState、」、。
typedef SnmpTransportDomain {
type Pointer (snmpTransportDomain);
status current;
description
"A pointer to an SNMP transport domain identity.";
};
Pointer(snmpTransportDomain); 状態電流;記述をタイプしてください。typedef SnmpTransportDomain、「SNMP輸送事業領域への指針」、。
typedef DateAndTime {
type OctetString (8 | 11);
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
status current;
description
"A date-time specification.
...
typedef DateAndTime、OctetString(8|11)をタイプしてください; 形式「1a1d: 2d-1d-1d、1d:1d:1d.1d、1d」(状態電流)記述「A日付-時間仕様」
Strauss & Schoenwaelder Experimental [Page 29] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[29ページ]RFC3780SMIng2004年5月
Note that if only local time is known, then timezone
information (fields 8-10) is not present.";
reference
"RFC 2579, SNMPv2-TC.DateAndTime.";
};
「現地時間であるだけであるならそれが知られていることに注意してください、そして、次に、タイムゾーン情報(分野8-10)は存在していません。」 「RFC2579、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.";
};
typedef Frequency、タイプUnsigned64; 形式、「d3インチのユニット「ヘルツ」; 状態電流;記述「頻度仕様が数千で測定した広い範囲Hertz」。;、」、。
8. The identity Statement
8. アイデンティティStatement
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つの議論を得ます: 最初の議論は小文字のアイデンティティ識別子です。 2番目の議論は義務的なオーダーにおける詳細なアイデンティティ情報を保持する声明ブロックです。
See the `identityStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `identity' statement.
'アイデンティティ'声明の正式な構文に関してSMIng文法(付録B)の'identityStatement'規則を見てください。
8.1. The identity's parent Statement
8.1. アイデンティティの親Statement
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つの議論を得ます。
8.2. The identity's status Statement
8.2. アイデンティティの状態Statement
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つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
Strauss & Schoenwaelder Experimental [Page 30] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[30ページ]RFC3780SMIng2004年5月
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.
アイデンティティSHOULD NOTを引き出す、彼らの親のアイデンティティが'推奨しない'か'時代遅れである'なら、'電流'と定義されてください。 同様である、それら、SHOULD NOT、彼らの親のアイデンティティが'時代遅れである'なら、'推奨しなく'定義されてください。 それにもかかわらず、親のアイデンティティのその後の改正を避けることができないで、唯一のSHOULDはアカウントに連れていかれたコネです。ローカルのモジュールのその後の改正。
8.3. The identity' description Statement
8.3. 'アイデンティティ'記述Statement
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.
アイデンティティの'記述'声明(存在していなければならない)は新たに定義されたアイデンティティのハイレベルの原文の記述を指定するのに使用される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.
実装、そうでなければこのアイデンティティ定義に関連しているどんな論評注釈でも伝えられるどんな情報も具体化するのに必要なすべての意味定義が含まれているのは、RECOMMENDEDです。
8.4. The identity's reference Statement
8.4. アイデンティティの参照Statement
The identity's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related identity definitions, or some other document which provides additional information relevant to this identity definition.
アイデンティティの'参照'声明(存在している必要はない)はある他のドキュメント(関連するアイデンティティ定義を定義する別のモジュールかこのアイデンティティ定義に関連している追加情報を提供するドキュメントのどちらかある他の)に原文の相互参照を指定するのに使用される1つの議論を得ます。
8.5. Usage Examples
8.5. 使用例
identity null {
status current;
description
"An identity used to represent null pointer values.";
};
アイデンティティヌル、状態電流; 「アイデンティティは空ポインタ値を表すのに使用した」記述、。
identity snmpTransportDomain {
status current;
description
"A generic SNMP transport domain identity.";
};
アイデンティティsnmpTransportDomain、状態電流; 記述「AジェネリックSNMP輸送事業領域」、。
identity snmpUDPDomain {
parent snmpTransportDomain;
status current;
description
"The SNMP over UDP transport domain.";
};
snmpTransportDomain; 状態電流;記述の親代わりとなってください。アイデンティティsnmpUDPDomain、「UDP輸送ドメインの上のSNMP」、。
Strauss & Schoenwaelder Experimental [Page 31] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[31ページ]RFC3780SMIng2004年5月
9. The class Statement
9. クラスStatement
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.
'クラス'声明の正式な構文に関してSMIng文法(付録B)の'classStatement'規則を見てください。
9.1. The class' extends Statement
9.1. クラスのものはStatementを広げています。
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つの議論を得ます。
9.2. The class' attribute Statement
9.2. クラスの属性Statement
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つの議論を得ます: 属性名と持ちこたえる声明ブロックは義務的なオーダーにおける属性情報を詳しく述べました。
9.2.1. The attribute's type Statement
9.2.1. 属性のタイプStatement
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番目の議論で制限されるかもしれません。
9.2.2. The attribute's access Statement
9.2.2. 属性のアクセスStatement
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つの議論を得ます。 これは属性のための最大限度のアクセスのレベルです。 この最大限度のアクセスのレベルはどんな管理承認方針からも独立しています。
Strauss & Schoenwaelder Experimental [Page 32] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[32ページ]RFC3780SMIng2004年5月
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'。
9.2.3. The attribute's default Statement
9.2.3. 属性のデフォルトStatement
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.
両方が存在しているなら、属性のデフォルト値は基底型定義のデフォルト値をくつがえします。
9.2.4. The attribute's format Statement
9.2.4. 属性の形式Statement
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.
両方が存在しているなら、属性の書式仕様は基底型定義の書式仕様をくつがえします。
9.2.5. The attribute's units Statement
9.2.5. 属性のユニットStatement
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.
両方が存在しているなら、属性のユニット仕様は基底型定義のユニット仕様に優越します。
Strauss & Schoenwaelder Experimental [Page 33] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[33ページ]RFC3780SMIng2004年5月
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の数千で測定されたタイプUnsigned64の頻度値を表すなら、書式仕様が表すべきである、-3、'ユニット仕様は、'ヘルツ'か'Hz'であるべきでしょう。 書式仕様が省略されるなら、ユニット仕様は、'ミリHertz'か'mHz'であるべきです。 SMIngモジュールの作者は、注意が、形式とユニットが同時性とのタイプと属性定義の仕様であることを保つのを支払うべきです。 書式仕様を実装しないで、アプリケーション作成者は、ユニットが仕様であると実装してはいけません。
9.2.6. The attribute's status Statement
9.2.6. 属性の状態Statement
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.
彼らのタイプであるなら'電流'と定義されるか、またはそれらがクラスを含むことである属性SHOULD NOTは'推奨しない'か'時代遅れです'。 同様である、それら、彼らのタイプであるなら'推奨しなく'定義されるか、またはそれらがクラスを含むことであるSHOULD NOTは'時代遅れです'。 それにもかかわらず、中古の型定義のその後の改正を避けることができないで、唯一のSHOULDはアカウントに連れていかれたコネです。ローカルのモジュールのその後の改正。
9.2.7. The attribute's description Statement
9.2.7. 属性の記述Statement
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.
この属性の実装に必要なすべての意味定義が含まれているのは、RECOMMENDEDです。
9.2.8. The attribute's reference Statement
9.2.8. 属性の参照Statement
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つの議論を得ます。
Strauss & Schoenwaelder Experimental [Page 34] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[34ページ]RFC3780SMIng2004年5月
9.3. The class' unique Statement
9.3. クラスのユニークなStatement
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.
存在しているなら、属性リストが一度より多くのどんな属性も保管してはいけなくて、属性が適切であるところで命令されるべきであるので、ほとんどの状況で最も重要な属性は最初に、現れます。
9.4. The class' event Statement
9.4. クラスのイベントStatement
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つの議論を得ます: 小文字の事象IDと持ちこたえる声明ブロックは義務的なオーダーにおける情報を詳しく述べました。
See the `eventStatement' rule of the SMIng grammar (Appendix B) for the formal syntax of the `event' statement.
'イベント'声明の正式な構文に関してSMIng文法(付録B)の'eventStatement'規則を見てください。
9.4.1. The event's status Statement
9.4.1. イベントの状態Statement
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つの議論を得ます。 値の'電流'は、定義が現在であって有効であることを意味します。 値の'時代遅れ'を定義が時代遅れであることを意味して、実装するべきでない、そして/または、以前に実装するなら、取り除くことができます。 また、値である間、'推奨しないこと'は時代遅れの定義を示して、それは、より古いか既存の実装で相互運用性を伸ばすために新しいか継続的な実装を可能にします。
9.4.2. The event's description Statement
9.4.2. イベントの記述Statement
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つの議論を得ます。
Strauss & Schoenwaelder Experimental [Page 35] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[35ページ]RFC3780SMIng2004年5月
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.
このイベントの実装に必要なすべての意味定義が含まれているのは、RECOMMENDEDです。 特にクラスのそれのインスタンスは記録されるこのタイプSHOULDのイベントに関連しています。
9.4.3. The event's reference Statement
9.4.3. イベントの参照Statement
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つの議論を得ます。
9.5. The class' status Statement
9.5. クラスの状態Statement
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.
引き出しているクラスSHOULD NOT、それらの親のクラスが'推奨しない'か'時代遅れである'なら、'電流'と定義されてください。 同様である、それら、SHOULD NOT、それらの親のクラスが'時代遅れである'なら、'推奨しなく'定義されてください。 それにもかかわらず、親のクラスのその後の改正を避けることができないで、唯一のSHOULDはアカウントに連れていかれたコネです。ローカルのモジュールのその後の改正。
9.6. The class' description Statement
9.6. クラスの記述Statement
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.
実装、そうでなければこのクラス定義に関連しているどんな論評注釈でも伝えられるどんな情報も具体化するのに必要なすべての意味定義が含まれているのは、RECOMMENDEDです。
Strauss & Schoenwaelder Experimental [Page 36] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[36ページ]RFC3780SMIng2004年5月
9.7. The class' reference Statement
9.7. クラスの参照Statement
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つの議論を得ます。
9.8. Usage Example
9.8. 使用例
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.";
};
AdminStatusをタイプしてください; readwrite; 状態電流; 記述にアクセスしてください。OperStatusをタイプしてください; アクセスは記述をreadonlyします; 状態電流;。クラスInterface、…//属性速度、「bpsにおけるインタフェースの現在の帯域幅の見積り」Gauge32; アクセスreadonly; ユニット「ビーピーエス」; 状態電流; 記述をタイプしてください、; …//属性adminStatus、「インタフェースの必要な状態」、;、operStatusを結果と考えてください 「インタフェースの現在の操作上の状態」、。
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.";
linkDownイベントは、このインタフェースインスタンスのためのifOperStatus属性がある他の状態(しかし、いずれのnotPresent状態からも、そうしない)から下に状態に入ろうとしているのを意味します。イベントlinkDown、状態、電流;記述、「この他の状態はifOperStatusの含まれている値によって示されます」。
Strauss & Schoenwaelder Experimental [Page 37] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[37ページ]RFC3780SMIng2004年5月
};
};
status current;
description
"A physical or logical network interface.";
状態電流。 「物理的であるか論理的なネットワークは連結する」記述。
};
};
10. Extending a Module
10. モジュールを広げています。
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')を変えてはいけません、そして、1つのモジュールから別のモジュールまで定義を動かしてはいけません。
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 'タイプ'サブ声明がクラスを指定する'属性'声明では、基底クラスから新しいクラスを引き出すなら(直接か間接的に)、クラスをもう1人のクラスに取り替えるかもしれません、そして、両方のクラスには、同じ意味論があります。
Strauss & Schoenwaelder Experimental [Page 38] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[38ページ]RFC3780SMIng2004年5月
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 どんな声明ブロックでも、'電流'の'状態'声明価値は'推奨しない'か'時代遅れ'として改訂されるかもしれません。 同様に、'推奨しないこと'の'状態'声明価値は'時代遅れ'として改訂されるかもしれません。 そのような変化、'記述'を声明SHOULDにするときにはアップデートして、原理について説明してください。
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.
既存の定義に関連している識別子を変えるのが意味変化であると考えられることに注意してください、これらのストリングが'輸入'声明で使用されるとき。
11. SMIng Language Extensibility
11. SMIng言語伸展性
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
コアSMIng言語には一般的に必要であると管理プロトコル特殊情報なしで見なされた経営情報のそれらの局面を指定するのに使用されるよく定義されたセットの声明(セクション9.4を通したセクション5)がある間、あるかもしれません。
Strauss & Schoenwaelder Experimental [Page 39] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[39ページ]RFC3780SMIng2004年5月
further information people wish to express. Describing additional information informally in description statements has a disadvantage in that this information cannot be parsed by any program.
人々が言い表したがっている詳細。 記述声明で追加情報について非公式に説明するのにおいて、不都合が、どんなプログラムでもこの情報を分析できないので、あります。
SMIng 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 明確に、SMIng実装のサポートしている拡大(例えば、SMIngモジュールコンパイラ)を言い表すことができます。
The only formal effect of an extension statement definition is to declare its existence and status, and optionally its ABNF grammar. All additional aspects SHOULD be described in the `description' statement:
拡大声明定義の唯一のホルマール作用は任意にその存在と状態を宣言することです。ABNF文法、すべての追加局面のSHOULD、'記述'声明で説明されてください:
o The detailed semantics of the new statement SHOULD be described.
o 詳細な意味論、新しい声明SHOULDでは、説明されてください。
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 新しい声明が中古のSHOULDであるかもしれない文脈が説明されて、例えば新しい声明は、モジュールの声明ブロックだけで使用されるように設計されていますが、他の入れ子にされた声明ブロックで設計されるかもしれないというわけではありません。 他のものは複数の文脈で適切であるかもしれません。 さらに、他の声明の義務的な注文の系列のポイントは新しい声明が挿入されるかもしれないところに定められるかもしれません。
o The circumstances that make the new statement mandatory or
optional SHOULD be described.
o 新しい声明の義務的であるか任意のSHOULDについて説明する事情。
Strauss & Schoenwaelder Experimental [Page 40] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[40ページ]RFC3780SMIng2004年5月
o The syntax of the new statement SHOULD at least be described
informally, if not supplied formally in an `abnf' statement.
o 構文、少なくとも新しい声明SHOULDでは、'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]フレームワークとのSMIng定義の正式なマッピングはSMIng拡張子と定義されます。 他のマッピングは将来、従うかもしれません。
o Inlined annotations to definitions. For example, a vendor may
wish to describe additional information to class and attribute
definitions in private modules. An example are severity levels of
events in the statement block of an `event' statement.
o 定義に注釈をInlinedしました。 例えば、ベンダーは個人的なモジュールでクラスと属性定義に追加情報について説明したがっているかもしれません。 例は'イベント'声明の声明ブロックのイベントの厳しさレベルです。
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 外部定義への任意の注釈。 例えば、ベンダーは「標準」のモジュールとの定義に追加情報について説明したがっているかもしれません。 これで、ベンダーは余分なモジュール定義なしで「標準」のモジュール定義の上で追加個人的な特徴と同様に「標準」のモジュールを実装することができます。
12. Security Considerations
12. セキュリティ問題
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.
このドキュメントは経営情報の記述を書いて、読む言語を定義します。 言語自体はインターネットにセキュリティ影響力を全く持っていません。
13. Acknowledgements
13. 承認
Since SMIng started as a close successor of SMIv2, some paragraphs and phrases are directly taken from the SMIv2 specifications [RFC2578], [RFC2579], [RFC2580] written by Jeff Case, Keith McCloghrie, David Perkins, Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser.
SMIngがSMIv2の近い後継者を始めたので、SMIv2仕様[RFC2578]、[RFC2579]、ジェフCaseによって書かれた[RFC2580]、キースMcCloghrie、デヴィッド・パーキンス、マーシャル・T.ローズ、ユルゲンSchoenwaelder、およびスティーブンL.Waldbusserから数個のパラグラフと句を直接取ります。
The authors would like to thank all participants of the 7th NMRG meeting held in Schloss Kleinheubach from 6-8 September 2000, which was a major step towards the current status of this memo, namely Heiko Dassow, David Durham, Keith McCloghrie, and Bert Wijnen.
作者はシュロスKleinheubachですなわち、このメモ、Heiko Dassow、デヴィッド・ダラム、キースMcCloghrie、およびバートWijnenの現在の状態に向かった主要なステップであった2000年9月6-8日から行われる7番目のNMRG会合のすべての関係者に感謝したがっています。
Furthermore, several discussions within the SMING Working Group reflected experience with SMIv2 and influenced this specification at some points.
その上、SMING作業部会の中のいくつかの議論が、SMIv2と共に経験を反映して、諸点でこの仕様に影響を及ぼしました。
Strauss & Schoenwaelder Experimental [Page 41] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[41ページ]RFC3780SMIng2004年5月
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
エド[RFC2234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
14.2. Informative References
14.2. 有益な参照
[RFC3216] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
Strauss, F. and W. Weiss, "SMIng Objectives", RFC 3216,
December 2001.
[RFC3216] エリオットとC.とハリントンとD.とジェイソンとJ.とSchoenwaelderとJ.とストラウスとF.とW.ウィス、「SMIng目的」、RFC3216、2001年12月。
[RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation
Structure of Management Information (SMIng) Mappings to
the Simple Network Management Protocol (SNMP)", RFC 3781,
May 2004.
[RFC3781] ストラウス、F.、およびJ.Schoenwaelder(「簡単なネットワーク管理プロトコル(SNMP)への経営情報(SMIng)マッピングの次世代構造」、RFC3781)は2004がそうするかもしれません。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrieとK.、パーキンスとD.とJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 59, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD59、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 60, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とJ.Schoenwaelder、「SMIv2"、STD60、RFC2580、1999年4月のための順応声明。」
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of
Policy Provisioning Information (SPPI)", RFC 3159, August
2001.
[RFC3159]McCloghrie、K.、おかげさまで元気です、M.、Seligson、J.、チェン、K.、ハーン、S.、Sahita、R.、スミス、A.、およびF.Reichmeyer、「方針の構造は情報(SPPI)に食糧を供給し」て、RFC3159、2001年8月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets", STD
16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
Strauss & Schoenwaelder Experimental [Page 42] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[42ページ]RFC3780SMIng2004年5月
[ASN1] International Organization for Standardization,
"Specification of Abstract Syntax Notation One (ASN.1)",
International Standard 8824, December 1987.
[ASN1]国際標準化機構、「抽象構文記法1(ASN.1)の仕様」、国際規格8824、1987年12月。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3411] ハリントンとD.とPresuhnとR.とB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411、2002年12月。
[IEEE754] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, August 1985.
[IEEE754]米国電気電子技術者学会、「2進の浮動小数点の演算のIEEE規格」、ANSI/IEEE規格754-1985、1985年8月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith,
"COPS Usage for Policy Provisioning", RFC 3084, March
2001.
[RFC3084]チェン(K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ハーツォグ、S.、Reichmeyer、F.、Yavatkar、R.、およびA.スミス)は、「方針の食糧を供給する用法を獲得します」、RFC3084、2001年3月。
Strauss & Schoenwaelder Experimental [Page 43] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[43ページ]RFC3780SMIng2004年5月
Appendix A. NMRG-SMING Module
付録A.NMRG-SMINGモジュール
Most SMIng modules are built on top of the definitions of some commonly used derived types. The definitions of these derived types are contained in the NMRG-SMING module which is defined below. Its derived types are generally applicable for modeling all areas of management information. Among these derived types are counter types, string types, and date and time related types.
ほとんどのSMIngモジュールが何人かの一般的に使用された派生型の定義の上で築き上げられます。 これらの派生型の定義は以下で定義されるNMRG-SMINGモジュールで含まれています。 一般に、経営情報のすべての領域をモデル化するのに、派生型は適切です。 このうち、派生型は、カウンタタイプであり、タイプを結んで、デートします、そして、時間はタイプを関係づけました。
This module is derived from RFC 2578 [RFC2578] and RFC 2579 [RFC2579].
RFC2578[RFC2578]とRFC2579[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
フランクストラウスTUブラウンシュバイクMuehlenpfordtstrasse23 38106ブラウンシュバイクドイツ電話: +49 3266年の531 391メール: strauss@ibr.cs.tu-bs.de
Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de";
ユルゲンSchoenwaelderの国際大学ブレーメン私書箱750 561 28725ブレーメンドイツPhone: +49 3587年の421 200メール: " j.schoenwaelder@iu-bremen.de "。
description "Core type definitions for SMIng. Several
type definitions are SMIng versions of
similar SMIv2 or SPPI definitions.
記述は「SMIngのために型定義の芯を取ります」。 いくつかの型定義が同様のSMIv2かSPPI定義のSMIngバージョンです。
Copyright (C) The Internet Society (2004).
All Rights Reserved.
This version of this module is part of
RFC 3780, see the RFC itself for full
legal notices.";
Copyright(C)インターネット協会(2004)。 All rights reserved。 「RFC自身は、完全な法定の通知に関してこのモジュールのこのバージョンがRFC3780の一部であると考えます。」
Strauss & Schoenwaelder Experimental [Page 44] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[44ページ]RFC3780SMIng2004年5月
revision {
date "2003-12-16";
description "Initial revision, published as RFC 3780.";
};
改正、「2003年12月16日」のときに、デートしてください; 「初期の改正であって、RFC3780として発行された」記述。
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 Gauge32{ Unsigned32をタイプしてください。 記述は「非負の整数を表Gauge32がタイプするします」。(負の整数は、最大値を決して超えないのを除いて、増減して、最小値の下まで下がるかもしれません)。 最大値が2以上^32-1であり(4294967295小数)であるはずがない、最小値は0よりわずかであるはずがありません。 Gauge32の値には、モデル化される情報がそう以上であるときはいつも、最大値があります。そして、最大が評価する、モデル化される情報が、より最小値以下であるときはいつも、最小値を持っています。 「また、次にモデル化される情報が以下(上では、増加する)で最大(最小の)の値を減少させるなら、Gauge32は減少します(増加します)。」 「RFC2578、セクション2 7.1.7」という参照。 };
typedef Counter32 {
type Unsigned32;
description
"The Counter32 type represents a non-negative integer
which monotonically increases until it reaches a
maximum value of 2^32-1 (4294967295 decimal), when it
wraps around and starts increasing again from zero.
typedef Counter32、Unsigned32をタイプしてください; 「Counter32タイプは巻きつけるとき、2^32-1(4294967295小数)の最大値に達するまで単調に増加して、再びゼロから増え始める非負の整数に表す」記述。
Counters have no defined `initial' value, and thus, a
single value of a Counter has (in general) no information
content. Discontinuities in the monotonically increasing
value normally occur at re-initialization of the
management system, and at other times as specified in the
description of an attribute using this type. If such
other times can occur, for example, the creation of a
class instance that contains an attribute of type
Counter32 at times other than re-initialization, then a
corresponding attribute should be defined, with an
appropriate type, to indicate the last discontinuity.
Examples of appropriate types include: TimeStamp32,
TimeStamp64, DateAndTime, TimeTicks32 or TimeTicks64
(other types defined in this module).
カウンタには、定義された'初期'の値が全くありません、そして、その結果、Counterのただ一つの値には、情報量が全くありません(一般に)。 通常、単調に増加する値における不連続はマネージメントシステムの再初期化においてこのタイプを使用する属性の記述における指定されるとしての他の時に起こります。 そのような他の回が起こることができるなら、例えば、再初期化を除いて、時にはタイプCounter32の属性を含むクラスインスタンスの作成であり、対応する属性は、最後の不連続を示すために適切なタイプで定義されるべきです。 適切なタイプに関する例は: TimeStamp32、TimeStamp64、DateAndTime、TimeTicks32またはTimeTicks64(このモジュールで定義された他のタイプ)。
Strauss & Schoenwaelder Experimental [Page 45] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[45ページ]RFC3780SMIng2004年5月
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.";
};
「属性にCounter32のタイプ値でデフォルト声明を使用するべきではありません。」 「RFC2578、セクション2 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 Gauge64{ Unsigned64をタイプしてください。 記述は「非負の整数を表Gauge64がタイプするします」。(負の整数は、最大値を決して超えないのを除いて、増減して、最小値の下まで下がるかもしれません)。 最大値が2以上^64-1(18446744073709551615)であるはずがなく、最小値は0よりわずかであるはずがありません。 Gauge64の値には、モデル化される情報がそう以上であるときはいつも、最大値があります。そして、最大が評価する、モデル化される情報が、より最小値以下であるときはいつも、最小値を持っています。 「また、次にモデル化される情報が以下(上では、増加する)で最大(最小の)の値を減少させるなら、Gauge64は減少します(増加します)。」 };
typedef Counter64 {
type Unsigned64;
description
"The Counter64 type represents a non-negative integer
which monotonically increases until it reaches a
maximum value of 2^64-1 (18446744073709551615), when
it wraps around and starts increasing again from zero.
typedef Counter64、Unsigned64をタイプしてください; 「Counter64タイプは巻きつけるとき、2^64-1(18446744073709551615)の最大値に達するまで単調に増加して、再びゼロから増え始める非負の整数に表す」記述。
Counters have no defined `initial' value, and thus, a
single value of a Counter has (in general) no
information content. Discontinuities in the
monotonically increasing value normally occur at
re-initialization of the management system, and at
other times as specified in the description of an
attribute using this type. If such other times can
occur, for example, the creation of a class
instance that contains an attribute of type Counter32
at times other than re-initialization, then
a corresponding attribute should be defined, with an
カウンタには、定義された'初期'の値が全くありません、そして、その結果、Counterのただ一つの値には、情報量が全くありません(一般に)。 通常、単調に増加する値における不連続はマネージメントシステムの再初期化においてこのタイプを使用する属性の記述における指定されるとしての他の時に起こります。 他のそのような回が起こることができるなら、例えば、再初期化を除いて、時にはタイプCounter32の属性を含むクラスインスタンスの作成であり、対応する属性は定義されるべきです。
Strauss & Schoenwaelder Experimental [Page 46] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[46ページ]RFC3780SMIng2004年5月
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のタイプ値がある属性のためのアクセス声明の値は、'readonlyである'か'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.";
};
「属性にCounter64のタイプ値でデフォルト声明を使用するべきではありません。」 「RFC2578、セクション2 7.1.10」という参照。 };
typedef Opaque {
type OctetString;
status obsolete;
description
"******* THIS TYPE DEFINITION IS OBSOLETE *******
「typedef Opaque、OctetStringをタイプしてください; 状態時代遅れである、記述、」、*******この型定義は時代遅れの*******です。
The Opaque type is provided solely for
backward-compatibility, and shall not be used for
newly-defined attributes and derived types.
Opaqueタイプを唯一後方の互換性に提供されて、新たに定義された属性と派生型に使用しないものとします。
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.
Opaqueタイプは任意のASN.1構文を通過する能力をサポートします。 値は、ASN.1Basic Encoding Rulesを一連の八重奏に使用することでコード化されます。 事実上、元のASN.1価値を'ダブルで包装し'て、これはOctetStringとして順番にコード化されます。
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.";
};
「'標準'のモジュールに関する要件はOpaqueのタイプ値がどんな属性にもないかもしれなくて、またOpaqueタイプからタイプを全く得ないかもしれないということです。」 「RFC2578、セクション2 7.1.9」という参照。 };
typedef IpAddress {
type OctetString (4);
status deprecated;
description
typedef IpAddress、OctetString(4)をタイプしてください; 状態推奨しない、記述
Strauss & Schoenwaelder Experimental [Page 47] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[47ページ]RFC3780SMIng2004年5月
"******* 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のOctetStringとして表されます。
Note that the IpAddress type is present for
historical reasons.";
reference
"RFC 2578, Sections 2. and 7.1.5.";
};
「IpAddressタイプが歴史的な理由で出席していることに注意してください。」 「RFC2578、セクション2 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.
TimeTicks32タイプは時間を表す非負の整数を表します、法2^32(4294967296小数)、2回の時代の間の1秒の100分の1で。typedef TimeTicks32、Unsigned32をタイプしてください;、記述、「属性が定義されるとき、(このタイプを使用します)属性の記述は参照時代の両方を特定します」。
For example, the TimeStamp32 type (defined in this
module) is based on the TimeTicks32 type.";
reference
"RFC 2578, Sections 2. and 7.1.8.";
};
「例えば、TimeStamp32タイプ(このモジュールでは、定義される)はTimeTicks32タイプに基づいています。」 「RFC2578、セクション2 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.
TimeTicks64タイプは時間を表す非負の整数を表します、法2^64(18446744073709551616小数)、2回の時代の間の1秒の100分の1で。typedef TimeTicks64、Unsigned64をタイプしてください;、記述、「属性が定義されるとき、(このタイプを使用します)属性の記述は参照時代の両方を特定します」。
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
関連TimeTicks32属性の値はどのa特定の発生のときに起こったか。typedef TimeStamp32、TimeTicks32をタイプしてください;、記述、「いずれの記述で特定の発生を定義しなければなりません」。
Strauss & Schoenwaelder Experimental [Page 48] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[48ページ]RFC3780SMIng2004年5月
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.
このタイプを使用することで定義された属性。 特定の発生が最後の時の前に起こったとき、関連TimeTicks32属性がゼロであった、そして、TimeStamp32値はゼロです。 関連TimeTicks32属性の値が何497+日も達して、ゼロに巻きつけられるとき、これが、すべてのTimeStamp32値がゼロにリセットされるのを必要とすることに注意してください。
The associated TimeTicks32 attribute should be specified
in the description of any attribute using this type.
If no TimeTicks32 attribute has been specified, the
default scalar attribute sysUpTime is used.";
reference
"RFC 2579, Section 2.";
};
関連TimeTicks32属性は、どんな属性の記述でもこのタイプを使用することで指定されるべきです。 「TimeTicks32属性が全く指定されていないなら、デフォルトのスカラの属性sysUpTimeは使用されています。」 「RFC2579、セクション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 TimeStamp64{ TimeTicks64をタイプしてください。 「どのa特定の発生が起こったかで関連TimeTicks64の値は結果と考える」記述。 このタイプを使用することで定義されたどんな属性の記述でも特定の発生を定義しなければなりません。 特定の発生が最後の時の前に起こったとき、関連TimeTicks64属性がゼロであった、そして、TimeStamp64値はゼロです。 どんな属性の記述でもこのタイプを使用することで関連TimeTicks64属性を指定しなければなりません。 「関連属性としてTimeTicks32属性を使用してはいけません。」 };
typedef TimeInterval32 {
type Integer32 (0..2147483647);
description
"A period of time, measured in units of 0.01 seconds.
typedef TimeInterval32、Integer32(0 .2147483647)をタイプしてください; 「期間であって、0.01秒の単位で測定された」記述。
The TimeInterval32 type uses Integer32 rather than
Unsigned32 for compatibility with RFC 2579.";
reference
"RFC 2579, Section 2.";
};
「TimeInterval32タイプはRFC2579との互換性にUnsigned32よりむしろInteger32を使用します。」 「RFC2579、セクション2」という参照。 };
typedef TimeInterval64 {
type Integer64;
description
"A period of time, measured in units of 0.01 seconds.
Note that negative values are allowed.";
};
typedef TimeInterval64{ Integer64をタイプしてください。 「期間であって、0.01秒の単位で測定された」記述。 「負の数が許容されていることに注意してください。」 };
Strauss & Schoenwaelder Experimental [Page 49] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[49ページ]RFC3780SMIng2004年5月
typedef DateAndTime {
type OctetString (8 | 11);
default 0x0000000000000000000000;
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
description
"A date-time specification.
typedef DateAndTime、タイプOctetString(8|11); デフォルト0x0000000000000000000000; 「1a1d: 2d-1d-1d、1d:1d:1d.1d、1d」をフォーマットしてください; 記述「A日付-時間仕様。」
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
分野の八重奏コンテンツ範囲----- ------ -------- ----- 1 1-2年*0。65535 2 3カ月1。12 | 0 3 4の1日目。31 | 0 4 5時間0。23 5 6分0。59 6 7秒0。60 (閏秒の使用60)7 8のデシ秒の0。UTC*0からUTC'+'/'--'9 10時間からの9 8 9方向。UTC0から13 10 11分。59
* Notes:
- the value of year is in big-endian encoding
- daylight saving time in New Zealand is +13
* 注意: - ビッグエンディアンコード化には年の値があります--ニュージーランドの夏時間は+13です。
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would
be displayed as:
例えば、以下として東部夏時間の午後1時30分15秒の1992年5月26日火曜日を表示するでしょう。
1992-5-26,13:30:15.0,-4:0
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.";
};
「2スペシャルが評価する、8か11では、どんなバイトも未知の日付-時間仕様を指示しない、」 「RFC2579、セクション2」という参照。 };
typedef TruthValue {
type Enumeration (true(1), false(2));
description
"Represents a boolean value.";
reference
"RFC 2579, Section 2.";
};
記述は「ブール値を表します」。typedef TruthValue、Enumerationをタイプしてください、(本当の(1)、誤った(2)); 「RFC2579、セクション2」に参照をつけてください、。
typedef PhysAddress {
typedef PhysAddress
Strauss & Schoenwaelder Experimental [Page 50] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[50ページ]RFC3780SMIng2004年5月
type OctetString;
format "1x:";
description
"Represents media- or physical-level addresses.";
reference
"RFC 2579, Section 2.";
};
OctetStringをタイプしてください。 形式、「1x:」、。 記述は「メディアか物理的なレベルアドレスを代表します」。 「RFC2579、セクション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.";
};
OctetString(6); 書式をタイプしてください。記述は「すなわち、まるで802.5(他の802.xプロトコルと対照して)が、最初にMACアドレスが伝えられた最上位ビットであることを必要としますが、最初にそれが伝えられた最下位ビットであるかのようにIEEE 802.1aによって定義された'正準な'オーダーに表されたIEEE802MACアドレスを表します」。typedef MacAddress、「1x:」 ; 「RFC2579、セクション2」に参照をつけてください、。
// The DisplayString definition below does not impose a size
// restriction and is thus not the same as the DisplayString
// definition in RFC 2579. The DisplayString255 definition is
// provided for mapping purposes.
以下でのDisplayString定義がする//は、サイズ//制限を課さないで、またその結果、RFC2579とのDisplayString//定義と同じではありません。 DisplayString255定義は目的を写像しながら備えられた//です。
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、タイプOctetString; 形式"1a"; 記述は「4、10-11RFCページで854定義されるようにNVT ASCII文字の組から取られた文字情報を表します」。
To summarize RFC 854, the NVT ASCII repertoire specifies:
RFC854をまとめるために、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、バーモント、およびFFはRFC854で特別な意味を指定させます。
- the other 25 codes have no standard interpretation
- 他の25のコードには、どんな標準の解釈もありません。
- the sequence 'CR LF' means newline
- 系列'CR LF'はニューラインを意味します。
- the sequence 'CR NUL' means carriage-return
- 系列'CR NUL'は復帰を意味します。
Strauss & Schoenwaelder Experimental [Page 51] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[51ページ]RFC3780SMIng2004年5月
- an 'LF' not preceded by a 'CR' means moving to the
same column on the next line.
- 'CR'によって先行されなかった'LF'は、次の系列に関する同じコラムに移行することを意味します。
- 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、DisplayString(0 .255)をタイプしてください;、記述、「255のキャラクタどんな属性の最大の長さも定義されているこの構文を使用するDisplayStringは長さで255のキャラクタを超えないかもしれません」。
The DisplayString255 type has the same semantics as the
DisplayString textual convention defined in RFC 2579.";
reference
"RFC 2579, Section 2.";
};
「DisplayString255タイプには、RFC2579で定義されたDisplayStringの原文のコンベンションと同じ意味論があります。」 「RFC2579、セクション2」という参照。 };
// The Utf8String and Utf8String255 definitions below facilitate
// internationalization. The definition is consistent with the
// definition of SnmpAdminString in RFC 2571.
//、Utf8StringとUtf8String255定義下は//国際化を容易にします。 定義はRFC2571とのSnmpAdminStringの//定義と一致しています。
typedef Utf8String {
type OctetString;
format "65535t"; // is there a better way ?
description
"A human readable string represented using the ISO/IEC IS
10646-1 character set, encoded as an octet string using
the UTF-8 transformation format described in RFC 3629.
typedef Utf8String、タイプOctetString; 形式、「65535 t」; //がそこにより良い方法であります--「人間の読み込み可能なストリングはUTF-8変換形式を使用する八重奏ストリングが中でRFC3629について説明したとき10646-1 文字集合であり、コード化されたISO/IECを使用することで表した」記述。
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規格の修正で時々加えられるので、0×00000000から0x7fffffffまであらゆるコード・ポイントに遭遇するように実装を準備しなければなりません。 コード・ポイントの有効な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.
主であるか引きずっている余白の使用は避けられるべきです。
Strauss & Schoenwaelder Experimental [Page 52] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[52ページ]RFC3780SMIng2004年5月
For code points not directly supported by user interface
hardware or software, an alternative means of entry and
display, such as hexadecimal, may be provided.
ユーザーインタフェースハードウェアかソフトウェアによって直接サポートされなかったコード・ポイントにおいて、エントリーの代替の手段と16進などのディスプレイを提供するかもしれません。
For information encoded in 7-bit US-ASCII, the UTF-8
encoding is identical to the US-ASCII encoding.
7ビットの米国-ASCIIでコード化された情報に関しては、UTF-8コード化は米国-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は1キャラクタ/コード・ポイントを表すために複数のバイトを必要とするかもしれません。 したがって、八重奏における、Utf8Stringの長さはコード化されたキャラクタの数と異なっているかもしれません。 「同様に、サイズ規制はコード化で代理をされたキャラクタの数ではなく、コード化された八重奏の数について言及します。」 };
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.";
};
typedef Utf8String255{ Utf8Stringをタイプしてください。(0。255); 形式、「255t」。 記述「255の八重奏の最大の長さがあるA Utf8String。」 「Utf8Stringのサイズがキャラクタではなく、八重奏で測定されることに注意してください。」 };
identity null {
description
"An identity used to represent null pointer values.";
};
アイデンティティヌル、「アイデンティティは空ポインタ値を表すのに使用した」記述、。
};
};
Appendix B. SMIng ABNF Grammar
付録B.SMIng ABNF文法
The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF) [RFC2234].
SMIng文法はAugmented BN記法(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. ;;
;; ;; sming.abnf--ABNF記法(RFC2234)によるSMIng文法。 ;; ;; @(#)$イド: sming.abnf、v1.33 2003/10/23の19:31:55strauss Expドル。 ;; Copyright(C)インターネット協会(2004)。 All rights reserved。 ;;
smingFile = optsep *(moduleStatement optsep)
smingFileはoptsep*と等しいです。(moduleStatement optsep)
;; ;; Statement rules.
;; ;; 声明は統治されます。
Strauss & Schoenwaelder Experimental [Page 53] RFC 3780 SMIng May 2004
ストラウスとSchoenwaelderの実験的な[53ページ]RFC3780SMIng2004年5月
;;
;;
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)organizationStatement stmtsep contactStatement stmtsep descriptionStatement stmtsep*1(referenceStatement stmtsep)1*(revisionStatement stmtsep)*(extensionStatement stmtsep)*(typedefStatement stmtsep)*(identityStatement stmtsep)*(classStatement stmtsep)」」optsepと等しい」;、」
extensionStatement = extensionKeyword sep lcIdentifier optsep
"{" stmtsep
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
*1(abnfStatement stmtsep)
"}" optsep ";"
「extensionStatementはextensionKeyword sep lcIdentifier optsep「「stmtsep statusStatement stmtsep descriptionStatement stmtsep*1(referenceStatement stmtsep)*1(abnfStatement stmtsep)」」optsepと等しい」;、」
typedefStatement = typedefKeyword sep ucIdentifier optsep
"{" stmtsep
typedefTypeStatement stmtsep
*1(defaultStatement stmtsep)
*1(formatStatement stmtsep)
*1(unitsStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
「typedefStatementはtypedefKeyword 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 ";"
「identityStatementはidentityStmtKeyword sep lcIdentifier optsep「「stmtsep*1(parentStatement stmtsep)statusStatement stmtsep descriptionStatement stmtsep*1(referenceStatement stmtsep)」」optsepと等しい」;、」
classStatement = classKeyword sep ucIdentifier optsep
"{" stmtsep
*1(extendsStatement stmtsep)
*(attributeStatement stmtsep)
*1(uniqueStatement stmtsep)
classStatement = classKeyword sep ucIdentifier optsep "{" stmtsep *1(extendsStatement stmtsep) *(attributeStatement stmtsep) *1(uniqueStatement stmtsep)
Strauss & Schoenwaelder Experimental [Page 54] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 54] RFC 3780 SMIng May 2004
*(eventStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
*(eventStatement stmtsep) statusStatement stmtsep descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
attributeStatement = attributeKeyword sep
lcIdentifier optsep
"{" stmtsep
typeStatement stmtsep
*1(accessStatement stmtsep)
*1(defaultStatement stmtsep)
*1(formatStatement stmtsep)
*1(unitsStatement stmtsep)
statusStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
attributeStatement = attributeKeyword 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 descriptionStatement stmtsep *1(referenceStatement stmtsep) "}" optsep ";"
importStatement = importKeyword sep ucIdentifier optsep
"(" optsep
identifierList optsep
")" optsep ";"
importStatement = importKeyword sep ucIdentifier optsep "(" optsep identifierList 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 ";"
extendsStatement = extendsKeyword sep qucIdentifier optsep ";"
Strauss & Schoenwaelder Experimental [Page 55] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 55] RFC 3780 SMIng May 2004
dateStatement = dateKeyword sep date optsep ";"
dateStatement = dateKeyword sep date optsep ";"
organizationStatement = organizationKeyword sep text optsep ";"
organizationStatement = organizationKeyword sep text optsep ";"
contactStatement = contactKeyword sep text optsep ";"
contactStatement = contactKeyword sep text optsep ";"
formatStatement = formatKeyword sep format optsep ";"
formatStatement = formatKeyword sep format optsep ";"
unitsStatement = unitsKeyword sep units optsep ";"
unitsStatement = unitsKeyword sep units optsep ";"
statusStatement = statusKeyword sep status optsep ";"
statusStatement = statusKeyword 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 ";"
descriptionStatement = descriptionKeyword 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
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)
refinedType = qucIdentifier *1(optsep anySpec)
anySpec = pointerSpec / numberSpec / floatSpec
anySpec = pointerSpec / numberSpec / floatSpec
pointerSpec = "(" optsep qlcIdentifier optsep ")"
pointerSpec = "(" optsep qlcIdentifier optsep ")"
Strauss & Schoenwaelder Experimental [Page 56] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 56] RFC 3780 SMIng May 2004
numberSpec = "(" optsep numberElement
*furtherNumberElement
optsep ")"
numberSpec = "(" optsep numberElement *furtherNumberElement optsep ")"
furtherNumberElement = optsep "|" optsep numberElement
furtherNumberElement = optsep "|" optsep numberElement
numberElement = signedNumber *1numberUpperLimit
numberElement = signedNumber *1numberUpperLimit
numberUpperLimit = optsep ".." optsep signedNumber
numberUpperLimit = optsep ".." optsep signedNumber
floatSpec = "(" optsep floatElement
*furtherFloatElement
optsep ")"
floatSpec = "(" optsep floatElement *furtherFloatElement optsep ")"
furtherFloatElement = optsep "|" optsep floatElement
furtherFloatElement = optsep "|" optsep floatElement
floatElement = floatValue *1floatUpperLimit
floatElement = floatValue *1floatUpperLimit
floatUpperLimit = optsep ".." optsep floatValue
floatUpperLimit = optsep ".." 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 number optsep ")"
namedSignedNumberSpec = "(" optsep namedSignedNumberList optsep ")"
namedSignedNumberSpec = "(" optsep namedSignedNumberList optsep ")"
namedSignedNumberList = namedSignedNumberItem
*(optsep "," optsep
namedSignedNumberItem)
namedSignedNumberList = namedSignedNumberItem *(optsep "," optsep namedSignedNumberItem)
namedSignedNumberItem = lcIdentifier optsep "(" optsep signedNumber
optsep ")"
namedSignedNumberItem = lcIdentifier optsep "(" optsep signedNumber optsep ")"
identifierList = identifier
*(optsep "," optsep identifier)
identifierList = identifier *(optsep "," optsep identifier)
qIdentifierList = qIdentifier
*(optsep "," optsep qIdentifier)
qIdentifierList = qIdentifier *(optsep "," optsep qIdentifier)
qlcIdentifierList = qlcIdentifier
*(optsep "," optsep qlcIdentifier)
qlcIdentifierList = qlcIdentifier *(optsep "," optsep qlcIdentifier)
bitsValue = "(" optsep bitsList optsep ")"
bitsValue = "(" optsep bitsList optsep ")"
Strauss & Schoenwaelder Experimental [Page 57] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 57] RFC 3780 SMIng May 2004
bitsList = *1(lcIdentifier
*(optsep "," optsep lcIdentifier))
bitsList = *1(lcIdentifier *(optsep "," optsep lcIdentifier))
;; ;; Other basic rules. ;;
;; ;; Other basic rules. ;;
identifier = ucIdentifier / lcIdentifier
identifier = ucIdentifier / lcIdentifier
qIdentifier = qucIdentifier / qlcIdentifier
qIdentifier = qucIdentifier / qlcIdentifier
ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-")
ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-")
qucIdentifier = *1(ucIdentifier "::") ucIdentifier
qucIdentifier = *1(ucIdentifier "::") ucIdentifier
lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-")
lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-")
qlcIdentifier = *1(ucIdentifier "::") lcIdentifier
qlcIdentifier = *1(ucIdentifier "::") lcIdentifier
attrIdentifier = lcIdentifier *("." lcIdentifier)
attrIdentifier = lcIdentifier *("." lcIdentifier)
qattrIdentifier = *1(ucIdentifier ".") attrIdentifier
qattrIdentifier = *1(ucIdentifier ".") attrIdentifier
cattrIdentifier = ucIdentifier "."
lcIdentifier *("." lcIdentifier)
cattrIdentifier = ucIdentifier "." lcIdentifier *("." lcIdentifier)
qcattrIdentifier = qucIdentifier "."
lcIdentifier *("." lcIdentifier)
qcattrIdentifier = qucIdentifier "." lcIdentifier *("." lcIdentifier)
text = textSegment *(optsep textSegment)
text = textSegment *(optsep textSegment)
textSegment = DQUOTE *textAtom DQUOTE
; See Section 4.2.
textSegment = DQUOTE *textAtom DQUOTE ; See Section 4.2.
textAtom = textVChar / HTAB / SP / lineBreak
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 ; always in UTC
format = textSegment
format = textSegment
units = textSegment
units = textSegment
anyValue = bitsValue /
signedNumber /
hexadecimalNumber /
anyValue = bitsValue / signedNumber / hexadecimalNumber /
Strauss & Schoenwaelder Experimental [Page 58] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 58] RFC 3780 SMIng May 2004
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.
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)
objectIdentifier = (qlcIdentifier / subid "." subid) *127("." subid)
subid = decimalNumber
subid = decimalNumber
number = hexadecimalNumber / decimalNumber
number = hexadecimalNumber / decimalNumber
negativeNumber = "-" decimalNumber
negativeNumber = "-" decimalNumber
signedNumber = number / negativeNumber
signedNumber = number / negativeNumber
decimalNumber = "0" / (nonZeroDigit *DIGIT)
decimalNumber = "0" / (nonZeroDigit *DIGIT)
zeroDecimalNumber = 1*DIGIT
zeroDecimalNumber = 1*DIGIT
hexadecimalNumber = %x30 %x78 ; "0x" with x only lower-case
1*(HEXDIG HEXDIG)
hexadecimalNumber = %x30 %x78 ; "0x" with x only lower-case 1*(HEXDIG HEXDIG)
floatValue = neginfKeyword /
posinfKeyword /
snanKeyword /
qnanKeyword /
signedNumber "." zeroDecimalNumber
*1("E" ("+"/"-") zeroDecimalNumber)
floatValue = neginfKeyword / posinfKeyword / snanKeyword / qnanKeyword / signedNumber "." zeroDecimalNumber *1("E" ("+"/"-") zeroDecimalNumber)
;; ;; Rules to skip unknown statements ;; with arbitrary arguments and blocks. ;;
;; ;; Rules to skip unknown statements ;; with arbitrary arguments and blocks. ;;
Strauss & Schoenwaelder Experimental [Page 59] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 59] RFC 3780 SMIng May 2004
unknownStatement = unknownKeyword optsep *unknownArgument
optsep ";"
unknownStatement = unknownKeyword optsep *unknownArgument optsep ";"
unknownArgument = ("(" optsep unknownList optsep ")") /
("{" optsep *unknownStatement optsep "}") /
qucIdentifier /
anyValue /
anySpec
unknownArgument = ("(" optsep unknownList optsep ")") / ("{" optsep *unknownStatement optsep "}") / qucIdentifier / anyValue / anySpec
unknownList = namedNumberList /
qIdentifierList
unknownList = namedNumberList / qIdentifierList
unknownKeyword = lcIdentifier
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. ;;
;; ;; 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
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
Strauss & Schoenwaelder Experimental [Page 60] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 60] RFC 3780 SMIng May 2004
abnfKeyword = %x61 %x62 %x6E %x66
abnfKeyword = %x61 %x62 %x6E %x66
;; Base type keywords.
;; Base type keywords.
OctetStringKeyword = %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69
%x6E %x67
PointerKeyword = %x50 %x6F %x69 %x6E %x74 %x65 %x72
ObjectIdentifierKeyword = %x4F %x62 %x6A %x65 %x63 %x74 %x49 %x64
%x65 %x6E %x74 %x69 %x66 %x69 %x65 %x72
Integer32Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x33 %x32
Unsigned32Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33
%x32
Integer64Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34
Unsigned64Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36
%x34
Float32Keyword = %x46 %x6C %x6F %x61 %x74 %x33 %x32
Float64Keyword = %x46 %x6C %x6F %x61 %x74 %x36 %x34
Float128Keyword = %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38
BitsKeyword = %x42 %x69 %x74 %x73
EnumerationKeyword = %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69
%x6F %x6E
OctetStringKeyword = %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69 %x6E %x67 PointerKeyword = %x50 %x6F %x69 %x6E %x74 %x65 %x72 ObjectIdentifierKeyword = %x4F %x62 %x6A %x65 %x63 %x74 %x49 %x64 %x65 %x6E %x74 %x69 %x66 %x69 %x65 %x72 Integer32Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x33 %x32 Unsigned32Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33 %x32 Integer64Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34 Unsigned64Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36 %x34 Float32Keyword = %x46 %x6C %x6F %x61 %x74 %x33 %x32 Float64Keyword = %x46 %x6C %x6F %x61 %x74 %x36 %x34 Float128Keyword = %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38 BitsKeyword = %x42 %x69 %x74 %x73 EnumerationKeyword = %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69 %x6F %x6E
;; Status keywords.
;; Status keywords.
currentKeyword = %x63 %x75 %x72 %x72 %x65 %x6E %x74
deprecatedKeyword = %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65
%x64
obsoleteKeyword = %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65
currentKeyword = %x63 %x75 %x72 %x72 %x65 %x6E %x74 deprecatedKeyword = %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65 %x64 obsoleteKeyword = %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65
;; Access keywords.
;; Access keywords.
eventonlyKeyword = %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79 readonlyKeyword = %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79 readwriteKeyword = %x72 %x65 %x61 %x64 %x77 %x72 %x69 %x74 %x65
eventonlyKeyword = %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79 readonlyKeyword = %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79 readwriteKeyword = %x72 %x65 %x61 %x64 %x77 %x72 %x69 %x74 %x65
;; Special floating point values' keywords.
;; Special floating point values' keywords.
neginfKeyword = %x6E %x65 %x67 %x69 %x6E %x66 posinfKeyword = %x70 %x6F %x73 %x69 %x6E %x66 snanKeyword = %x73 %x6E %x61 %x6E qnanKeyword = %x71 %x6E %x61 %x6E
neginfKeyword = %x6E %x65 %x67 %x69 %x6E %x66 posinfKeyword = %x70 %x6F %x73 %x69 %x6E %x66 snanKeyword = %x73 %x6E %x61 %x6E qnanKeyword = %x71 %x6E %x61 %x6E
;; ;; Some low level rules. ;; These tokens are typically skipped by the lexical analyzer. ;;
;; ;; Some low level rules. ;; These tokens are typically skipped by the lexical analyzer. ;;
Strauss & Schoenwaelder Experimental [Page 61] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 61] RFC 3780 SMIng May 2004
sep = 1*(comment / lineBreak / WSP)
; unconditional separator
sep = 1*(comment / lineBreak / WSP) ; unconditional separator
optsep = *(comment / lineBreak / WSP)
optsep = *(comment / lineBreak / WSP)
stmtsep = *(comment /
lineBreak /
WSP /
unknownStatement)
stmtsep = *(comment / lineBreak / WSP / unknownStatement)
comment = "//" *(WSP / VCHAR) lineBreak
comment = "//" *(WSP / VCHAR) lineBreak
lineBreak = CRLF / LF
lineBreak = CRLF / LF
;; ;; Encoding specific rules. ;;
;; ;; Encoding specific rules. ;;
textVChar = %x21 / %x23-7E
; any VCHAR except DQUOTE
textVChar = %x21 / %x23-7E ; any VCHAR except DQUOTE
ucAlpha = %x41-5A
ucAlpha = %x41-5A
lcAlpha = %x61-7A
lcAlpha = %x61-7A
nonZeroDigit = %x31-39
nonZeroDigit = %x31-39
;; ;; RFC 2234 core rules. ;;
;; ;; RFC 2234 core rules. ;;
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
CR = %x0D
; carriage return
CR = %x0D ; carriage return
CRLF = CR LF
; Internet standard newline
CRLF = CR LF ; Internet standard newline
DIGIT = %x30-39
; 0-9
DIGIT = %x30-39 ; 0-9
DQUOTE = %x22
; " (Double Quote)
DQUOTE = %x22 ; " (Double Quote)
HEXDIG = DIGIT /
%x61 / %x62 / %x63 / %x64 / %x65 / %x66
HEXDIG = DIGIT / %x61 / %x62 / %x63 / %x64 / %x65 / %x66
Strauss & Schoenwaelder Experimental [Page 62] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 62] RFC 3780 SMIng May 2004
; only lower-case a..f
; only lower-case a..f
HTAB = %x09
; horizontal tab
HTAB = %x09 ; horizontal tab
LF = %x0A
; linefeed
LF = %x0A ; linefeed
SP = %x20
; space
SP = %x20 ; space
VCHAR = %x21-7E
; visible (printing) characters
VCHAR = %x21-7E ; visible (printing) characters
WSP = SP / HTAB
; white space
WSP = SP / HTAB ; white space
;; End of ABNF
;; End of ABNF
Authors' Addresses
Authors' Addresses
Frank Strauss TU Braunschweig Muehlenpfordtstrasse 23 38106 Braunschweig Germany
Frank Strauss TU Braunschweig Muehlenpfordtstrasse 23 38106 Braunschweig Germany
Phone: +49 531 391 3266 EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
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. Box 750 561 28725 Bremen Germany
Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de URI: http://www.eecs.iu-bremen.de/
Phone: +49 421 200 3587 EMail: j.schoenwaelder@iu-bremen.de URI: http://www.eecs.iu-bremen.de/
Strauss & Schoenwaelder Experimental [Page 63] RFC 3780 SMIng May 2004
Strauss & Schoenwaelder Experimental [Page 63] RFC 3780 SMIng May 2004
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright (C) 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.
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.
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
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Strauss & Schoenwaelder Experimental [Page 64]
Strauss & Schoenwaelder Experimental [Page 64]
一覧
スポンサーリンク
