RFC4181 日本語訳
4181 Guidelines for Authors and Reviewers of MIB Documents. C. Heard,Ed.. September 2005. (Format: TXT=102521 bytes) (Updated by RFC4841) (Also BCP0111) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Heard, Ed. Request for Comments: 4181 September 2005 BCP: 111 Category: Best Current Practice
エド、ネットワークワーキンググループC.を聞きました。コメントのために以下を要求してください。 4181 2005年9月のBCP: 111カテゴリ: 最も良い現在の習慣
Guidelines for Authors and Reviewers of MIB Documents
MIBドキュメントの作者と評論家へのガイドライン
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents.
このメモはMIBモジュールを含むIETF標準化過程仕様の作者と評論家にガイドラインを提供します。 適切な部分は他のMIBドキュメントのレビューの基礎として使用されるかもしれません。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. General Documentation Guidelines ................................4
3.1. MIB Boilerplate Section ....................................4
3.2. Narrative Sections .........................................5
3.3. Definitions Section ........................................5
3.4. Security Considerations Section ............................5
3.5. IANA Considerations Section ................................6
3.5.1. Documents that Create a New Name Space ..............6
3.5.2. Documents that Require Assignments in
Existing Namespace(s) ...............................7
3.5.3. Documents with No IANA Requests .....................8
3.6. References Sections ........................................8
3.7. Copyright Notices ..........................................9
3.8. Intellectual Property Section .............................10
4. SMIv2 Usage Guidelines .........................................10
4.1. Module Names ..............................................10
4.2. Descriptors, TC Names, and Labels .........................10
4.3. Naming Hierarchy ..........................................11
4.4. IMPORTS Statement .........................................11
4.5. MODULE-IDENTITY Invocation ................................12
4.6. Textual Conventions and Object Definitions ................14
1. 序論…3 2. 用語…3 3. 一般ドキュメンテーションガイドライン…4 3.1. MIB決まり文句の部…4 3.2. 物語のセクション…5 3.3. 定義部…5 3.4. セキュリティ問題部…5 3.5. IANA問題部…6 3.5.1. そのCreate a New Name Spaceは記録します…6 3.5.2. そのRequire AssignmentsはExisting Namespace(s)に記録します…7 3.5.3. IANA要求のないドキュメント…8 3.6. 参照部…8 3.7. 版権情報…9 3.8. 知的所有権部…10 4. SMIv2用法ガイドライン…10 4.1. モジュール名…10 4.2. 記述子、Tc名、およびラベル…10 4.3. 階層構造を命名します…11 4.4. 声明を輸入します…11 4.5. モジュールアイデンティティ実施…12 4.6. 原文のコンベンションとオブジェクト定義…14
Heard Best Current Practice [Page 1] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[1ページ]RFC4181ガイドライン
4.6.1. Usage of Data Types ................................14
4.6.1.1. INTEGER, Integer32, Gauge32, and
Unsigned32 ................................14
4.6.1.2. Counter32 and Counter64 ...................16
4.6.1.3. CounterBasedGauge64 .......................17
4.6.1.4. OCTET STRING ..............................17
4.6.1.5. OBJECT IDENTIFIER .........................18
4.6.1.6. The BITS Construct ........................19
4.6.1.7. IpAddress .................................19
4.6.1.8. TimeTicks .................................19
4.6.1.9. TruthValue ................................19
4.6.1.10. Other Data Types .........................19
4.6.2. DESCRIPTION and REFERENCE Clauses ..................20
4.6.3. DISPLAY-HINT Clause ................................21
4.6.4. Conceptual Table Definitions .......................21
4.6.5. OID Values Assigned to Objects .....................23
4.6.6. OID Length Limitations and Table Indexing ..........24
4.7. Notification Definitions ..................................24
4.8. Compliance Statements .....................................25
4.8.1. Note Regarding These Examples and RFC 2578 .........27
4.9. Revisions to MIB Modules ..................................28
5. Acknowledgments ................................................31
6. Security Considerations ........................................32
7. IANA Considerations ............................................32
Appendix A: MIB Review Checklist .................................33
Appendix B: Commonly Used Textual Conventions ....................34
Appendix C: Suggested Naming Conventions .........................36
Appendix D: Suggested OID Layout .................................37
Normative References ..............................................38
Informative References ............................................40
4.6.1. データ型の用法…14 4.6.1.1. 整数、Integer32、Gauge32、およびUnsigned32…14 4.6.1.2. Counter32とCounter64…16 4.6.1.3. CounterBasedGauge64…17 4.6.1.4. 八重奏ストリング…17 4.6.1.5. 物の識別子…18 4.6.1.6. ビット構造物…19 4.6.1.7. IpAddress…19 4.6.1.8. TimeTicks…19 4.6.1.9. TruthValue…19 4.6.1.10. 他のデータ型…19 4.6.2. 記述と参照節…20 4.6.3. 表示ヒント節…21 4.6.4. 概念的なテーブル定義…21 4.6.5. 物に割り当てられたOID値…23 4.6.6. OID長さの制限とテーブルインデックス…24 4.7. 通知定義…24 4.8. 承諾声明…25 4.8.1. これらの例を見なして、RFC2578に注意してください…27 4.9. MIBモジュールへの改正…28 5. 承認…31 6. セキュリティ問題…32 7. IANA問題…32 付録A: MIBはチェックリストを再検討します…33 付録B: 一般的に、原文のコンベンションを使用します…34 付録C: 命名規則は示しました…36 付録D: OIDレイアウトを示します…37 標準の参照…38 有益な参照…40
Heard Best Current Practice [Page 2] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[2ページ]RFC4181ガイドライン
1. Introduction
1. 序論
Some time ago, the IESG instituted a policy of requiring expert review of IETF standards-track specifications containing MIB modules. These reviews were established to ensure that such specifications follow established IETF documentation practices and that the MIB modules they contain meet certain generally accepted standards of quality, including (but not limited to) compliance with all syntactic and semantic requirements of SMIv2 (STD 58) [RFC2578] [RFC2579] [RFC2580] that are applicable to "standard" MIB modules. The purpose of this memo is to document the guidelines that are followed in such reviews.
先頃、IESGはMIBモジュールを含むIETF標準化過程仕様の専門のレビューを必要とする方針を設けました。 これらのレビューはそのような仕様が確立したIETFドキュメンテーション習慣に続いて、それらが含むMIBモジュールが品質のある一般に、受け入れられた規格を満たすのを保証するために確立されました、「標準」のMIBモジュールに適切なSMIv2(STD58)[RFC2578][RFC2579][RFC2580]のすべての構文的、そして、意味的な要件への(他)コンプライアンスを含んでいて。 このメモの目的はそのようなレビューで従われているガイドラインを記録することです。
Please note that the guidelines in this memo are not intended to alter requirements or prohibitions (in the sense of "MUST", "MUST NOT", "SHALL", or "SHALL NOT" as defined in RFC 2119 [RFC2119]) of existing BCPs or Internet Standards except where those requirements or prohibitions are ambiguous or contradictory. In the exceptional cases where ambiguities or contradictions exist, this memo documents the current generally accepted interpretation. In certain instances, the guidelines in this memo do alter recommendations (in the sense of "SHOULD", "SHOULD NOT", "RECOMMENDED", or "NOT RECOMMENDED" as defined in RFC 2119) of existing BCPs or Internet Standards. This has been done where practical experience has shown that the published recommendations are suboptimal. In addition, this memo provides guidelines for the selection of certain SMIv2 options (in the sense of "MAY" or "OPTIONAL" as defined in RFC 2119) in cases where there is a consensus on a preferred approach.
または、このメモによるガイドラインが要件か禁止を変更することを意図しない、(“MUST"の感覚、「必須NOT」、“SHALL"で「」 どこを除いて、既存のBCPsかインターネット規格のRFC2119年[RFC2119)に定義されるように、それらの要件か禁止が、あいまいであるか、または相容れなくなるだろうか。 あいまいさか矛盾が存在する例外的な場合では、このメモは現在の一般に、受け入れられた解釈を記録します。 ある例では、このメモによるガイドラインが推薦を変更する、(“SHOULD"の意味で「」 既存のBCPsかインターネット規格のRFC2119年に)定義されるとして「お勧め」、または「お勧めでないべきではありません」。 実用的な経験が発行された推薦が準最適であることを示したところでこれをしました。 さらに、このメモは好ましい方法に関するコンセンサスがある場合における、あるSMIv2オプション(RFC2119での定義されるとして「5月」か「任意」の意味における)の品揃えのためのガイドラインを提供します。
Although some of the guidelines in this memo are not applicable to non-standards track or non-IETF MIB documents, authors and reviewers of those documents should consider using the ones that do apply.
このメモによるガイドラインのいくつかが非標準化過程の、または、非IETF MIBのドキュメントに適切ではありませんが、それらのドキュメントの作者と評論家は、適用されるものを使用すると考えるべきです。
Reviewers and authors need to be aware that some of the guidelines in this memo do not apply to MIB modules that have been translated to SMIv2 from SMIv1 (STD 16) [RFC1155] [RFC1212] [RFC1215].
評論家と作者は、このメモによるガイドラインのいくつかがSMIv1(STD16)[RFC1155][RFC1212][RFC1215]からSMIv2に翻訳されたMIBモジュールに適用されないのを意識している必要があります。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when used in the guidelines in this memo, are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTはこのメモによるガイドラインで使用されるとRFC2119[RFC2119]で説明されるように解釈されることであるべきですか?
The terms "MIB module" and "information module" are used interchangeably in this memo. As used here, both terms refer to any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578].
用語「MIBモジュール」と「情報モジュール」はこのメモで互換性を持って使用されます。 ここで同じくらい使用されていて、両方の用語はRFC2578[RFC2578]のセクション3で定義された3つのタイプの情報モジュールのいずれにも言及します。
Heard Best Current Practice [Page 3] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[3ページ]RFC4181ガイドライン
The term "standard", when it appears in quotes, is used in the same sense as in the SMIv2 documents [RFC2578] [RFC2579] [RFC2580]. In particular, it is used to refer to the requirements that those documents levy on "standard" modules or "standard" objects.
「標準」という用語(それは引用文に現れる)はSMIv2ドキュメント[RFC2578][RFC2579][RFC2580]のように同じ意味で使用されます。 特に、それは、それらのドキュメントが「標準」のモジュールか「標準」の物に徴収する要件について言及するのに使用されます。
3. General Documentation Guidelines
3. 一般ドキュメンテーションガイドライン
In general, IETF standards-track specifications containing MIB modules are subject to the same requirements as IETF standards-track RFCs (see [RFC2223bis]), although there are some differences. In particular, since the version under review will be an Internet-Draft, the notices on the front page MUST comply with the requirements of http://www.ietf.org/ietf/1id-guidelines.txt and not with those of [RFC2223bis]. In addition, since the specification under review is expected to be submitted to the IESG, it MUST comply with certain requirements that do not necessarily apply to RFCs; see http://www.ietf.org/ID-Checklist.html for details.
一般に、MIBモジュールを含むIETF標準化過程仕様はIETF標準化過程と同じ要件を条件としたRFCs([RFC2223bis]を見る)です、いくつかの違いがありますが。 レビュー中のバージョンがインターネット草稿になるので、特に、第一面に関する通知は[RFC2223bis]のものではなく、 http://www.ietf.org/ietf/1id-guidelines.txt の要件に従わなければなりません。 さらに、レビュー中の仕様がIESGに提出すると予想されて、必ずRFCsに適用されるというわけではないある要件に従わなければなりません。 詳細に関して http://www.ietf.org/ID-Checklist.html を見てください。
Section 4 of [RFC2223bis] lists the sections that may exist in an RFC. Sections from the abstract onward may also be present in an Internet-Draft; see http://www.ietf.org/ID-Checklist.html. The "body of memo" is always required, and in a MIB document MUST contain at least the following:
[RFC2223bis]のセクション4はRFCに存在するかもしれないセクションを記載します。 要約からのセクション、また、前方へ、インターネット草稿で存在しているかもしれません。 http://www.ietf.org/ID-Checklist.html を見てください。 「メモのボディー」は、いつも必要であり、MIBドキュメントに少なくとも以下を含まなければなりません:
o MIB boilerplate section
o MIB決まり文句の部
o Narrative sections
o 物語のセクション
o Definitions section
o 定義部
o Security Considerations section
o セキュリティConsiderations部
o IANA Considerations section
o IANA Considerations部
o References section
o 参照部
Section-by-section guidelines follow.
セクションのそばのセクションガイドラインは従います。
3.1. MIB Boilerplate Section
3.1. MIB決まり文句の部
This section MUST contain a verbatim copy of the latest approved Internet-Standard Management Framework boilerplate, which is available on-line at http://www.ops.ietf.org/mib-boilerplate.html.
このセクションは http://www.ops.ietf.org/mib-boilerplate.html にオンラインで最新の承認されたインターネット標準のManagement Frameworkの決まり文句の逐語的なコピーを含まなければなりません。(決まり文句は利用可能です)。
Heard Best Current Practice [Page 4] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[4ページ]RFC4181ガイドライン
3.2. Narrative Sections
3.2. 物語のセクション
The narrative part MUST include an overview section that describes the scope and field of application of the MIB modules defined by the specification and that specifies the relationship (if any) of these MIB modules to other standards, particularly to standards containing other MIB modules. The narrative part SHOULD include one or more sections to briefly describe the structure of the MIB modules defined in the specification.
物語の部分は仕様で定義されたMIBモジュールの範囲と応用分野について説明して、これらのMIBモジュールの関係(もしあれば)を他の規格に指定する概観部を含まなければなりません、特に他のMIBモジュールを含む規格に。 物語のパートSHOULDは、簡潔に仕様に基づき定義されたMIBモジュールの構造について説明するために1つ以上のセクションを含んでいます。
If the MIB modules defined by the specification import definitions from other MIB modules (except for those defined in the SMIv2 documents [RFC2578] [RFC2579] [RFC2580]) or are always implemented in conjunction with other MIB modules, then those facts MUST be noted in the overview section, as MUST any special interpretations of objects in other MIB modules. For instance, so-called media-specific MIB modules are always implemented in conjunction with the IF-MIB [RFC2863] and are REQUIRED to document how certain objects in the IF-MIB are used. In addition, media-specific MIB modules that rely on the ifStackTable [RFC2863] and the ifInvStackTable [RFC2864] to maintain information regarding configuration and multiplexing of interface sublayers MUST contain a description of the layering model.
仕様で定義されたMIBモジュールが他のMIBモジュール(SMIv2ドキュメント[RFC2578][RFC2579][RFC2580]で定義されたものを除いた)から定義を輸入するか、またはいつも他のMIBモジュールに関連して実行されるなら、概観部でそれらの事実に注意しなければなりません、他のMIBモジュールにおける、物のどんな特別な解釈でなければならないことのようにも。 に関連して例えば、いわゆるメディア特有のMIBモジュールがいつも実行される、-、MIB、[RFC2863]、ドキュメントにどれくらい確かなREQUIREDが中で反対するかということである、-、MIB、使用されます。 さらに、インタフェース副層の構成とマルチプレクシングの情報を保守するために、ifStackTable[RFC2863]とifInvStackTable[RFC2864]を当てにするメディア特有のMIBモジュールはレイヤリングモデルの記述を含まなければなりません。
3.3. Definitions Section
3.3. 定義部
This section contains the MIB module(s) defined by the specification. These MIB modules MUST be written in SMIv2 [RFC2578] [RFC2579] [RFC2580]; SMIv1 [RFC1155] [RFC1212] [RFC1215] has "Not Recommended" status [RFC3410] and is no longer acceptable in IETF MIB modules.
このセクションは仕様で定義されたMIBモジュールを含みます。 SMIv2[RFC2578][RFC2579][RFC2580]にこれらのMIBモジュールを書かなければなりません。 SMIv1[RFC1155][RFC1212][RFC1215]は状態[RFC3410]を「推薦しない」で、またもうIETF MIBモジュールで許容できません。
See Section 4 for guidelines on SMIv2 usage.
SMIv2用法に関するガイドラインに関してセクション4を見てください。
3.4. Security Considerations Section
3.4. セキュリティ問題部
Each specification that defines one or more MIB modules MUST contain a section that discusses security considerations relevant to those modules. This section MUST be patterned after the latest approved template (available at http://www.ops.ietf.org/mib-security.html). In particular, writable MIB objects that could be especially disruptive if abused MUST be explicitly listed by name and the associated security risks MUST be spelled out; similarly, readable MIB objects that contain especially sensitive information or that raise significant privacy concerns MUST be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained. If there are no risks/vulnerabilities for a specific category of MIB objects, then that fact MUST be explicitly stated. Failure to mention a particular category of MIB objects will not be equated to a claim of no risks/vulnerabilities in that category;
1つ以上のMIBモジュールを定義する各仕様はそれらのモジュールに関連しているセキュリティ問題について論ずるセクションを含まなければなりません。 最新の承認されたテンプレート( http://www.ops.ietf.org/mib-security.html で利用可能な)の後にこのセクションを型に基づいて作らなければなりません。 特に、名前で乱用されるなら特に破壊的であるかもしれない書き込み可能なMIB物を明らかに記載しなければなりません、そして、関連セキュリティ危険について詳しく説明しなければなりません。 同様に、名前で明らかに特に機密の情報を含むか、または重要なプライバシーの問題を提起する読み込み可能なMIB物を記載しなければなりません、そして、感度/プライバシーの問題の理由について説明しなければなりません。 MIB物の特定のカテゴリのためのリスク/脆弱性が全くなければ、明らかにその事実を述べなければなりません。 MIB物の特定のカテゴリについて言及しないと、そのカテゴリにおける、リスク/脆弱性がないクレームと同一視されないでしょう。
Heard Best Current Practice [Page 5] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[5ページ]RFC4181ガイドライン
rather, it will be treated as an act of omission and will result in the document being returned to the author for correction. Remember that the objective is not to blindly copy text from the template, but rather to think and evaluate the risks/vulnerabilities and then state/document the result of this evaluation.
むしろ、それは、省略の行為として扱われて、修正のために作者に返されるドキュメントをもたらすでしょう。 次に、この評価の結果を目的は、盲目的にテンプレートからのテキストをコピーするのではなく、むしろリスク/脆弱性を考えて、忘れずに評価してくださいことであり、述べるか、または記録してください。
3.5. IANA Considerations Section
3.5. IANA問題部
In order to comply with IESG policy as set forth in http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is submitted to the IESG for publication MUST contain an IANA Considerations section. The requirements for this section vary depending what actions are required of the IANA.
http://www.ietf.org/ID-Checklist.html に詳しく説明されるようにIESG方針に従うために、公表のためにIESGに提出されるあらゆるインターネット草稿がIANA Considerations部を含まなければなりません。 IANAがどんな動作に要求されるかによりながら、このセクションのための要件は異なります。
3.5.1. Documents that Create a New Name Space
3.5.1. そのCreate a New Name Spaceを記録します。
If an Internet-Draft defines a new name space that is to be administered by the IANA, then the document MUST include an IANA Considerations section conforming to the guidelines set forth in RFC 2434 [RFC2434] that specifies how the name space is to be administered.
インターネット草稿がIANAによって管理されることになっている新しい名前スペースを定義するなら、ドキュメントは管理される名前スペースがことである方法を指定するRFC2434[RFC2434]に詳しく説明されたガイドラインに一致しているIANA Considerations部を含まなければなりません。
Name spaces defined by MIB documents generally consist of the range of values for some type (usually an enumerated INTEGER) defined by a TEXTUAL-CONVENTION (TC) or of a set of administratively-defined OBJECT IDENTIFIER (OID) values. In each case, the definitions are housed in stand-alone MIB modules that are maintained by the IANA. These IANA-maintained MIB modules are separate from the MIB modules defined in standards-track specifications so that new assignments can be made without having to republish a standards-track RFC. Examples of IANA-maintained MIB modules include the IANAifType-MIB (http://www.iana.org/assignments/ianaiftype-mib), which defines a name space used by the IF-MIB [RFC2863], and the IANA-RTPROTO-MIB (http://www.iana.org/assignments/ianaiprouteprotocol-mib), which defines a name space used by the IPMROUTE-STD-MIB [RFC2932].
一般に、MIBドキュメントによって定義された名前空間はTEXTUAL-CONVENTION(TC)によって定義されたタイプ(通常列挙されたINTEGER)のための値か1セットの行政上定義されたOBJECT IDENTIFIER(OID)値の範囲から成ります。 その都度、定義はIANAによって維持されるスタンドアロンのMIBモジュールで収容されます。 これらのIANAによって維持されたMIBモジュールは標準化過程RFCを再刊する必要はなくて新しい課題をすることができるように標準化過程仕様に基づき定義されたMIBモジュールから別々です。 IANAifType-MIBは使用されていた状態で名前スペースを定義します。IANAによって維持されたMIBモジュールに関する例がIANAifType-MIB( http://www.iana.org/assignments/ianaiftype-mib )を含んでいる、-、MIB、[RFC2863]、およびIANA-RTPROTO-MIB( http://www.iana.org/assignments/ianaiprouteprotocol-mib )。(そのIANA-RTPROTO-MIBはIPMROUTE-STD-MIB[RFC2932]によって使用された名前スペースを定義します)。
The current practice for such cases is to include a detailed IANA Considerations section complying with RFC 2434 in the DESCRIPTION clause of the MODULE-IDENTITY invocation in each IANA-maintained MIB module and for the IANA Considerations section of the MIB document that defines the name spaces to refer to the URLs for the relevant modules. See RFC 2932 [RFC2932] for an example. This creates a chicken-and-egg problem for MIB documents that have not yet been published as RFCs because the relevant IANA-maintained MIB modules will not yet exist. The accepted way out of this dilemma is to include the initial content of each IANA-maintained MIB module in a non-normative section of the initial issue of the document that defines the name space; for an example, see [RFC1573], which
そのような場合のための現在の習慣は関連モジュールについてURLを示すためにMODULE-IDENTITY実施の記述節でそれぞれのIANAによって維持されたMIBモジュールと空間という名前を定義するMIBドキュメントのIANA Considerations部にRFC2434に従う詳細なIANA Considerations部を含むことになっています。 例に関してRFC2932[RFC2932]を見てください。 これは関連IANAによって維持されたMIBモジュールがまだ存在していないのでRFCsとしてまだ発表されていないMIBドキュメントのための因果関係の分からない問題を作成します。 このジレンマからの受け入れられた道はスペースという名前を定義するドキュメントの初期の問題の非標準のセクションのそれぞれのIANAによって維持されたMIBモジュールの初期の内容を含むことです。 例に関しては、[RFC1573]を見てください、どれ
Heard Best Current Practice [Page 6] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[6ページ]RFC4181ガイドライン
documents the initial version of the IANAifType-MIB. That material is usually omitted from subsequent updates to the document since the IANA-maintained modules are then available on-line (cf. [RFC2863]).
IANAifType-MIBの初期のバージョンを記録します。 次に、IANAによって維持されたモジュールがオンラインで利用可能であるので、通常、その材料はその後のアップデートからドキュメントまで省略されます。(Cf。 [RFC2863]).
Reviewers of draft MIB documents to which these considerations apply MUST check that the IANA Considerations section proposed for publication in the RFC is present and contains pointers to the appropriate IANA-maintained MIB modules. Reviewers of Internet Drafts that contain the proposed initial content of IANA-maintained MIB modules MUST also verify that the DESCRIPTION clauses of the MODULE-IDENTITY invocations contain an IANA Considerations section compliant with the guidelines in RFC 2434.
これらの問題が適用される草稿MIBドキュメントの評論家は、RFCでの公表のために提案されたIANA Considerations部が存在していて、適切なIANAによって維持されたMIBモジュールにポインタを含むのをチェックしなければなりません。 また、IANAによって維持されたMIBモジュールの提案された初期の内容を含むインターネットDraftsの評論家は、MODULE-IDENTITY実施の記述節が言いなりになっているRFC2434にあるガイドラインでIANA Considerations部を含むことを確かめなければなりません。
3.5.2. Documents that Require Assignments in Existing Namespace(s)
3.5.2. そのRequire AssignmentsをExisting Namespaceに記録します。(s)
If an Internet-Draft requires the IANA to update an existing registry prior to publication as an RFC, then the IANA Considerations section in the draft MUST document that fact. MIB documents that contain the initial version of a MIB module will generally require that the IANA assign an OBJECT IDENTIFIER value for the MIB module's MODULE- IDENTITY value and possibly to make other assignments as well. Internet-Drafts containing such MIB modules MUST contain an IANA Considerations section that specifies the registries that are to be updated, the descriptors to which OBJECT IDENTIFIER values are being assigned, and the subtrees under which the values are to be allocated. The text SHOULD be crafted so that after publication it will serve to document the OBJECT IDENTIFIER assignments. For example, something along the following lines would be appropriate for an Internet-Draft containing a single MIB module with MODULE-IDENTITY descriptor powerEthernetMIB that is to be assigned a value under the 'mib-2' subtree:
インターネット草稿が、IANAが公表の前にRFCとして既存の登録をアップデートするのを必要とするなら、草稿におけるIANA Considerations部はその事実を記録しなければなりません。 一般に、MIBモジュールの初期のバージョンを含むMIBドキュメントは、IANAがMIBモジュールのMODULE- IDENTITY値、ことによるとまた、他の課題をするようにOBJECT IDENTIFIER値を割り当てるのを必要とするでしょう。 そのようなMIBモジュールを含むインターネット草稿はアップデートされることになっている登録を指定するIANA Considerations部を含まなければなりません、OBJECT IDENTIFIER値が割り当てられて、割り当てられる値がことである下位木である記述子。 テキストSHOULD、公表の後にOBJECT IDENTIFIER課題を記録するのに役立つように、作られてください。 例えば、インターネット草稿には、ものはMODULE-IDENTITY記述子powerEthernetMIBがある値が'mib-2'下位木の下で割り当てられることになっているただ一つのMIBモジュールを含むのにおいて以下のやり方で何か適切でしょう:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
MIBモジュールは本書ではSMI民数記登録に記録された以下のIANAによって割り当てられたOBJECT IDENTIFIER値を使用します:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
記述子OBJECT IDENTIFIER価値---------- -----------------------
powerEthernetMIB { mib-2 XXX }
powerEthernetMIBmib-2 XXX
Editor's Note (to be removed prior to publication): the IANA is
requested to assign a value for "XXX" under the 'mib-2' subtree
and to record the assignment in the SMI Numbers registry. When
the assignment has been made, the RFC Editor is asked to replace
"XXX" (here and in the MIB module) with the assigned value and to
remove this note.
エディタのNote(公表の前に取り除く): "XXX"のために'mib-2'下位木の下で値を割り当てて、IANAがSMI数の登録に課題を記録するよう要求されています。 課題をしたとき、"XXX"(こことMIBモジュールによる)を割り当てられた値に取り替えて、この注意を取り除くようにRFC Editorに頼みます。
Heard Best Current Practice [Page 7] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[7ページ]RFC4181ガイドライン
Note well: prior to official assignment by the IANA, a draft document MUST use placeholders (such as "XXX" above) rather than actual numbers. See Section 4.5 for an example of how this is done in a draft MIB module.
以下によく注意してください。 IANAによる公式の課題の前に、草稿ドキュメントは実数よりむしろプレースホルダ(上の"XXX"などの)を使用しなければなりません。 草稿MIBモジュールでどうこれをするかに関する例に関してセクション4.5を見てください。
3.5.3. Documents with No IANA Requests
3.5.3. IANA要求のないドキュメント
If an Internet-Draft makes no requests of the IANA, then that fact MUST be documented in the IANA Considerations section. When an Internet-Draft contains an update of a previously published MIB module, it typically will not require any action on the part of the IANA, but it may inherit an IANA Considerations section documenting existing assignments from the RFC that contains the previous version of the MIB module. In such cases, the draft MUST contain a note (to be removed prior to publication) explicitly indicating that nothing is required from the IANA. For example, a draft that contains an updated version of the POWER-ETHERNET-MIB [RFC3621] might include an IANA Considerations section such as the following:
インターネット草稿がIANAの要求を全くしないなら、IANA Considerations部でその事実を記録しなければなりません。 インターネット草稿が以前に広められたMIBモジュールのアップデートを含んでいる場合、IANA側の少しの動作も通常必要としないでしょうが、それはMIBモジュールの旧バージョンを含むRFCから既存の課題を記録するIANA Considerations部を引き継ぐかもしれません。 そのような場合、何もIANAから必要でないことを明らかに示して、草稿がメモ(公表の前に取り除く)を含まなければなりません。 例えば、POWERイーサネットMIB[RFC3621]のアップデートされたバージョンを含む草稿は以下などのIANA Considerations部を含むかもしれません:
The MIB module in this document uses the following IANA-assigned
OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
MIBモジュールは本書ではSMI民数記登録に記録された以下のIANAによって割り当てられたOBJECT IDENTIFIER値を使用します:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
記述子OBJECT IDENTIFIER価値---------- -----------------------
powerEthernetMIB { mib-2 105 }
powerEthernetMIBmib-2 105
Editor's Note (to be removed prior to publication): this draft
makes no additional requests of the IANA.
エディタのNote(公表の前に取り除く): この草稿はIANAのどんな追加要求もしません。
If an Internet-Draft makes no requests of the IANA and there are no existing assignments to be documented, then suitable text for the draft would be something along the following lines:
インターネット草稿がIANAの要求を全くしないで、また記録されるためにどんな既存の課題もなければ、草稿のための適当なテキストは以下のやり方で何かでしょう:
No IANA actions are required by this document.
IANA動作は全くこのドキュメントによって必要とされません。
3.6. References Sections
3.6. 参照部
Section 4.7f of [RFC2223bis] specifies the requirements for the references sections in an RFC; http://www.ietf.org/ID-Checklist.html imposes the same requirements on Internet-Drafts. In particular, there MUST be separate lists of normative and informative references, each in a separate section. The style SHOULD follow that of recently published RFCs.
[RFC2223bis]のセクション4.7fはRFCの参照部のための要件を指定します。 http://www.ietf.org/ID-Checklist.html は同じ要件をインターネット草稿に課します。 特に、規範的で有益な参照の別々のリストがそれぞれ別々のセクションにあるに違いありません。 スタイルSHOULDは最近発行されたRFCsのものに続きます。
The standard MIB boilerplate available at http://www.ops.ietf.org/mib-boilerplate.html includes lists of normative and informative references that MUST appear in all IETF
http://www.ops.ietf.org/mib-boilerplate.html で利用可能な標準のMIBの決まり文句はすべてのIETFに現れなければならない規範的で有益な参照のリストを含んでいます。
Heard Best Current Practice [Page 8] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[8ページ]RFC4181ガイドライン
specifications that contain MIB modules. If items from other MIB modules appear in an IMPORTS statement in the Definitions section, then the specifications containing those MIB modules MUST be included in the list of normative references. When items are imported from an IANA-maintained MIB module, the corresponding normative reference SHALL point to the on-line version of that MIB module. It is the policy of the RFC Editor that all references must be cited in the text; such citations MUST appear in the overview section where documents containing imported definitions (other than those already mentioned in the MIB boilerplate) are required to be mentioned (cf. Section 3.2).
MIBモジュールを含む仕様。 他のMIBモジュールからの商品がDefinitions部でのIMPORTS声明に現れるなら、引用規格のリストにそれらのMIBモジュールを含む仕様を含まなければなりません。 IANAによって維持されたMIBモジュールから商品を輸入するとき、対応する引用規格SHALLはそのMIBモジュールのオンラインバージョンを示します。 テキストですべてが参照をつけるRFC Editorの方針を引用しなければならないということです。 そのような引用は輸入された定義(MIBの決まり文句で既に言及されたものを除いた)を含むドキュメントが言及されなければならない概観部に現れなければなりません。(Cf。 セクション3.2).
In general, each normative reference SHOULD point to the most recent version of the specification in question.
一般に、各引用規格SHOULDは問題の仕様の最新のバージョンを示します。
3.7. Copyright Notices
3.7. 版権情報
IETF MIB documents MUST contain the copyright notices and disclaimer specified in Sections 5.4 and 5.5 of RFC 3978 [RFC3978]. Authors and reviewers MUST check to make sure that the correct year is inserted into these notices. In addition, the DESCRIPTION clause of the MODULE-IDENTITY invocation of each MIB module that will appear in the published RFC MUST contain a pointer to the copyright notices in the RFC. A template suitable for inclusion in an Internet-Draft, appropriate for MIB modules other than those that are to be maintained by the IANA, is as follows:
IETF MIBドキュメントはRFC3978[RFC3978]のセクション5.4と5.5で指定された版権情報と注意書きを含まなければなりません。 作者と評論家は、正しい年がこれらの通知に挿入されるのを念のためチェックしなければなりません。 添加、発行に現れるそれぞれのMIBモジュールのMODULE-IDENTITY実施の記述節では、RFC MUSTはRFCの版権情報にポインタを含んでいます。 インターネット草稿での包含に適したそれら以外のIANAによって維持されることになっているMIBモジュールに、適切なテンプレートは以下の通りです:
DESCRIPTION
" [ ... ]
「記述」[ ... ]
Copyright (C) The Internet Society (date). This version
of this MIB module is part of RFC yyyy; see the RFC
itself for full legal notices."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
Copyright(C)インターネット協会(日付)。 このMIBモジュールのこのバージョンはRFC yyyyの一部です。 「完全な法定の通知に関してRFC自身を見てください。」 -- RFCエド、: yyyyを実際のRFC番号に取り替えてください、そして、この注意を取り除いてください。
A template suitable for MIB modules that are to be maintained by the IANA is as follows:
IANAによって維持されることになっているMIBモジュールに適したテンプレートは以下の通りです:
DESCRIPTION
" [ ... ]
「記述」[ ... ]
Copyright (C) The Internet Society (date). The initial
version of this MIB module was published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available at:
http://www.ietf.org/copyrights/ianamib.html."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
Copyright(C)インターネット協会(日付)。 このMIBモジュールの初期のバージョンはRFC yyyyで発行されました。 完全な法定の通知に関しては、RFC自身を見てください。 補助情報は以下で利用可能であるかもしれません。 " http://www.ietf.org/copyrights/ianamib.html "。 -- RFCエド、: yyyyを実際のRFC番号に取り替えてください、そして、この注意を取り除いてください。
Heard Best Current Practice [Page 9] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[9ページ]RFC4181ガイドライン
In each case, the current year is to be inserted in place of the word "date".
その都度、本年度は「日付」という言葉に代わって挿入されることになっています。
3.8. Intellectual Property Section
3.8. 知的所有権部
Section 5 of RFC 3979 [RFC3979] contains a notice regarding intellectual property rights or other rights that must appear in all IETF RFCs. A verbatim copy of that notice SHOULD appear in every IETF MIB document.
RFC3979[RFC3979]のセクション5はすべてのIETF RFCsに現れなければならない知的所有権か他の権利に関する通知を含みます。 通知SHOULDがあらゆるIETF MIBドキュメントで見えるその逐語的なコピー。
4. SMIv2 Usage Guidelines
4. SMIv2用法ガイドライン
In general, MIB modules in IETF standards-track specifications MUST comply with all syntactic and semantic requirements of SMIv2 [RFC2578] [RFC2579] [RFC2580] that apply to "standard" MIB modules and except as noted below SHOULD comply with SMIv2 recommendations. The guidelines in this section are intended to supplement the SMIv2 documents in the following ways:
一般に、IETF標準化過程仕様によるMIBモジュールは「標準」のMIBモジュールに適用して、SHOULDの下に述べられるのを除いて、SMIv2推薦に従うSMIv2[RFC2578][RFC2579][RFC2580]のすべての構文的、そして、意味的な要件に従わなければなりません。 このセクションのガイドラインが以下の方法でSMIv2ドキュメントを補うことを意図します:
o to document the current generally accepted interpretation when
those documents contain ambiguities or contradictions;
o それらのドキュメントがあいまいさか矛盾を含むとき、一般に、電流を記録するのは解釈を受け入れました。
o to update recommendations in those documents that have been shown
by practical experience to be out-of-date or otherwise suboptimal;
o 時代遅れであるか、またはそうでなければ、準最適であるために実用的な経験で見せられたそれらのドキュメントにおける推薦をアップデートするために。
o to provide guidance in selection of SMIv2 options in cases where
there is a consensus on a preferred approach.
o 好ましい方法に関するコンセンサスがある場合における、SMIv2オプションの品揃えにおける指導を提供するために。
4.1. Module Names
4.1. モジュール名
RFC 2578 Section 3 specifies the rules for module names. Note in particular that names of "standard" modules MUST be unique, MUST follow the syntax rules in RFC 2578 Section 3, and MUST NOT be changed when a MIB module is revised (see also RFC 2578 Section 10).
RFC2578セクション3はモジュール名に規則を指定します。 「標準」のモジュールの名前がユニークでなければならなく、RFC2578セクション3のシンタックス・ルールに従わなければならなくて、MIBモジュールが改訂されているとき(また、RFC2578セクション10を見てください)変えられてはいけないことに特に注意してください。
It is RECOMMENDED that module names be mnemonic. See Appendix C for suggested naming conventions.
モジュール名が簡略記憶であることは、RECOMMENDEDです。 提案された命名規則のためにAppendix Cを見てください。
4.2. Descriptors, TC Names, and Labels
4.2. 記述子、Tc名、およびラベル
RFC 2578 Sections 3.1, 7.1.1, and 7.1.4 and RFC 2579 Section 3 recommend that descriptors and names associated with macro invocations and labels associated with enumerated INTEGER and BITS values be no longer than 32 characters, but require that they be no longer than 64 characters.
RFC2578セクション3.1、7.1.1、および7.1の.4とRFC2579セクション3 32のキャラクタより記述子、マクロ実施に関連している名前、および列挙されたINTEGERとBITS値に関連しているラベルがもうであることを推薦する、64のキャラクタより彼らがもうであることを必要であってください。
Heard Best Current Practice [Page 10] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[10ページ]RFC4181ガイドライン
Restricting descriptors, TC names, and labels to 32 characters often conflicts with the recommendation that they be mnemonic and (for descriptors and TC names) with the requirement that they be unique (see RFC 2578 Section 3.1 and RFC 2579 Section 3). The consensus of the current pool of MIB reviewers is that the SMIv2 recommendation to limit descriptors, TC names, and labels to 32 characters SHOULD be set aside in favor of promoting clarity and uniqueness and that automated tools such as MIB compilers SHOULD NOT by default generate warnings for violating that recommendation.
そして、記述子、TC名、およびラベルを32のキャラクタに制限すると彼らが簡略記憶であるという推薦がしばしば衝突する、(記述子とTC名のための) 彼らがユニークであるという(2578年のRFCセクション3.1と2579年のRFCセクション3を見ます)要件で。 MIB評論家の現在のプールのコンセンサスは明快とユニークさを促進することを支持して記述子、TC名、およびラベルを32キャラクタSHOULDに制限するというSMIv2推薦がかたわらに置かれて、MIBコンパイラSHOULD NOTなどの自動化されたツールがデフォルトでその推薦に違反するための警告を発生させるということです。
Note that violations of the 64-character limit MUST NOT be ignored; they MUST be treated as errors.
64キャラクタの限界の違反を無視してはいけないことに注意してください。 誤りとしてそれらを扱わなければなりません。
See Appendix C for suggested descriptor and TC naming conventions.
提案された記述子とTC命名規則のためにAppendix Cを見てください。
4.3. Naming Hierarchy
4.3. 階層構造を命名します。
RFC 2578 Section 4 describes the object identifier subtrees that are
maintained by IANA and specifies the usages for those subtrees. In
particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF
"standard" objects, while the experimental subtree { iso 3 6 1 3 } is
used to identify objects that are under development in the IETF. It
is REQUIRED that objects be moved from the experimental subtree to
the mgmt subtree when a MIB module enters the IETF standards track.
RFC2578セクション4は、IANAによって維持される物の識別子下位木について説明して、それらの下位木に用法を指定します。 特に、管理下位木iso3 6 1 2はIETFの「標準」の物を特定するのに使用されます、実験下位木iso3 6 1 3はIETFで開発中である物を特定するのに使用されますが。 MIBモジュールがIETF標準化過程に入るとき、物体が実験下位木から管理下位木に移されるのは、REQUIREDです。
Experience has shown that it is impractical to move objects from one subtree to another once those objects have seen large-scale use in an operational environment. Hence any object that is targeted for deployment in an operational environment MUST NOT be registered under the experimental subtree, irrespective of the standardization status of that object. The experimental subtree should be used only for objects that are intended for limited experimental deployment. Such objects typically are defined in Experimental RFCs.
それらの物がいったん運用環境における大規模な使用を見ると、経験は、1つの下位木から別のものへ物体を移すのが非実用的であることを示しました。 したがって、実験下位木の下で運用環境における展開のために狙うどんな物も登録してはいけません、その物の標準化状態の如何にかかわらず。 実験下位木は限られた実験的な展開のために意図する物にだけ使用されるべきです。 そのような物はExperimental RFCsで通常定義されます。
Note: the term "object", as used here and in RFC 2578 Section 4, is to be broadly interpreted as any construct that results in an OBJECT IDENTIFIER registration. The list of such constructs is specified in RFC 2578 Section 3.6.
以下に注意してください。 ここで使用されてRFC2578セクション4では、「物」という用語はOBJECT IDENTIFIER登録をもたらすどんな構造物としても露骨に解釈されることになっています。 そのような構造物のリストはRFC2578セクション3.6で指定されます。
4.4. IMPORTS Statement
4.4. 声明を輸入します。
RFC 2578 Section 3.2 specifies which symbols must be imported and also lists certain predefined symbols that must not be imported.
RFC2578セクション3.2は、どのシンボルを輸入しなければならないかを指定して、また、輸入してはいけないある事前に定義されたシンボルを記載します。
The general requirement is that if an external symbol other than a predefined ASN.1 type or the BITS construct is used, then it MUST be mentioned in the module's IMPORTS statement. The words "external object" in the first paragraph of that section may give the
一般的な要件は事前に定義されたASN.1タイプかBITS構造物以外の外部記号が使用されているならモジュールのIMPORTS声明でそれについて言及しなければならないということです。 そのセクションの第一節の「外部の物」という言葉は与えるかもしれません。
Heard Best Current Practice [Page 11] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[11ページ]RFC4181ガイドライン
impression that such symbols are limited to those that refer to object definitions, but that is not the case, as subsequent paragraphs should make clear.
そのようなシンボルがオブジェクト定義について言及するものに制限されるというその後のパラグラフが明らかにするべきであるようにケースでない印象。
Note that exemptions to this general requirement are granted by RFC 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in the OBJECT clause of a MODULE-COMPLIANCE statement or in the VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB compilers also grant exemptions to descriptors of notifications appearing in a VARIATION clause and to descriptors of object groups and notification groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or an INCLUDES clause, although RFC 2580 (through apparent oversight) does not mention those cases. The exemptions are sometimes seen as unhelpful because they make IMPORTS rules more complicated and inter-module dependencies less obvious than they otherwise would be. External symbols referenced by compliance statements and capabilities statements MAY therefore be listed in the IMPORTS statement; if this is done, it SHOULD be done consistently.
この一般的な要件への控除がMODULE-COMPLIANCE声明のOBJECT節かエージェント-CAPABILITIES声明のVARIATION節に現れる物に関する記述子のためにRFC2580のセクション5.4.3と6.5.2承諾されることに注意してください。 また、いくつかのMIBコンパイラがVARIATION節に現れる通知に関する記述子と、そして、MANDATORY-GROUPS節、GROUP節、またはINCLUDES節によって参照をつけられる物のグループと通知グループに関する記述子に控除を承諾します、RFC2580(見かけの見落としによる)はそれらのケースについて言及しませんが。 IMPORTS規則をより複雑にして、相互モジュールの依存をそうでなければであるだろうというほど明白でなくするので、控除は時々役に立たないとみなされます。 したがって、承諾声明と能力声明によって参照をつけられる外部記号はIMPORTS声明に記載されているかもしれません。 これは完了していて、それはSHOULDです。一貫して、します。
Finally, even though it is not forbidden by the SMI, it is considered poor style to import symbols that are not used, and standards-track MIB modules SHOULD NOT do so.
最終的に、SMIによって禁じられませんが、それは使用されなかったシンボルを輸入するために貧しいスタイルであると考えられます、そして、標準化過程MIBモジュールSHOULD NOTはそうします。
4.5. MODULE-IDENTITY Invocation
4.5. モジュールアイデンティティ実施
RFC 2578 Section 3 requires that all SMIv2 MIB modules start with exactly one invocation of the MODULE-IDENTITY macro. This invocation MUST appear immediately after the IMPORTS statement.
RFC2578セクション3は、すべてのSMIv2 MIBモジュールがまさにMODULE-IDENTITYマクロの1つの実施から始まるのを必要とします。 この実施はIMPORTS声明直後現れなければなりません。
RFC 2578 Section 5 describes how the various clauses are used. The following additional guidelines apply to all MIB modules over which the IETF has change control:
RFC2578セクション5は様々な節がどう使用されているかを説明します。 以下の別途ガイドラインはIETFが変化コントロールを持っているすべてのMIBモジュールに適用されます:
- If the module was developed by an IETF working group, then the
ORGANIZATION clause MUST provide the full name of the working
group, and the CONTACT-INFO clause MUST include working group
mailing list information. The CONTACT-INFO clause SHOULD also
provide a pointer to the working group's web page.
- モジュールがIETFワーキンググループによって開発されたなら、ORGANIZATION節はワーキンググループのフルネームを提供しなければなりません、そして、CONTACT-INFO節はワーキンググループメーリングリスト情報を含まなければなりません。 また、CONTACT-INFO節SHOULDはワーキンググループのウェブページにポインタを提供します。
- A REVISION clause MUST be present for each revision of the MIB
module, and the UTC time of the most recent REVISION clause MUST
match that of the LAST-UPDATED clause. The DESCRIPTION clause
associated with each revision MUST state in which RFC that revision
appeared and SHOULD provide a list of all significant changes.
When a MIB module is revised, UTC times in all REVISION clauses
SHOULD be updated to use four-digit year notation.
- REVISION節はMIBモジュールの各改正のために存在していなければなりません、そして、最新のREVISION節のUTC時間はLAST-UPDATED節のものに合わなければなりません。 各改正に関連している記述節は、どのRFCで改正が現れて、SHOULDがすべての著しい変化のリストを提供すると述べなければならないか。 MIBモジュールがすべてのREVISION節SHOULDの改訂されたUTC回であるときにはアップデートして、4ケタの年の記法を使用してください。
Heard Best Current Practice [Page 12] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[12ページ]RFC4181ガイドライン
- The value assigned to the MODULE-IDENTITY descriptor MUST be unique
and (for IETF standards-track MIB modules) SHOULD reside under the
mgmt subtree [RFC2578]. Most often it will be an IANA-assigned
value directly under mib-2 [RFC2578], although for media-specific
MIB modules that extend the IF-MIB [RFC2863] it is customary to use
an IANA-assigned value under transmission [RFC2578]. In the past,
some IETF working groups have made their own assignments from
subtrees delegated to them by IANA, but that practice has proven
problematic and is NOT RECOMMENDED.
- MODULE-IDENTITY記述子に割り当てられた値はユニークであるに違いありません、そして、(IETF標準化過程MIBモジュールのための)SHOULDは管理下位木[RFC2578]の下で住んでいます。 たいていそれはmib-2[RFC2578]の直接下のIANA-割り当てられた値でしょう、広がるメディア特有のMIBモジュールのために-、MIB、[RFC2863] トランスミッション[RFC2578]でIANA-割り当てられた値を使用するのは通例です。 過去に、IETFワーキンググループがそれら自身の課題を下位木からした或るものがIANAでそれらに委任しましたが、その習慣は、問題が多いと判明して、NOT RECOMMENDEDです。
While a MIB module is under development, the RFC number in which it will eventually be published is usually unknown and must be filled in by the RFC Editor prior to publication. An appropriate form for the REVISION clause applying to a version under development would be something along the following lines:
MIBモジュールが開発中である間、それが結局発行されるRFC番号を通常、未知であり、RFC Editorは公表の前に記入しなければなりません。 開発中のバージョンに適用されるREVISION節のための適切なフォームは以下のやり方で何かでしょう:
REVISION "200212132358Z" -- December 13, 2002
DESCRIPTION "Initial version, published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
REVISION"200212132358Z"--「初期のバージョンであって、RFC yyyyとして発行された」2002年12月13日記述。 -- RFCエド、: yyyyを実際のRFC番号に取り替えてください、そして、この注意を取り除いてください。
Note that after RFC publication, a REVISION clause is present only for published versions of a MIB module and not for interim versions that existed only as Internet-Drafts. Thus, a draft version of a MIB module MUST contain just one new REVISION clause that covers all changes since the last published version (if any).
RFC公表の後にREVISION節がインターネット草稿だけとして存在した当座のバージョンのために存在しているのではなく、MIBモジュールの発行されたバージョンのためだけに存在していることに注意してください。 したがって、MIBモジュールの草案バージョンは最後に発行されたバージョン(もしあれば)以来のすべての変化に関するちょうど1つの新しいREVISION節を含まなければなりません。
When the initial version of a MIB module is under development, the value assigned to the MODULE-IDENTITY descriptor will be unknown if an IANA-assigned value is used, because the assignment is made just prior to publication as an RFC. The accepted form for the MODULE- IDENTITY statement in draft versions of such a module is something along the following lines:
MIBモジュールの初期のバージョンが開発中であるときに、IANA-割り当てられた値が使用されているなら、MODULE-IDENTITY記述子に割り当てられた値は未知になるでしょう、公表のすぐ前にRFCとして課題をするので。 そのようなモジュールの草案バージョンでのMODULE- IDENTITY声明のための受け入れられたフォームは以下のやり方で何かです:
<descriptor> MODULE-IDENTITY
<記述子>モジュールアイデンティティ
[ ... ]
[ ... ]
::= { <subtree> XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this note
::= <下位木>XXX--RFCエド、: XXXをIANA-規定番号に取り替えてください、そして、この注意を取り除いてください。
where <descriptor> is whatever descriptor has been selected for the module and <subtree> is the subtree under which the module is to be registered (e.g., mib-2 or transmission). Note that XXX must be temporarily replaced by a number in order for the module to compile.
<記述子>がどこのモジュールと<下位木>のために選択されたどういった記述子であるかは登録されているモジュールがことである下位木(例えば、mib-2かトランスミッション)です。 モジュールがコンパイルされるために一時XXXを数に取り替えなければならないことに注意してください。
Heard Best Current Practice [Page 13] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[13ページ]RFC4181ガイドライン
Note well: prior to official assignment by the IANA, a draft document MUST use a placeholder (such as "XXX" above) rather than an actual number. If trial implementations are desired during the development process, then an assignment under the 'experimental' subtree may be obtained from the IANA (cf. Section 4.3).
以下によく注意してください。 IANAによる公式の課題の前に、草稿ドキュメントは実数よりむしろプレースホルダ(上の"XXX"などの)を使用しなければなりません。 開発過程の間、トライアル実現を望んでいるなら、IANAから'実験的な'下位木の下における課題を得るかもしれません。(Cf。 セクション4.3).
4.6. Textual Conventions and Object Definitions
4.6. 原文のコンベンションとオブジェクト定義
4.6.1. Usage of Data Types
4.6.1. データ型の用法
4.6.1.1. INTEGER, Integer32, Gauge32, and Unsigned32
4.6.1.1. 整数、Integer32、Gauge32、およびUnsigned32
The 32-bit integer data types INTEGER, Integer32, Gauge32, and Unsigned32 are described in RFC 2578 Section 2 and further elaborated in RFC 2578 Sections 7.1.1, 7.1.7, and 7.1.11. The following guidelines apply when selecting one of these data types for an object definition or a textual convention:
32ビットの整数データ型のINTEGER、Integer32、Gauge32、およびUnsigned32はRFC2578セクション2で説明されて、RFC2578のセクション7.1.1、7.1.7、および7.1で、より遠くに.11に練られます。 オブジェクト定義か原文のコンベンションのためにこれらのデータ型の1つを選択するとき、以下のガイドラインは適用されます:
- For integer-valued enumerations:
- 整数で評価された列挙のために:
- INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST
NOT be used.
- INTEGERはREQUIREDです。 - Integer32、Unsigned32、およびGauge32を使用してはいけません。
Note that RFC 2578 recommends (but does not require) that integer- valued enumerations start at 1 and be numbered contiguously. This recommendation SHOULD be followed unless there is a valid reason to do otherwise, e.g., to match values of external data or to indicate special cases, and any such special-case usage SHOULD be clearly documented. For an example, see the InetAddressType TC [RFC4001].
しかし、そのRFC2578が推薦することに注意してください、(必要でない、)、整数の評価された列挙は、1時に始まって、近接して付番されます。 別の方法でする正当な理由がない場合この推薦SHOULDが続かれて、例えば外部のデータの値を合わせるか、または特別なケース、およびどんなそのような特別なケース用法SHOULDも示すために、明確に記録されてください。 例に関しては、InetAddressType TC[RFC4001]を見てください。
Although the SMI allows DEFVAL clauses for integer-valued enumerations to specify the default value either by label or by numeric value, the label form is preferred since all the examples in RFC 2578 are of that form and some tools do not accept the numeric form.
整数で評価された列挙がラベルか数値でデフォルト値を指定するように、SMIはDEFVALに節を許容しますが、RFC2578のすべての例がそのフォームのものであり、いくつかのツールが数値フォームを受け入れないで、ラベルフォームは好まれます。
- If the value range is between -2147483648..2147483647 (inclusive)
and negative values are possible, then:
- -2147483648の間には、値の範囲があるなら。2147483647 次に、(包括的)的、そして、否定的な値は可能です:
- Integer32 is RECOMMENDED;
- INTEGER is acceptable;
- Unsigned32 and Gauge32 MUST NOT be used.
- Integer32はRECOMMENDEDです。 - INTEGERは許容できます。 - Unsigned32とGauge32を使用してはいけません。
- If the value range is between 0..4294967295 (inclusive) and the
value of the information being modelled may increase above the
maximum value or decrease below the minimum value, then:
- 0の間には、値の範囲があるなら。4294967295(包括的な)とモデル化される情報の価値は、最大値より上で増加するか、または最小値より下で減少するかもしれません、そして:
Heard Best Current Practice [Page 14] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[14ページ]RFC4181ガイドライン
- Gauge32 is RECOMMENDED;
- Unsigned32 is acceptable;
- INTEGER and Integer32 MUST NOT be used if
values greater than 2147483647 are possible.
- Gauge32はRECOMMENDEDです。 - Unsigned32は許容できます。 - 値より多くの2147483647が可能であるなら、INTEGERとInteger32を使用してはいけません。
- If the value range is between 0..4294967295 (inclusive), and values
greater than 2147483647 are possible, and the value of the
information being modelled does not increase above the maximum
value nor decrease below the minimum value, then:
- 0の間には、値の範囲があるなら。モデル化されるのが最大値より上で増加して、最小値、その時の下で減少させない4294967295(包括的な)、2147483647が可能であるより大きい値、および情報の価値:
- Unsigned32 is RECOMMENDED;
- Gauge32 is acceptable;
- INTEGER and Integer32 MUST NOT be used.
- Unsigned32はRECOMMENDEDです。 - Gauge32は許容できます。 - INTEGERとInteger32を使用してはいけません。
- If the value range is between 0..2147483647 (inclusive), and the
value of the information being modelled does not increase above the
maximum value nor decrease below the minimum value, then:
- 0の間には、値の範囲があるなら。モデル化されるのが最大値より上で増加して、最小値、その時の下で減少させない2147483647(包括的な)、および情報の価値:
- Unsigned32 is RECOMMENDED;
- INTEGER, Integer32, and Gauge32 are acceptable.
- Unsigned32はRECOMMENDEDです。 - INTEGER、Integer32、およびGauge32は許容できます。
- For integer-valued objects that appear in an INDEX clause or for
integer-valued TCs that are to be used in an index column:
- INDEX節に現れる整数で評価された物かインデックスコラムで使用されることになっている整数で評価されたTCsのために:
- Unsigned32 with a range that excludes zero is RECOMMENDED for
most index objects. It is acceptable to include zero in the
range when it is semantically significant or when it is used as
the index value for a unique row with special properties. Such
usage SHOULD be clearly documented in the DESCRIPTION clause.
- ゼロを除く範囲があるUnsigned32はほとんどのインデックス物のためのRECOMMENDEDです。 それが意味的に重要であるか、またはそれが特別な性質に従ったユニークな列にインデックス値として使用されるとき、範囲にゼロを含んでいるのは許容できます。 記述節に記録されて、そのような用法SHOULDは明確にそうです。
- Integer32 or INTEGER with a non-negative range is acceptable.
Again, zero SHOULD be excluded from the range except when it is
semantically significant or when it is used as the index value
for a unique row with special properties, and in such cases the
usage SHOULD be clearly documented in the DESCRIPTION clause.
- 非否定的な範囲があるInteger32かINTEGERが許容できます。 もう一度、範囲から除かれて、それが意味的に重要であるか、またはそれが特別な性質に従ったユニークな列にインデックス値として使用される、およびそのような場合における用法がSHOULDであったなら明確に記録されたコネが記述節であったならSHOULDのゼロを合わせてください。
- Use of Gauge32 is acceptable for index objects that have gauge
semantics.
- ゲージ意味論を持っているインデックス物において、Gauge32の使用は許容できます。
The guidelines above combine both the usage rules for integer data types and the INDEX rules in RFC 2578 Section 7.7 up to and including bullet (1) plus the next-to-last paragraph on page 28.
上記のガイドラインはRFC2578セクション7.7の整数データ型とINDEX規則のために28ページで弾丸(1)と持続するためには次パラグラフを含めて両方の用法規則を結合します。
Sometimes it will be necessary for external variables to represent values of an index object -- e.g., ifIndex [RFC2863]. In such cases, authors of the module containing that object SHOULD consider defining TCs such as InterfaceIndex and/or InterfaceIndexOrZero [RFC2863].
時々、外部の変数がインデックス物の値を表すのが必要でしょう--例えば、ifIndex[RFC2863]。 そのような場合、その物のSHOULDを含むモジュールの作者は、InterfaceIndex、そして/または、InterfaceIndexOrZero[RFC2863]などのTCsを定義すると考えます。
Heard Best Current Practice [Page 15] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[15ページ]RFC4181ガイドライン
Note that INTEGER is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement, whereas Integer32, Gauge32, and Unsigned32 are defined by SNMPv2-SMI and MUST be imported from that module if used.
INTEGERが事前に定義されたASN.1タイプであり、モジュールのIMPORTS声明に存在しているはずがないことに注意してください、Integer32、Gauge32、およびUnsigned32をSNMPv2-SMIが定義して、使用するなら、そのモジュールから輸入しなければなりませんが。
4.6.1.2. Counter32 and Counter64
4.6.1.2. Counter32とCounter64
Counter32 and Counter64 have special semantics as described in RFC 2578 Sections 7.1.6 and 7.1.10, respectively. Object definitions MUST (and textual conventions SHOULD) respect these semantics. That means:
Counter32とCounter64には、特別な意味論がRFC2578のセクション7.1.6と7.1.10でそれぞれ説明されるようにあります。 オブジェクト定義はこれらの意味論を尊敬しなければなりません(そして、原文のコンベンションSHOULD)。 それは以下を意味します。
- It is OK to use Counter32/64 for counters that may/will be reset
when the management subsystem is re-initialized or when other
unusual/irregular events occur (e.g., counters maintained on a line
card may be reset when the line card is reset). However, if it is
possible for such other unusual/irregular events to occur, the
DESCRIPTION clause MUST state that this is so and MUST describe
those other unusual/irregular events in sufficient detail that it
is possible for a management application to determine whether a
reset has occurred since the last time the counter was polled. The
RECOMMENDED way to do this is to provide a discontinuity indicator
as described in RFC 2578 Sections 7.1.6 and 7.1.10. For an example
of such a discontinuity indicator, see the
ifCounterDiscontinuityTime object in the IF-MIB [RFC2863].
- そうするかもしれないカウンタへの管理サブシステムがそうであることのリセットが再初期化されていたなら/がそうするか、または他の珍しいか不規則な出来事が起こる(線カードがリセットされるとき、例えば線カードで維持されたカウンタはリセットされるかもしれません)Counter32/64を使用するのはOKです。 しかしながら、そのようなものに、起こる他の珍しいか不規則な出来事、記述節がこれがそうであると述べなければならなくて、管理アプリケーションが、最後の時間以来リセットが起こっているかどうか決定するのが、可能であるという十分な詳細にそれらの他の珍しいか不規則な出来事について説明しなければならないのが、可能であるなら、カウンタは投票されました。 これをするRECOMMENDED方法はRFC2578のセクション7.1.6と7.1.10で説明されるように不連続インディケータを提供することです。 そのような不連続インディケータの例に関して、中でifCounterDiscontinuityTime物を見てください、-、MIB、[RFC2863。]
- It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
that there is a requirement that on a discontinuity the counter
MUST reset to zero or to any other specific value.
- ゼロ、または、いかなる他の特定の値にもリセットされて、不連続では、カウンタがそうしなければならないという要件をあるCounter32/64の記述節に置くのはOKではありません。
- It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
that there is a requirement that it MUST reset at any specific
time/event (e.g., midnight).
- それがどんな特定の時間/出来事(例えば、真夜中)にもリセットしなければならない要件をあるCounter32/64の記述節に置くのはOKではありません。
- It is NOT OK for one manager to request the agent to reset the
value(s) of counter(s) to zero, and Counter32/64 is the wrong
syntax for "counters" that regularly reset themselves to zero. For
the latter, it is better to define or use textual conventions such
as those in RFC 3593 [RFC3593] or RFC 3705 [RFC3705].
- 1人のマネージャが、カウンタの値をゼロにリセットするようエージェントに要求するのが、OKでなく、Counter32/64は定期的にゼロに自分たちをリセットした「カウンタ」への間違った構文です。 後者には、RFC3593[RFC3593]かRFC3705[RFC3705]のそれらなどの原文のコンベンションを定義するか、または使用するのが、より良いです。
RFC 2578 Section 7.1.10 places a requirement on "standard" MIB modules that the Counter64 type may be used only if the information being modelled would wrap in less than one hour if the Counter32 type was used instead. Now that SNMPv3 is an Internet Standard and SNMPv1 is Historic (see http://www.rfc-editor.org/rfcxx00.html for status and [RFC3410] for rationale), there is no reason to continue enforcing this restriction. Henceforth "standard" MIB modules MAY use the Counter64 type when it makes sense to do so, and MUST use
Counter64がタイプする「標準」のMIBモジュールに関する要件がモデル化される情報がそうする場合にだけ使用されて、Counter32がタイプするなら1時間未満で包装が代わりに使用されたということであるかもしれないRFC2578セクション7.1.10の場所。 SNMPv3がインターネットStandardであり、SNMPv1がHistoric(状態と[RFC3410]に関して原理に関して http://www.rfc-editor.org/rfcxx00.html を見る)であるので、この制限を実施し続ける理由が全くありません。 Counter64がそうする意味になるとタイプして、使用しなければならない今後は「標準」のMIBモジュール5月の使用
Heard Best Current Practice [Page 16] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[16ページ]RFC4181ガイドライン
Counter64 if the information being modelled would wrap in less than one hour if the Counter32 type was used instead. Note also that there is no longer a requirement to define Counter32 counterparts for each Counter64 object, although one is still allowed to do so.
Counter32がタイプするならモデル化される情報が1時間未満後に包装されるなら、Counter64は代わりに使用されました。 また、それぞれのCounter64物のためにCounter32対応者を定義するという要件がもうないことに注意してください、1つはまだそうすることができますが。
There also exist closely-related textual conventions ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB [RFC2021] and HCNUM-TC [RFC2856], respectively.
また、RMON2-MIB[RFC2021]とHCNUM-TC[RFC2856]でそれぞれ定義された密接に関連の原文のコンベンションのZeroBasedCounter32とZeroBasedCounter64は存在しています。
The only difference between ZeroBasedCounter32/64 TCs and Counter32/64 is their starting value; at time=X, where X is their minimum-wrap-time after they were created, the behavior of ZeroBasedCounter32/64 becomes exactly the same as Counter32/64. Thus, the preceding paragraphs/rules apply not only to Counter32/64, but also to ZeroBasedCounter32/64 TCs.
ZeroBasedCounter32/64 TCsとCounter32/64の唯一の違いが彼らは値を開始することにさせます。 時間=Xでは、ZeroBasedCounter32/64の動きはまさにCounter32/64と同じになります。そこでは、それらが作成された後にXが彼らの最小の包装時間です。 したがって、先行のパラグラフ/規則はCounter32/64に適用するだけではなく、ZeroBasedCounter32/64 TCsにも適用されます。
4.6.1.3. CounterBasedGauge64
4.6.1.3. CounterBasedGauge64
SMIv2 unfortunately does not provide 64-bit integer base types. In order to make up for this omission, the CounterBasedGauge64 textual convention is defined in HCNUM-TC [RFC2856]. This TC uses Counter64 as a base type, but discards the special counter semantics, which is allowed under the generally accepted interpretation of RFC 2579 Section 3.3. It does inherit all the syntactic restrictions of that type, which means that it MUST NOT be subtyped and that objects defined with it MUST NOT appear in an INDEX clause, MUST NOT have a DEFVAL clause, and MUST have a MAX-ACCESS of read-only or accessible-for-notify.
残念ながら、SMIv2は64ビットの整数ベースタイプを提供しません。 この省略の埋め合わせをするために、CounterBasedGauge64の原文のコンベンションはHCNUM-TC[RFC2856]で定義されます。 このTCはベースタイプとしてCounter64を使用しますが、特別なカウンタ意味論を捨てます。(それは、RFC2579セクション3.3の一般に、受け入れられた解釈で許容されています)。 または、それがそれで定義された物がそれを副タイプしてはいけなくて、INDEX節に現れてはいけなくて、DEFVAL節を持ってはいけなくて、書き込み禁止のマックス-ACCESSを持たなければならないことを意味するそのタイプのすべての構文の制限を引き継ぐ、アクセスしやすい、通知
This TC SHOULD be used for object definitions that require a 64-bit unsigned data type with gauge semantics. If a 64-bit unsigned data type with different semantics is needed, then a different TC based on Counter64 MUST be used, since one TC cannot refine another (cf. RFC 2579 Section 3.5).
このTC SHOULD、ゲージ意味論がある64ビットの無記名のデータ型を必要とするオブジェクト定義には、使用されてください。 異なった意味論がある64ビットの無記名のデータ型が必要であるなら、Counter64に基づく異なったTCを使用しなければなりません、1TCが別のものを精製できないので(Cf。 RFC2579部3.5).
4.6.1.4. OCTET STRING
4.6.1.4. 八重奏ストリング
The OCTET STRING type is described in RFC 2578 Section 7.1.2. It represents arbitrary binary or textual data whose length is between 0 and 65535 octets inclusive. Objects and TCs whose SYNTAX is of this type SHOULD have a size constraint when the actual bounds are more restrictive than the SMI-imposed limits. This is particularly true for index objects. Note, however, that size constraints SHOULD NOT be imposed arbitrarily, as the SMI does not permit them to be changed afterward.
OCTET STRINGタイプはRFC2578セクション7.1.2で説明されます。 それは包括的に長さが0〜65535の八重奏である任意の2進の、または、原文のデータを表します。 実際の領域がSMIによって課された限界より制限しているとき、このタイプSHOULDにはSYNTAXがある物とTCsはサイズ規制を持っています。 インデックス物には、これは特に本当です。 しかしながら、サイズ規制SHOULD NOTが任意に課されることに注意してください、SMIが、それらがその後変えられるのを可能にしないとき。
Heard Best Current Practice [Page 17] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[17ページ]RFC4181ガイドライン
There exist a number of standard TCs that cater to some of the more common requirements for specialized OCTET STRING types. In particular, SNMPv2-TC [RFC2579] contains the DisplayString, PhysAddress, MacAddress, and DateAndTime TCs; the SNMP-FRAMEWORK-MIB [RFC3411] contains the SnmpAdminString TC; and the SYSAPPL-MIB [RFC2287] contains the Utf8String and LongUtf8String TCs. When a standard TC provides the desired semantics, it SHOULD be used in an object's SYNTAX clause instead of OCTET STRING or an equivalent locally-defined TC.
専門化しているOCTET STRINGタイプのための、より一般的な要件のいくつかに満たす多くの標準のTCsが存在しています。 特に、SNMPv2-TC[RFC2579]はDisplayString、PhysAddress、MacAddress、およびDateAndTime TCsを含んでいます。 SNMP-FRAMEWORK-MIB[RFC3411]はSnmpAdminString TCを含んでいます。 そして、SYSAPPL-MIB[RFC2287]はUtf8StringとLongUtf8String TCsを含んでいます。 規格であるときに、TCは必要な意味論を提供して、それはSHOULDです。OCTET STRINGか同等な局所的に定義されたTCの代わりに物のSYNTAX節で使用されてください。
Note that OCTET STRING is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
OCTET STRINGが事前に定義されたASN.1タイプであり、モジュールのIMPORTS声明に存在しているはずがないことに注意してください。
4.6.1.5. OBJECT IDENTIFIER
4.6.1.5. 物の識別子
The OBJECT IDENTIFIER type is described in RFC 2578 Section 7.1.3. Its instances represent administratively assigned names. Note that both the SMI and the SNMP protocol limit instances of this type to 128 sub-identifiers and require that each sub-identifier be within the range 0 to 4294967295 inclusive. Subtyping is not allowed.
OBJECT IDENTIFIERタイプはRFC2578セクション7.1.3で説明されます。 例は行政上割り当てられた名前を表します。 SMIとSNMPプロトコルの両方が、このタイプの例を128のサブ識別子に制限して、範囲の中にそれぞれのサブ識別子が0〜4294967295にあるのを必要とすることに注意してください。包括的。 Subtypingは許容されていません。
The purpose of OBJECT IDENTIFIER values is to provide authoritative identification either for some type of item or for a specific instance of some type of item. Among the items that can be identified in this way are definitions in MIB modules created via the MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT- CAPABILITIES constructs; and via instances of objects defined in MIB modules, protocols, languages, specifications, interface types, hardware, and software. For some of these uses other possibilities exist, e.g., OCTET STRING or enumerated INTEGER values. The OBJECT IDENTIFIER type SHOULD be used instead of the alternatives when the set of identification values needs to be independently extensible without the need for a registry to provide centralized coordination.
OBJECT IDENTIFIER値の目的はタイプの項目かタイプの項目の特定の例のための正式の識別を提供することです。 このように特定できる項目の中に、MODULE-IDENTITY、OBJECT-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、OBJECT-GROUP、NOTIFICATION-GROUP、MODULE-COMPLIANCE、およびエージェントCAPABILITIES構造物を通して作成されたMIBモジュールとの定義があります。 そして、MIBモジュールで定義された物の例で、プロトコル(言語、仕様)はタイプ、ハードウェア、およびソフトウェアを連結します。 例えば、OCTET STRINGか列挙されたINTEGERが、これらの用途のいくつかのために、他の可能性が存在するのを評価します。 OBJECT IDENTIFIERはSHOULDをタイプします。代替手段の代わりに、識別値のセットが、登録が集結されたコーディネートを提供する必要性なしで独自に広げることができる必要があるときには使用されてください。
There exist a number of standard TCs that cater to some of the more common requirements for specialized OBJECT IDENTIFIER types. In particular, SNMPv2-TC [RFC2579] contains the AutonomousType, VariablePointer, and RowPointer TCs. When a standard TC provides the desired semantics, it SHOULD be used in an object's SYNTAX clause instead of OBJECT IDENTIFIER or an equivalent locally-defined TC.
専門化しているOBJECT IDENTIFIERタイプのための、より一般的な要件のいくつかに満たす多くの標準のTCsが存在しています。 特に、SNMPv2-TC[RFC2579]はAutonomousType、VariablePointer、およびRowPointer TCsを含んでいます。 規格であるときに、TCは必要な意味論を提供して、それはSHOULDです。OBJECT IDENTIFIERか同等な局所的に定義されたTCの代わりに物のSYNTAX節で使用されてください。
Note that OBJECT IDENTIFIER is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
OBJECT IDENTIFIERが事前に定義されたASN.1タイプであり、モジュールのIMPORTS声明に存在しているはずがないことに注意してください。
Heard Best Current Practice [Page 18] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[18ページ]RFC4181ガイドライン
4.6.1.6. The BITS Construct
4.6.1.6. ビット構造物
The BITS construct is described in RFC 2578 Section 7.1.4. It represents an enumeration of named bits. The bit positions in a TC or object definition whose SYNTAX is of this type MUST start at 0 and SHOULD be contiguous.
BITS構造物はRFC2578セクション7.1.4で説明されます。 それは命名されたビットの列挙を表します。 TCのビット位置かこのタイプにはSYNTAXがあるオブジェクト定義が0とSHOULDで始まらなければなりません。隣接になってください。
Note that the BITS construct is defined by the macros that use it and therefore MUST NOT be present in a module's IMPORTS statement.
BITS構造物がそれを使用するマクロによって定義されて、したがって、モジュールのIMPORTS声明に存在しているはずがないことに注意してください。
4.6.1.7. IpAddress
4.6.1.7. IpAddress
The IpAddress type described in RFC 2578 Section 7.1.5 SHOULD NOT be used in new MIB modules. The InetAddress/InetAddressType textual conventions [RFC4001] SHOULD be used instead.
IpAddressタイプは中古のコネが新しいMIBモジュールであったならRFC2578でセクション7.1.5SHOULD NOTについて説明しました。 InetAddress/InetAddressType原文のコンベンション[RFC4001]SHOULD、代わりに使用されてください。
4.6.1.8. TimeTicks
4.6.1.8. TimeTicks
The TimeTicks type is described in RFC 2578 Section 7.1.8. It represents the time in hundredths of a second between two epochs, reduced modulo 2^32. It MUST NOT be subtyped, and the DESCRIPTION clause of any object or TC whose SYNTAX is of this type MUST identify the reference epochs.
TimeTicksタイプはRFC2578セクション7.1.8で説明されます。 それは2回の時代、減少している法2^32の間に1秒の100分の1で時間を表します。 それを副タイプしてはいけません、そして、このタイプにはSYNTAXがあるどんな物やTCの記述節も参照時代を特定しなければなりません。
The TimeTicks type SHOULD NOT be used directly in definitions of objects that are snapshots of sysUpTime [RFC3418]. The TimeStamp TC [RFC2579] already conveys the desired semantics and SHOULD be used instead.
TimeTicksはSHOULD NOTをタイプします。直接sysUpTime[RFC3418]のスナップである物の定義では、使用されてください。 TimeStamp TC[RFC2579]は既に必要な意味論とSHOULDを伝えます。代わりに使用されます。
4.6.1.9. TruthValue
4.6.1.9. TruthValue
The TruthValue TC is defined in SNMPv2-TC [RFC2579]. It is an enumerated INTEGER type that assumes the values true(1) and false(2).
TruthValue TCはSNMPv2-TC[RFC2579]で定義されます。 それは値が本当の(1)と誤った(2)であると仮定する列挙されたINTEGERタイプです。
This TC SHOULD be used in the SYNTAX clause of object definitions that require a Boolean type. MIB modules SHOULD NOT use enumerated INTEGER types or define TCs that duplicate its semantics.
このTC SHOULD、ブールタイプを必要とするオブジェクト定義のSYNTAX節で使用されてください。 MIBモジュールSHOULD NOT使用は、INTEGERタイプを数え上げるか、または意味論をコピーするTCsを定義します。
4.6.1.10. Other Data Types
4.6.1.10. 他のデータ型
There exist a number of standard TCs that cater to some of the more common requirements for specialized data types. Some have been mentioned above, and Appendix B contains a partial list that includes those plus some others that are a bit more specialized. An on-line version of that list, which is updated as new TCs are developed, can be found at http://www.ops.ietf.org/mib-common-tcs.html.
専門化しているデータ型のための、より一般的な要件のいくつかに満たす多くの標準のTCsが存在しています。 或るものは上に言及されました、そして、Appendix Bはもう少し専門にされるそれらと何人かの他のものを含んでいる部分的なリストを含んでいます。 http://www.ops.ietf.org/mib-common-tcs.html でそのリストのオンラインバージョンを見つけることができます。(新しいTCsが開発されているとき、リストはアップデートされます)。
Heard Best Current Practice [Page 19] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[19ページ]RFC4181ガイドライン
Whenever a standard TC already conveys the desired semantics, it SHOULD be used in an object definition instead of the corresponding base type or a locally-defined TC. This is especially true of the TCs defined in SNMPv2-TC [RFC2579] and SNMP-FRAMEWORK-MIB [RFC3411] because they are Internet Standards, and so modules that refer to them will not suffer delay in advancement on the standards track on account of such references.
標準のTCが既に必要な意味論を伝えて、それがSHOULDであるときはいつも、対応するベースタイプか局所的に定義されたTCの代わりにオブジェクト定義に使用されてください。 彼らがインターネットStandardsであるのでこれがSNMPv2-TC[RFC2579]とSNMP-FRAMEWORK-MIB[RFC3411]で定義されたTCsに関して特に本当であるので、それらについて言及するモジュールがそのような参照のために標準化過程の上に前進の遅れを受けないでしょう。
MIB module authors need to be aware that enumerated INTEGER or BITS TCs may in some cases be extended with additional enumerated values or additional bit positions. When an imported TC that may be extended in this way is used to define an object that may be written or that serves as an index in a read-create table, then the set of values or bit positions that needs to be supported SHOULD be specified either in the object's DESCRIPTION clause or in an OBJECT clause in the MIB module's compliance statement(s). This may be done by explicitly listing the required values or bit positions, or it may be done by stating that an implementation may support a subset of values or bit positions of its choosing.
いくつかの場合、MIBモジュール作者が、それがINTEGERを数え上げたのを意識している必要があるか、またはBITS TCsは追加列挙された値か追加ビット位置で広げられるかもしれません。 このように広げられるかもしれない輸入されたTCが書かれているかもしれないか、または中のaがテーブルの上に置くのに読書して作成するインデックスとして機能する物を定義するのに使用されるとき、そして、支持されたSHOULDである必要性が物の記述節かMIBモジュールの承諾声明のOBJECT節で指定されるという値かビット位置のセットです。 明らかに必要な値かビット位置を記載することによって、これをするかもしれませんか、または実現が選ぶ値かビット位置の部分集合をサポートするかもしれないと述べることによって、それをするかもしれません。
4.6.2. DESCRIPTION and REFERENCE Clauses
4.6.2. 記述と参照節
It is hard to overemphasize the importance of an accurate and unambiguous DESCRIPTION clause for all objects and TCs. The DESCRIPTION clause contains the instructions that implementors will use to implement an object, and if they are inadequate or ambiguous, then implementation quality will suffer. Probably the single most important job of a MIB reviewer is to ensure that DESCRIPTION clauses are sufficiently clear and unambiguous to allow interoperable implementations to be created.
すべての物とTCsのための正確で明白な記述節の重要性を偏重しにくいです。 記述節は作成者が物を実行するのに使用する指示を含んでいて、彼らが不十分であるか、またはあいまいであるなら、実現品質に苦しむでしょう。 たぶんMIB評論家の最も重要な仕事は記述節が確実に共同利用できる実現が作成されるのを許容するために十分明確で明白になるようにすることです。
A very common problem is to see an object definition for, say, 'stdMIBPoofpoofCounter' with a DESCRIPTION clause that just says "Number of poofpoofs" with no indication what a 'poofpoof' is. In such cases, it is strongly RECOMMENDED that there either be at least a minimal explanation or else a REFERENCE clause to point to the definition of a 'poofpoof'.
非常に一般的な問題はたとえば、指示なしで「poofpoofsの数」をただ言う記述節がある'stdMIBPoofpoofCounter'に関してオブジェクト定義を見ることです。'poofpoof'が何であるかということです。 そのような場合、それが強くそうである、RECOMMENDED、'poofpoof'の定義に指す少なくとも最小量の説明かREFERENCE節があります。
For read-write objects (other than columns in read-create tables that have well-defined persistence properties), it is RECOMMENDED that the DESCRIPTION clause specify what happens to the value after an agent reboot. Among the possibilities are that the value remains unchanged, that it reverts to a well-defined default value, or that the result is implementation-dependent.
読書して書いている物(コラムを除いて、明確な固執の特性を持っているテーブルを中に読書して作成する)に関しては、記述節が、値がエージェントリブートの後にどうなるかを指定するのは、RECOMMENDEDです。 可能性の中に、それはいます。値は変わりがなくて、明確なデフォルト値、またはそれに結果を振り向けるのは、実現依存しています。
Heard Best Current Practice [Page 20] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[20ページ]RFC4181ガイドライン
4.6.3. DISPLAY-HINT Clause
4.6.3. 表示ヒント節
The DISPLAY-HINT clause is used in a TC to provide a nonbinding hint to a management application as to how the value of an instance of an object defined with the syntax in the TC might be displayed. Its presence is optional.
DISPLAY-ヒント節は、どう構文がTCにある状態で定義された物の例の値を表示するかもしれないかに関して拘束力がないヒントを管理アプリケーションに提供するのにTCで使用されます。 存在は任意です。
Although management applications typically default to decimal format
("d") for integer TCs that are not enumerations and to a hexadecimal
format ("1x:" or "1x " or "1x_") for octet string TCs when the
DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not
actually specify any defaults. MIB authors should be aware that a
clear hint is provided to applications only when the DISPLAY-HINT
clause is present.
管理アプリケーションが列挙でない整数TCsのための10進形式(「d」)と、そして、16進形式を通常デフォルトとする、(「1x: 」 "1x"か「1x_」) DISPLAY-ヒント節が欠けているときの八重奏ストリングTCsによって、SMIv2が実際に少しのデフォルトも指定しないのが有名であるべきです。 MIB作者はDISPLAY-ヒント節が存在しているときだけ、はっきりしたヒントがアプリケーションに提供されるのを意識しているべきです。
4.6.4. Conceptual Table Definitions
4.6.4. 概念的なテーブル定義
RFC 2578 Sections 7.1.12 and 7.1.12.1 specify the rules for defining conceptual tables, and RFC 2578 Sections 7.7, 7.8, and 7.8.1 specify conceptual table indexing rules. The following guidelines apply to such definitions:
.1が概念的なテーブル、およびRFC2578セクション7.7、7.8、および7.8.1を定義しながら規則を指定するRFC2578のセクション7.1.12と7.1.12は概念的なテーブル指標付与規則を指定します。 以下のガイドラインはそのような定義に適用されます:
- For conceptual rows:
- 概念的な列に:
- If the row is an extension of a row in some other table, then an
AUGMENTS clause MUST be used if the relationship is one-to-one,
and an INDEX clause MUST be used if the relationship is sparse.
In the latter case, the INDEX clause SHOULD be identical to that
of the original table.
- 列がある他のテーブルでの列の拡大であるなら、関係が1〜1であるならAUGMENTS節を使用しなければなりません、そして、関係がまばらであるなら、INDEX節を使用しなければなりません。 後者のケース、INDEX節SHOULD、原表のものと同じにしてください。
- If the row is an element of an expansion table -- that is, if
multiple row instances correspond to a single row instance in
some other table -- then an INDEX clause MUST be used, and the
first-mentioned elements SHOULD be the indices of that other
table, listed in the same order.
- すなわち、複数の列の例がある他のテーブルの一つの列例に対応しているなら列が拡大テーブルの要素であるならINDEX節を使用しなければならなくて、最初に言及された要素SHOULDはその他のテーブルのインデックスリストであり、同次で記載しました。
- If objects external to the row are present in the INDEX clause,
then the conceptual row's DESCRIPTION clause MUST specify how
those objects are used in identifying instances of its columnar
objects, and in particular MUST specify for which values of those
index objects the conceptual row may exist.
- 列への外部の物がINDEX節に存在しているなら、概念的な列の記述節は、それらの物が円柱状の物の例を特定する際にどう使用されるかを指定しなければならなくて、概念的な列がそれらのインデックス物のどの値のために存在するかもしれないかを特に指定しなければなりません。
- Use of the IMPLIED keyword is NOT RECOMMENDED for any index
object that may appear in the INDEX clause of an expansion table.
Since this keyword may be associated only with the last object in
an INDEX clause, it cannot be associated with the same index
object in a primary table and an expansion table. This will
cause the sort order to be different in the primary table and any
- IMPLIEDキーワードの使用は拡大テーブルのINDEX節に現れるどんなインデックス物のためのNOT RECOMMENDEDです。 このキーワードがINDEX節における最後の物だけに関連しているかもしれないので、第一のテーブルと拡大テーブルで同じインデックス物にそれを関連づけることができません。 これは第一のテーブルといずれでも異なるソート順序を引き起こすでしょう。
Heard Best Current Practice [Page 21] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[21ページ]RFC4181ガイドライン
expansion tables. As a consequence, an implementation will be
unable to reuse indexing code from the primary table in expansion
tables, and data structures meant to be extended might actually
have to be replicated. Designers who are tempted to use IMPLIED
should consider that the resulting sort order rarely meets user
expectations, particularly for strings that include both
uppercase and lowercase letters, and it does not take the user
language or locale into account.
拡大テーブル。 結果として、実現は拡大テーブルの第一のテーブルからインデックスコードを再利用できないでしょう、そして、広げられたことになっていたデータ構造が実際に模写されなければならないかもしれません。 IMPLIEDを使用するように誘惑されるデザイナーは、結果として起こるソート順序がめったに特に大文字しているものと同様に小文字の手紙を含んでいるストリングへのユーザ期待に合わないと考えるべきです、そして、それはユーザ言語か現場を考慮に入れません。
- If dynamic row creation and/or deletion by management applications
is supported, then:
- ダイナミックであるなら、創造をこいでください、そして、次に、管理アプリケーションによる削除は支持されます:
- There SHOULD be one columnar object with a SYNTAX value of
RowStatus [RFC2579] and a MAX-ACCESS value of read-create. This
object is called the status column for the conceptual row. All
other columnar objects MUST have a MAX-ACCESS value of read-
create, read-only, accessible-for-notify, or not-accessible; a
MAX-ACCESS value of read-write is not allowed.
- そこ、SHOULD、RowStatus[RFC2579]のSYNTAX値とマックス-ACCESS値がある1個の円柱状の物になってください、読書して作成します。 この物は概念的な列のための状態コラムと呼ばれます。 他のすべての円柱状の物には読書の値が作成するマックス-ACCESS、書き込み禁止がなければならない、アクセスしやすい、通知、アクセスしやすくはありません。 読書して書くことのマックス-ACCESS値は許容されていません。
- There either MUST be one columnar object with a SYNTAX value of
StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
else the row object (table entry) DESCRIPTION clause MUST specify
what happens to dynamically-created rows after an agent restart.
- StorageType[RFC2579]のSYNTAX値とマックス-ACCESS値がある1個の円柱状の物があるに違いない、読書する作成、または、列の物(テーブル項目)の記述節は、ダイナミックに作成された列がエージェント再開の後にどうなるかを指定しなければなりません。
- If the agent itself may also create and/or delete rows, then the
conditions under which this can occur MUST be clearly documented
in the row object DESCRIPTION clause.
- また、エージェント自身が列を作成する、そして/または、削除するかもしれないなら、列の物の記述節に明確に、これが起こることができる状態を記録しなければなりません。
- For conceptual rows that include a status column:
- 状態コラムを含んでいる概念的な列に:
- The DESCRIPTION clause of the status column MUST specify which
columnar objects (if any) have to be set to valid values before
the row can be activated. If any objects in cascading tables
have to be populated with related data before the row can be
activated, then this MUST also be specified.
- 状態コラムの記述節は、列が活性化できる前にどの円柱状の物(もしあれば)が有効値に設定されなければならないかを指定しなければなりません。 また、列が活性化できる前に何か滝のテーブルの物が関連するデータで居住されなければならないなら、これを指定しなければなりません。
- The DESCRIPTION clause of the status column MUST specify whether
or not it is possible to modify other columns in the same
conceptual row when the status value is active(1). Note that in
many cases it will be possible to modify some writable columns
when the row is active but not others. In such cases, the
DESCRIPTION clause for each writable column SHOULD state whether
or not that column can be modified when the row is active, and
the DESCRIPTION clause for the status column SHOULD state that
modifiability of other columns when the status value is active(1)
is specified in the DESCRIPTION clauses for those columns (rather
than listing the modifiable columns individually).
- 状態値がアクティブな(1)であるときに、状態コラムの記述節は、同じ概念的な列で他のコラムを変更するのが可能であるかどうか指定しなければなりません。 列がアクティブであるときには多くの場合、いくつかの書き込み可能なコラムを変更するのが可能であることに注意してくださいが、他のものは注意しません。 状態値がアクティブな(1)であるときに、そのような場合、列がアクティブであるときに、そのコラムを変更できるか否かに関係なく、SHOULDが述べるそれぞれの書き込み可能なコラムのための記述節、および状態コラムSHOULD状態のための記述節では、他のコラムのその修正可能性はそれらのコラム(個別に修正できるコラムをリストアップするよりむしろ)のための記述節で指定されます。
Heard Best Current Practice [Page 22] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[22ページ]RFC4181ガイドライン
- For conceptual rows that include a StorageType column:
- StorageTypeコラムを含んでいる概念的な列に:
- The DESCRIPTION clause of the StorageType column MUST specify
which read-write or read-create columnar objects in permanent(4)
rows an agent must, at a minimum, allow to be writable.
- StorageTypeコラムの記述節は、エージェントが書き込み可能であることを最小限で許さなければならない永久的な(4)列でどれが円柱状の物を読書して書くか、または読書して作成するかを指定しなければなりません。
Note that RFC 2578 Section 7.8 requires that the lifetime of an instance of a conceptual row that AUGMENTS a base row must be the same as the corresponding instance of the base row. It follows that there is no need for a RowStatus or StorageType column in an augmenting row if one is already present in the base row.
RFC2578セクション7.8が概念的な列の例のベース列がそうしなければならないAUGMENTSがベース列の対応する例と同じであることの生涯それを必要とすることに注意してください。 RowStatusの必要は全くないということになるか、または増大列のStorageTypeコラムが1であるならベース列に既に存在しています。
Complete requirements for the RowStatus and StorageType TCs can be found in RFC 2579, in the DESCRIPTION clauses for those TCs.
RFC2579でRowStatusとStorageType TCsのための完全な要件を見つけることができます、それらのTCsのための記述節で。
4.6.5. OID Values Assigned to Objects
4.6.5. 物に割り当てられたOID値
RFC 2578 Section 7.10 specifies the rules for assigning OBJECT IDENTIFIER (OID) values to OBJECT-TYPE definitions. In particular:
RFC2578セクション7.10はOBJECT IDENTIFIER(OID)に値を割り当てるための規則をOBJECT-TYPE定義に指定します。 特に:
- A conceptual table MUST have exactly one subordinate object, which
is a conceptual row. The OID assigned to the conceptual row MUST
be derived by appending a sub-identifier of "1" to the OID assigned
to the conceptual table.
- 概念的なテーブルにはちょうど1個の下位オブジェクトがなければなりません。(それは、概念的な列です)。 「概念的なテーブルに割り当てられたOIDへの1インチ」に関するサブ識別子を追加することによって、概念的な列に割り当てられたOIDを引き出さなければなりません。
- A conceptual row has as many subordinate objects as there are
columns in the row; there MUST be at least one. The OID assigned
to each columnar object MUST be derived by appending a non-zero
sub-identifier, unique within the row, to the OID assigned to the
conceptual row.
- 概念的な列には、コラムが列にあるのと同じくらい多くの下位オブジェクトがあります。 少なくとも1つがあるに違いありません。 非ゼロサブ識別子を追加することによって、それぞれの円柱状の物に割り当てられたOIDを引き出さなければなりません、列の中でユニークです、概念的な列に割り当てられたOIDに。
- A columnar or scalar object MUST NOT have any subordinate objects.
- 円柱状の、または、スカラの物には、少しの下位オブジェクトもあってはいけません。
- The last sub-identifier of an OID assigned to any object (be it
table, row, column, or scalar) MUST NOT be equal to zero. Note
that sub-identifiers of intermediate nodes MAY be equal to zero.
- どんな物(テーブル、列、コラム、またはスカラであることにかかわらず)にも割り当てられたOIDの最後のサブ識別子は、ゼロに合わせるために等しいはずがありません。 中間的ノードのサブ識別子がゼロに合わせるために等しいかもしれないことに注意してください。
- The OID assigned to an object definition MUST NOT also be assigned
to another definition that results in OID registration. RFC 2578
Section 3.6 lists the constructs that create OID registrations.
- また、OID登録をもたらす別の定義にオブジェクト定義に割り当てられたOIDを割り当ててはいけません。 RFC2578セクション3.6はOID登録証明書を作成する構造物を記載します。
Although it is not specifically required by the SMI, it is customary (and strongly RECOMMENDED) that object definitions not be registered beneath group definitions, compliance statements, capabilities statements, or notification definitions. It is also customary (and strongly RECOMMENDED) that group definitions, compliance statements,
SMIは明確に必要ではありませんが、それが通例である、(強さ、RECOMMENDED) オブジェクト定義はグループ定義、承諾声明、能力声明、または通知定義の下に登録されません。 また、それも通例である、(強く、RECOMMENDED) それは定義、承諾声明を分類します。
Heard Best Current Practice [Page 23] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[23ページ]RFC4181ガイドライン
capabilities statements, and notification definitions not be registered beneath object definitions. See Appendix D for a RECOMMENDED OID assignment scheme.
能力声明、および通知定義、オブジェクト定義の下に登録されないでください。 RECOMMENDED OID課題計画に関してAppendix Dを見てください。
4.6.6. OID Length Limitations and Table Indexing
4.6.6. OID長さの制限とテーブルインデックス
As specified in RFC 2578 Section 3.5, all OIDs are limited to 128 sub-identifiers. While this is not likely to cause problems with administrative assignments, it does place some limitations on table indexing. That is true because the length limitation also applies to OIDs for object instances, and these consist of the concatenation of the "base" OID assigned in the object definition plus the index components. When a table has multiple indices of types such as OCTET STRING or OBJECT IDENTIFIER that resolve to multiple sub-identifiers, then the 128-sub-identifier limit can be quickly reached.
RFC2578セクション3.5で指定されるように、すべてのOIDsが128のサブ識別子に制限されます。 これが管理課題で問題を起こしていそうにない間、それはテーブルインデックスにいくつかの制限を置きます。 また、長さの制限がオブジェクトインスタンスのためにOIDsに申し込まれるので、それは本当です、そして、これらはオブジェクト定義とインデックスコンポーネントで割り当てられた「ベース」OIDの連結から成ります。 テーブルが複数で決議するOCTET STRINGかOBJECT IDENTIFIERなどのタイプの複数のインデックスリストをサブ識別子であるのに持っていると、128サブ識別子限界にすぐに達することができます。
Despite its inconvenience, the 128-sub-identifier limit is not something that can be ignored. In addition to being imposed by the SMI, it is also imposed by the SNMP (see the last paragraph in Section 4.1 of RFC 3416 [RFC3416]). It follows that any table with enough indexing components to violate this limit cannot be read or written using the SNMP and so is unusable. Hence table design MUST take the 128-sub-identifier limit into account. It is RECOMMENDED that all MIB documents make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation.
不便にもかかわらず、128サブ識別子限界は無視できる何かではありません。 また、SMIによって課されることに加えて、それはSNMPによって課されます(RFC3416[RFC3416]のセクション4.1における最後のパラグラフを見てください)。 SNMPを使用することでこの限界に違反できるくらいのインデックスコンポーネントがあるどんなテーブルも読むことができないか、書くことができないのに続くので、それは、使用不可能です。 したがって、テーブルデザインは128サブ識別子限界を考慮に入れなければなりません。 すべてのMIBドキュメントで管理ソフトウェアが観測しなければならないインデックスコンポーネントの長さにおけるどんな制限も明白になるのは、RECOMMENDEDです。 インデックスコンポーネントにSIZE規制を含んでいるか、または概念的な行記述節か周囲のドキュメンテーションで適切な規制を指定することによって、これをするかもしれません。
4.7. Notification Definitions
4.7. 通知定義
RFC 2578 Section 8 specifies the rules for notification definitions. In particular:
RFC2578セクション8は通知定義のための規則を指定します。 特に:
- Inaccessible objects MUST NOT appear in the OBJECTS clause.
- アクセスできないオブジェクトはOBJECTS節に現れてはいけません。
- For each object type mentioned in the OBJECTS clause, the
DESCRIPTION clause MUST specify which object instance is to be
present in the transmitted notification and MUST specify the
information/meaning conveyed.
- OBJECTS節で言及された各オブジェクト・タイプとして、記述節は、どのオブジェクトインスタンスが伝えられた通知に存在しているかことであるかと指定しなければならなくて、伝えられた情報/意味を指定しなければなりません。
- The OBJECT IDENTIFIER (OID) value assigned to each notification
type MUST have a next-to-last sub-identifier of zero, so that it is
possible to convert an SMIv2 notification definition into an SMIv1
trap definition and back again without information loss (see
[RFC3584] Section 2.1.2) and possible for a multilingual proxy
chain to translate an SNMPv2 trap into an SNMPv1 trap and back
again without information loss (see [RFC3584] Section 3). In
- それぞれの通知タイプに割り当てられたOBJECT IDENTIFIER(OID)値はゼロに関する持続する次サブ識別子を持たなければなりません、多言語プロキシチェーンがSNMPv2罠をSNMPv1罠に翻訳して、情報の損失なしで戻すのが情報の損失([RFC3584]セクション2.1.2を見る)なしでSMIv2通知定義をSMIv1罠定義に行き帰り変換するのにおいて可能であって、可能である([RFC3584]セクション3を見る)ように。 コネ
Heard Best Current Practice [Page 24] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[24ページ]RFC4181ガイドライン
addition, the OID assigned to a notification definition MUST NOT
also be assigned to another definition that results in OID
registration. RFC 2578 Section 3.6 lists the constructs that
create OID registrations.
追加、また、OID登録をもたらす別の定義に通知定義に割り当てられたOIDを割り当ててはいけません。 RFC2578セクション3.6はOID登録証明書を作成する構造物を記載します。
Although it is not specifically required by the SMI, it is customary (and strongly RECOMMENDED) that notification definitions not be registered beneath group definitions, compliance statements, capabilities statements, or object definitions (this last is especially unwise, as it may result in an object instance and a notification definition sharing the same OID). It is also customary (and strongly RECOMMENDED) that the OIDs assigned to notification types be leaf OIDs (i.e., that there be no OID registrations subordinate to a notification definition). See Appendix D for a RECOMMENDED OID assignment scheme.
RECOMMENDED) その通知定義は強く、グループ定義、承諾声明、能力声明の下に登録もされませんし、反対もしません。そして、SMIは明確に必要ではありませんが、それが通例である、(定義(これは最後に特に賢明ではありません、同じOIDを共有しながらオブジェクトインスタンスと通知定義をもたらしているかもしれない間)。 また、それも通例である、(強さ、RECOMMENDED)、通知タイプに割り当てられたOIDsが葉のOIDsである、(すなわち、それ、どんなOID登録証明書も通知定義を従属しないというそこでは、ことになってください、) RECOMMENDED OID課題体系に関してAppendix Dを見てください。
In many cases, notifications will be triggered by external events, and sometimes it will be possible for those external events to occur at a sufficiently rapid rate that sending a notification for each occurrence would overwhelm the network. In such cases, a mechanism MUST be provided for limiting the rate at which the notification can be generated. A common technique is to require that the notification generator use throttling -- that is, to require that it generate no more than one notification for each event source in any given time interval of duration T. The throttling period T MAY be configurable, in which case it is specified in a MIB object, or it MAY be fixed, in which case it is specified in the notification definition. Examples of the fixed time interval technique can be found in the SNMP- REPEATER-MIB [RFC2108] and in the ENTITY-MIB [RFC4133].
多くの場合、通知は外部のイベントによって引き起こされるでしょう、そして、それらの外部のイベントが十分急速な速度で起こるのにおいて時々、各発生のために通知書を送るのがネットワークを圧倒するのは、可能でしょう。 そのような場合、通知を生成することができるレートを制限して、メカニズムに備えなければなりません。 一般的なテクニックは通知ジェネレータが阻止を使用するのが必要であることです--すなわち、持続時間T.のどんな与えられた時間間隔の各イベントソースあたり1つ未満の通知にも阻止を生成するのが必要であるように、期間Tが構成可能であるかもしれない、それは修理されるかもしれなくて、その場合、その場合、それがMIBオブジェクトで指定されるか、またはそれは通知定義で指定されます。 SNMP- REPEATER-MIB[RFC2108]とENTITY-MIB[RFC4133]で一定時間間隔のテクニックに関する例を見つけることができます。
4.8. Compliance Statements
4.8. 承諾声明
RFC 2580 Sections 3, 4, and 5 specify the rules for conformance groups and compliance statements. In particular:
RFC2580セクション3、4、および5は順応グループと承諾声明に規則を指定します。 特に:
- Every object with a MAX-ACCESS value other than "not-accessible"
MUST be contained in at least one object group.
- 少なくとも1つのオブジェクトグループに「アクセスしやすくないこと」を除いたマックス-ACCESS値があるあらゆるオブジェクトを含まなければなりません。
- Every notification MUST be contained in at least one notification
group.
- 少なくとも1つの通知グループにあらゆる通知を含まなければなりません。
- There MUST be at least one compliance statement defined for each
"standard" MIB module. It may reside either within that MIB module
or within a companion MIB module.
- それぞれの「標準」のMIBモジュールのために定義された少なくとも1つの承諾声明があるに違いありません。 それはそのMIBモジュール以内か仲間MIBモジュールの中に住むかもしれません。
In writing compliance statements, there are several points that are easily overlooked:
承諾声明を書くには、容易に見落とされる数個の意味があります:
Heard Best Current Practice [Page 25] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[25ページ]RFC4181ガイドライン
- An object group or notification group that is not mentioned either
in the MANDATORY-GROUPS clause or in any GROUP clause of a MODULE-
COMPLIANCE statement is unconditionally optional with respect to
that compliance statement. An alternate way to indicate that an
object group or notification group is optional is to mention it in
a GROUP clause whose DESCRIPTION clause states that the group is
optional. The latter method is RECOMMENDED (for optional groups
that are relevant to the compliance statement) in order to make it
clear that the optional status is intended rather than being the
result of an act of omission.
- MANDATORY-GROUPS節かMODULE- COMPLIANCE声明のどんなGROUP節でも参照されないオブジェクトグループか通知グループがその承諾声明に関して無条件に任意です。 オブジェクトグループか通知グループが任意であることを示す代替の方法は記述節がグループが任意であると述べるGROUP節でそれについて言及することです。 後者のメソッドは、むしろ省略の行為の結果であるより任意の状態が意図すると断言するRECOMMENDED(承諾声明に関連している任意のグループのための)です。
- If there are any objects with a MAX-ACCESS value of read-write or
read-create for which there is no OBJECT clause that specifies a
MIN-ACCESS of read-only, then implementations must support write
access to those objects in order to be compliant with that MODULE-
COMPLIANCE statement. This fact sometimes catches MIB module
authors by surprise. When confronted with such cases, reviewers
SHOULD verify that this is indeed what the authors intended, since
it often is not.
- 何かマックス-ACCESSがあるオブジェクトがあれば、書き込み禁止のMIN-ACCESSを読書して書くのを評価するか、またはどれが指定するOBJECT節が全くないように、読書して作成してくださいか、と当時の実装必須サポートはそのMODULE- COMPLIANCE声明で言いなりになるためにそれらのオブジェクトへのアクセスを書きます。 この事実は時々驚きでMIBモジュール作者を捕らえます。 そのような場合に立ち向かわれていると、評論家SHOULDは、本当に、これが作者が意図したものであることを確かめます、それがしばしばそうであるというわけではないので。
- On the other side of the coin, MIB module authors need to be aware
that while a read-only compliance statement is sufficient to
support interoperable monitoring applications, it is not sufficient
to support interoperable configuration applications. A technique
commonly used in MIB modules that are intended to support both
monitoring and configuration is to provide both a read-only
compliance statement and a full compliance statement. A good
example is provided by the DIFFSERV-MIB [RFC3289]. Authors SHOULD
consider using this technique when it is applicable.
- その一方で、MIBモジュール作者は、書き込み禁止承諾声明が共同利用できる監視用途をサポートするために十分ですが、共同利用できる構成アプリケーションをサポートするのが十分でないことを意識している必要があります。 モニターと構成の両方をサポートすることを意図するMIBモジュールで一般的に使用されるテクニックは書き込み禁止承諾声明と完全な承諾声明の両方を提供することです。 好例はDIFFSERV-MIB[RFC3289]によって提供されます。 SHOULDがそれが適切であるときに、このテクニックを使用することで考える作者。
Sometimes MIB module authors will want to specify that a compliant implementation needs to support only a subset of the values allowed by an object's SYNTAX clause. For accessible objects, this may be done either by specifying the required values in an object's DESCRIPTION clause or by providing an OBJECT clause with a refined SYNTAX in a compliance statement. The latter method is RECOMMENDED for most cases, and is REQUIRED if there are multiple compliance statements with different value subsets required. The DIFFSERV-MIB [RFC3289] illustrates this point. The diffServMIBFullCompliance statement contains the following OBJECT clause. (See Section 4.8.1, "Note Regarding These Examples and RFC 2578".)
時々、MIBモジュール作者は、対応する実装が、オブジェクトのSYNTAX節によって許容された値の部分集合だけをサポートする必要であると指定したくなるでしょう。 アクセスしやすいオブジェクトに関しては、オブジェクトの記述節で必要な値を指定するか、または承諾声明で洗練されたSYNTAXをOBJECT節に提供することによって、これをするかもしれません。 後者のメソッドは、ほとんどのケースのためのRECOMMENDEDであり、複数の承諾声明があれば、異価部分集合が必要であることのREQUIREDです。 DIFFSERV-MIB[RFC3289]はこのポイントを例証します。 diffServMIBFullCompliance声明は以下のOBJECT節を含んでいます。 (セクション4.8.1、「これらの例とRFC2578に関する注」を見てください。)
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
OBJECT diffServDataPathStatus SYNTAX RowStatusのアクティブな(1)WRITE-SYNTAX RowStatus、createAndGo(4)、(6)を破壊してください、記述、「createAndWaitとnotInServiceのサポートは必要ではありません」。
Heard Best Current Practice [Page 26] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[26ページ]RFC4181ガイドライン
whereas the diffServMIBReadOnlyCompliance statement contains this:
diffServMIBReadOnlyCompliance声明はこれを含んでいますが:
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only status that
needs to be supported."
OBJECT diffServDataPathStatus SYNTAX RowStatusのアクティブな(1)、MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要ではありません、そして、アクティブであるのが、サポートされる必要がある唯一の状態である、」
One cannot do this for inaccessible index objects because they cannot be present in object groups and cannot be mentioned in OBJECT clauses. There are situations, however, in which one might wish to indicate that an implementation is required to support only a subset of the possible values of some index in a read-create table. In such cases, the requirements MUST be specified either in the index object's DESCRIPTION clause (RECOMMENDED if there is only one value subset) or in the DESCRIPTION clause of a MODULE-COMPLIANCE statement (REQUIRED if the value subset is unique to the compliance statement).
それらについてオブジェクトグループで存在しているはずがなくて、OBJECT節で言及できないので、1つはアクセスできないインデックスオブジェクトのためにこれができません。 しかしながら、中のaがテーブルの上に置くのに読書して作成する何らかのインデックスの可能な値の部分集合だけをサポートするために、実装が必要であることを示すというどの1つの力の願望に状況があるか。 そのような場合、インデックスオブジェクトの記述節(そこである場合にだけ、RECOMMENDEDは1つの値の部分集合である)かMODULE-COMPLIANCE声明の記述節で要件を指定しなければなりません(REQUIREDは値の部分集合であるなら承諾声明にユニークです)。
In many cases, a MIB module is always implemented in conjunction with one or more other MIB modules. That fact is REQUIRED to be noted in the surrounding documentation (see Section 3.2 above), and it SHOULD also be noted in the relevant compliance statements. In cases where a particular compliance statement in (say) MIB module A requires the complete implementation of some other MIB module B, then the RECOMMENDED approach is to include a statement to that effect in the DESCRIPTION clause of the compliance statement(s) in MIB module A. It is also possible, however, that MIB module A might have requirements that are different from those that are expressed by any compliance statement of module B -- for example, module A might not require any of the unconditionally mandatory object groups from module B but might require mandatory implementation of an object group from module B that is only conditionally mandatory with respect to the compliance statement(s) in module B. In such cases, the RECOMMENDED approach is for the compliance statement(s) in module A to formally specify requirements with respect to module B via appropriate MODULE, MANDATORY-GROUPS, GROUP, and OBJECT clauses. An example is provided by the compliance statements in the DIFFSERV-MIB [RFC3289], which list the ifCounterDiscontinuityGroup from IF-MIB [RFC2863] as a mandatory group. That group is not sufficient to satisfy any IF-MIB compliance statement, and it is conditionally mandatory in the IF-MIB's current compliance statement ifCompliance3.
多くの場合、MIBモジュールはいつも他の1つ以上のMIBモジュールに関連して実装されます。 その事実は周囲のドキュメンテーションに述べられるべきREQUIRED(上でセクション3.2を見る)であり、それはSHOULDです。また、関連承諾声明では、述べられます。 しかしながら、次に、RECOMMENDEDアプローチが(言います)MIBモジュールAによる特定の承諾声明がある他のMIBモジュールBの完全な実装を必要として、その趣旨で承諾声明の記述節にMIBモジュールA.で声明を含むことである場合では、また、ItもMIBモジュールAにはモジュールBのどんな承諾声明によっても言い表されるものと異なった要件があるかもしれないのが可能です; 例えば、モジュールAは、モジュールBからの無条件に義務的なオブジェクトグループのいずれも必要としませんが、承諾声明に関してモジュールB.で条件付きにだけ義務的なモジュールBからのオブジェクトグループの義務的な実装を必要とするかもしれません。モジュールBに関して正式に要件を指定するモジュールAによる承諾声明のためにそのような場合、RECOMMENDEDアプローチであるInがMODULE、MANDATORY-GROUPS、GROUP、およびOBJECT節を当てます。 ifCounterDiscontinuityGroupを記載するDIFFSERV-MIB[RFC3289]での承諾声明を例に提供する、-、MIB、義務的なグループとしての[RFC2863。] そのグループが満足することができないくらいいくらか、-、MIB、承諾声明、それが中で条件付きに義務的である、-、MIBのもの、現在の承諾声明ifCompliance3。
4.8.1. Note Regarding These Examples and RFC 2578
4.8.1. これらの例を見なして、RFC2578に注意してください。
There has been some dispute as to whether syntax refinements that restrict enumerations (RFC 2578 Section 9) are permitted with TCs, as shown in the examples above, or are allowed only with the base types
列挙(RFC2578セクション9)を制限する構文気品がTCsと共に上記の例に示されるように受入れられるか、または単にベースタイプで許容されているかに関して何らかの論争がありました。
Heard Best Current Practice [Page 27] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[27ページ]RFC4181ガイドライン
INTEGER and BITS, as suggested by a strict reading of RFC 2578. The rough consensus of the editors of the SMIv2 documents and the current pool of MIB reviewers is that they should be allowed with TCs. MIB module authors should be aware that some MIB compilers follow the strict reading of RFC 2578 and require that the TC be replaced by its base type (INTEGER or BITS) when enumerations are refined. That usage is legal, and it can be found in some older MIB modules such as the IF-MIB [RFC2863].
そして、INTEGER、RFC2578の厳しい読みで示されるようなBITS。 SMIv2ドキュメントのエディタとMIB評論家の現在のプールの荒いコンセンサスは彼らがTCsと共に許容されるべきであるということです。 MIBモジュール作者は、いくつかのMIBコンパイラがRFC2578の厳しい示度に続くのを意識していて、列挙が洗練されているとき、TCがベースタイプ(INTEGERかBITS)に取り替えられるのを必要とするべきです。 その用法が法的であり、それがいくつかの、より古いMIBモジュールでそのようなものを設立することであるかもしれない、-、MIB、[RFC2863。]
4.9. Revisions to MIB Modules
4.9. MIBモジュールへの改正
RFC 2578 Section 10 specifies general rules that apply any time a MIB module is revised. Specifically:
RFC2578セクション10はMIBモジュールが改訂されている何時でも適用される総則を指定します。 明確に:
- The MODULE-IDENTITY invocation MUST be updated to include
information about the revision. In particular, the LAST-UPDATED
clause value MUST be set to the revision time, a REVISION clause
with the same UTC time and an associated DESCRIPTION clause
describing the changes MUST be added, and any obsolete information
in the existing DESCRIPTION, ORGANIZATION, and CONTACT-INFO clauses
MUST be replaced with up-to-date information. See Section 4.5
above for additional requirements that apply to MIB modules that
are under IETF change control.
- 改正の情報を含むようにMODULE-IDENTITY実施をアップデートしなければなりません。 特に、LAST-UPDATED節価値を改正時間に設定しなければなりません、そして、同UTC時間と関連記述節が変化について説明しているREVISION節を追加しなければなりません、そして、既存の記述、ORGANIZATION、およびCONTACT-INFO節のどんな時代遅れの情報も最新情報に取り替えなければなりません。 IETFの下にあるMIBモジュールに適用される追加要件における、上のセクション4.5がコントロールを変えるのを見てください。
- On the other hand, the module name MUST NOT be changed (except to
correct typographical errors), existing definitions (even obsolete
ones) MUST NOT be removed from the MIB module, and descriptors and
OBJECT IDENTIFIER values associated with existing definitions MUST
NOT be changed or re-assigned.
- 他方では、モジュール名を変えてはいけなくて(誤字を修正する以外に)、MIBモジュールから既存の定義(時代遅れのものさえ)を取り除いてはいけなくて、既存の定義に関連している記述子とOBJECT IDENTIFIER値を変えてはいけませんし、また再選任してはいけません。
It is important to note that the purpose in forbidding certain kinds of changes is to ensure that a revised MIB module is compatible with fielded implementations based on previous versions of the module. There are two distinct aspects of this backward-compatibility requirement. One is "over the wire" compatibility of agent and manager implementations that are based on different revisions of the MIB module. The other is "compilation" compatibility with MIB modules that import definitions from the revised MIB module. The rules forbidding changing or re-assigning OBJECT IDENTIFIER values are necessary to ensure "over the wire" compatibility; the rules against changing module names or descriptors or removing obsolete definitions are necessary to ensure compilation compatibility.
変化のある種類が確実にすることになっていると禁じることにおける改訂されたMIBモジュールは互換性がある目的がモジュールの旧バージョンに基づく実装をさばいたことに注意するのが重要です。 この後方の互換性要件の2つの異なった局面があります。 1つはMIBモジュールの異なった改正に基づいているエージェントとマネージャ実装の「ワイヤ」互換性です。 もう片方が改訂されたMIBモジュールから定義を意味するMIBモジュールとの「編集」の互換性です。 OBJECT IDENTIFIER値を変えるか、または再選任するのを禁じる規則が、「ワイヤ」で互換性を確実にするのに必要です。 モジュール名か記述子を変えるか、または時代遅れの定義を取り除くことに対する規則が、編集の互換性を確実にするのに必要です。
RFC 2578 Section 10.2 specifies rules that apply to revisions of object definitions. The following guidelines correct some errors in these rules and provide some clarifications:
RFC2578セクション10.2はオブジェクト定義の改正に適用される規則を指定します。 以下のガイドラインは、これらの規則でいくつかの誤りを修正して、いくつかの明確化を提供します:
Heard Best Current Practice [Page 28] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[28ページ]RFC4181ガイドライン
- Bullet (1) allows the labels of named numbers and named bits in
SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
This can break compilation compatibility, since those labels may be
used by DEFVAL clauses in modules that import the definitions of
the affected objects. Therefore, labels of named numbers and named
bits MUST NOT be changed when revising IETF MIB modules (except to
correct typographical errors), and they SHOULD NOT be changed when
revising enterprise MIB modules.
- 弾丸(1)で、タイプの列挙されたINTEGERかBITSのSYNTAX節の命名された数と命名されたビットのラベルは変化します。 これは編集の互換性を壊すことができます、それらのラベルが影響を受けるオブジェクトの定義を意味するモジュールによるDEFVAL節によって使用されるかもしれないので。 したがって、IETF MIBモジュール(誤字を修正するのを除いた)を改訂して、それらであるときに名前付の数と名前付のビットのラベルを変えてはいけない、SHOULD NOT、企業MIBモジュールを改訂するときには、変えてください。
- Although not specifically permitted in bullets (1) through (8), it
is generally considered acceptable to add range constraints to the
SYNTAX clause of an integer-valued object, provided that the
constraints simply make explicit some value restrictions that were
implicit in the definition of the object. The most common example
is an auxiliary object with a SYNTAX of INTEGER or Integer32 with
no range constraint. Since an auxiliary object is not permitted to
assume negative values, adding the range constraint (0..2147483647)
cannot possibly result in any "over the wire" change, nor will it
cause any compilation compatibility problems with a correctly
written MIB module. Such a change SHOULD be treated by a reviewer
as an editorial change, not as a semantic change. Similarly,
removal of a range or size constraint from an object definition
when that range or size constraint is enforced by the underlying
data type SHOULD be treated by a reviewer as an editorial change.
- (8)を通して弾丸(1)で明確に受入れられませんが、一般に、それは整数で評価されたオブジェクトのSYNTAX節に範囲規制を追加するのにおいて許容できると考えられます、いくつかのオブジェクトの定義で暗黙である値の制限が規制で単に明白になれば。 最も一般的な例は範囲規制のないINTEGERかInteger32のSYNTAXがある補助のオブジェクトです。 補助のオブジェクトが負の数を仮定することが許可されていないので、範囲規制(0 .2147483647)が「ワイヤ」でいずれももたらすことができないと言い足して、変化してください、そして、それは正しく書かれたMIBモジュールの少しの編集互換性の問題も引き起こさないでしょう。 そのようなaはSHOULDを変えます。意味変化として扱われるのではなく、社説変化として評論家によって扱われてください。 その範囲かサイズ規制であるときに、同様に、オブジェクト定義からの範囲かサイズ規制の取り外しは基本的なデータ型SHOULDによって励行されます。社説変化として評論家によって扱われてください。
RFC 2578 Section 10.3 specifies rules that apply to revisions of notification definitions. No clarifications or corrections are required.
RFC2578セクション10.3は通知定義の改正に適用される規則を指定します。 どんな明確化も修正も必要ではありません。
RFC 2579 Section 5 specifies rules that apply to revisions of textual convention definitions. The following guideline corrects an error in these rules:
RFC2579セクション5は原文のコンベンション定義の改正に適用される規則を指定します。 以下のガイドラインはこれらの規則で誤りを改めます:
- Bullet (1) allows the labels of named numbers and named bits in
SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
This can break compilation compatibility, since those labels may be
used by DEFVAL clauses in modules that import the definitions of
the affected TCs. Therefore, labels of named numbers and named
bits MUST NOT be changed when revising IETF MIB modules (except to
correct typographical errors), and they SHOULD NOT be changed when
revising enterprise MIB modules.
- 弾丸(1)で、タイプの列挙されたINTEGERかBITSのSYNTAX節の命名された数と命名されたビットのラベルは変化します。 これは編集の互換性を壊すことができます、それらのラベルが影響を受けるTCsの定義を意味するモジュールによるDEFVAL節によって使用されるかもしれないので。 したがって、IETF MIBモジュール(誤字を修正するのを除いた)を改訂して、それらであるときに名前付の数と名前付のビットのラベルを変えてはいけない、SHOULD NOT、企業MIBモジュールを改訂するときには、変えてください。
RFC 2580 Section 7.1 specifies rules that apply to revisions of conformance groups. Two point are worth reiterating:
RFC2580セクション7.1は順応グループの改正に適用される規則を指定します。 2ポイントは繰り返す価値があります:
Heard Best Current Practice [Page 29] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[29ページ]RFC4181ガイドライン
- Objects and notifications MUST NOT be added to or removed from an
existing object group or notification group. Doing so could cause
a compilation failure or (worse) a silent change in the meaning of
a compliance statement or capabilities statement that refers to
that group.
- オブジェクトと通知は、グループを、加えられてはいけませんし、また既存のオブジェクトグループか通知から移してはいけません。 そうするのはそのグループを参照する承諾声明か能力声明の意味における編集失敗か(より悪い)静かな変化を引き起こす場合がありました。
- The status of a conformance group is independent of the status of
its members. Thus, a current group MAY refer to deprecated objects
or notifications. This may be desirable in certain cases, e.g., a
set of widely-deployed objects or notifications may be deprecated
when they are replaced by a more up-to-date set of definitions, but
the conformance groups that contain them may remain current in
order to encourage continued implementation of the deprecated
objects and notifications.
- 順応グループの状態はメンバーの状態から独立しています。 したがって、現在のグループは推奨しないオブジェクトか通知を示すかもしれません。 ある場合には、これが望ましいかもしれない、それらをより最新の定義に取り替えるとき、例えば、1セットの広く配布しているオブジェクトか通知が推奨しないかもしれませんが、それらを含む順応グループは、推奨しないオブジェクトと通知の継続的な実装を奨励するために現在のままで残るかもしれません。
RFC 2580 Section 7.2 specifies rules that apply to revisions of compliance statements. The following guidelines correct an omission from these rules and emphasize one important point:
RFC2580セクション7.2は承諾声明の改正に適用される規則を指定します。 以下のガイドラインは、これらの規則から省略を修正して、重要な1ポイントを強調します:
- RFC 2580 should (but does not) recommend that an OBJECT clause
specifying support for the original set of values be added to a
compliance statement when an enumerated INTEGER object or a BITS
object referenced by the compliance statement has enumerations or
named bits added, assuming that no such clause is already present
and that the effective MIN-ACCESS value is read-write or read-
create. This is necessary in order to avoid a silent change to the
meaning of the compliance statement. MIB module authors and
reviewers SHOULD watch for this to ensure that such OBJECT clauses
are added when needed. Note that this may not always be possible
to do, since affected compliance statements may reside in modules
other than the one that contains the revised definition(s).
- RFC2580は推薦するべきです。(but does not)は、元の値のサポートを指定するOBJECT節がいつ列挙されたINTEGERオブジェクトか承諾声明によって参照をつけられるBITSオブジェクトで列挙か名前付のビットを加えるか、そして、どんなそのような節も既に存在していなくて、有効なMIN-ACCESS値が読書して書くことであると仮定するか、読書が作成する承諾声明に追加されることを勧めます。 これが、承諾声明の意味への静かな変化を避けるのに必要です。 MIBモジュール作者と評論家SHOULDは、必要であるとそのようなOBJECT節が加えられるのを保証するためにこれを待ち兼ねます。 これがするのにおいていつも可能であるかもしれないというわけではないことに注意してください、影響を受ける承諾声明が改訂された定義を含むもの以外のモジュールであるかもしれないので。
- The status of a compliance statement is independent of the status
of its members. Thus, a current compliance statement MAY refer to
deprecated object groups or notification groups. This may be
desirable in certain cases, e.g., a set of widely-deployed object
or notification groups may be deprecated when they are replaced by
a more up-to-date set of definitions, but compliance statements
that refer to them may remain current in order to encourage
continued implementation of the deprecated groups.
- 承諾声明の状態はメンバーの状態から独立しています。 したがって、現在の承諾声明は推奨しないオブジェクトグループか通知グループを参照するかもしれません。 ある場合には、これが望ましいかもしれない、それらをより最新の定義に取り替えるとき、例えば、1セットの広く配布しているオブジェクトか通知グループが推奨しないかもしれませんが、それらについて言及する承諾声明は、推奨しないグループの継続的な実装を奨励するために現在のままで残るかもしれません。
RFC 2580 Section 7.3 specifies rules that apply to revisions of capabilities statements. The following guideline corrects an omission from these rules:
RFC2580セクション7.3は能力声明の改正に適用される規則を指定します。 以下のガイドラインはこれらの規則から省略を修正します:
- RFC 2580 should (but does not) recommend that VARIATION clauses
specifying support for the original set of values be added to a
capabilities statement when enumerated INTEGER objects or BITS
- RFC2580、(but does not)は、元の値のサポートを指定するVARIATION節が列挙されるとINTEGERが反対するという能力声明かBITSに追加されることを勧めるはずです。
Heard Best Current Practice [Page 30] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[30ページ]RFC4181ガイドライン
objects referenced by the capabilities statement have enumerations
added, assuming that no such clauses are already present. This is
necessary in order to avoid a silent change to the meaning of the
capabilities statement.
能力声明によって参照をつけられるオブジェクトで、そのようなどんな節も既に存在していないと仮定して、列挙を加えます。 これが、能力声明の意味への静かな変化を避けるのに必要です。
In certain exceptional situations, the cost of strictly following the SMIv2 rules governing MIB module revisions may exceed the benefit. In such cases, the rules can be waived, but when that is done both the change and the justification for it MUST be thoroughly documented. One example is provided by Section 3.1.5 of RFC 2863, which documents the semantic change that was made to ifIndex in the transition from MIB-II [RFC1213] to the IF-MIB [RFC2863] and provides a detailed justification for that change. Another example is provided by the REVISION clause of the SONET-MIB [RFC2558] that documents raising the MAX-ACCESS of several objects to read-write while adding MIN-ACCESS of read-only for compatibility with the previous version [RFC1595].
ある例外的な状況で、厳密にMIBモジュール改正を治めるSMIv2規則に従う費用は利益を超えるかもしれません。 そのような場合、規則を放棄できますが、それが完了していると、変化とそれのための正当化の両方を徹底的に記録しなければなりません。 そして、変遷でMIB-II[RFC1213]からifIndexにされた意味変化を記録する.5セクション3.1RFC2863をある例に提供する、-、MIB、[RFC2863]、その変化のための詳細な正当化を提供します。 それが記録するSonet-MIB[RFC2558]のREVISION節は、旧バージョン[RFC1595]との互換性のために書き込み禁止の加えている間に読書して書く数個のオブジェクトのマックス-ACCESS MIN-ACCESSを上げながら、別の例を提供します。
Authors and reviewers may find it helpful to use tools that can list the differences between two revisions of a MIB module. Please see http://www.ops.ietf.org/mib-review-tools.html for more information.
作者と評論家は、MIBモジュールの2つの改正の違いを記載できるツールを使用するのに役立っているのがわかるかもしれません。 詳しい情報に関して http://www.ops.ietf.org/mib-review-tools.html を見てください。
5. Acknowledgments
5. 承認
Most of the material on usage of data types was based on input provided by Bert Wijnen with assistance from Keith McCloghrie, David T. Perkins, and Juergen Schoenwaelder. Much of the other material on SMIv2 usage was taken from an unpublished guide for MIB authors and reviewers by Juergen Schoenwaelder. Some of the recommendations in these guidelines are based on material drawn from the on-line SMIv2 errata list at http://www.ibr.cs.tu-bs.de/ietf/smi-errata/. Thanks to Frank Strauss and Juergen Schoenwaelder for maintaining that list and to the contributors who supplied the material for that list. Finally, thanks are due to the following individuals whose comments on earlier versions of this memo contained many valuable suggestions for additions, clarifications, and corrections: Andy Bierman, Bob Braden, Michelle Cotton, David Harrington, Harrie Hazewinkel, Dinakaran Joseph, Michael Kirkham, Keith McCloghrie, David T. Perkins, Randy Presuhn, Dan Romascanu, Juergen Schoenwaelder, Frank Strauss, Dave Thaler, and Bert Wijnen.
データ型の用法の材料の大部分はキースMcCloghrie、デヴィッド・T.パーキンス、およびユルゲンSchoenwaelderから援助されてバートWijnenによって提供された入力に基づきました。 SMIv2用法のもう片方の材料の多くがユルゲンSchoenwaelderによって未発表のガイドからMIB作者と評論家に抜粋されました。 これらのガイドラインにおける推薦のいくつかが http://www.ibr.cs.tu-bs.de/ietf/smi-errata/ でオンラインSMIv2誤字リストから得られた材料に基づいています。おかげに、そのリストを維持して、貢献者への材料をそれに供給したフランク・ストラウスとユルゲンSchoenwaelderが記載します。 最終的に、感謝はこのメモの以前のバージョンのコメントが追加、明確化、および修正のための多くの貴重な提案を含んだ以下の個人のためです: アンディBierman、ボブ・ブレーデン、ミシェルCotton、デヴィッド・ハリントン、Harrie Hazewinkel、Dinakaranジョゼフ、マイケル・カーカム、キースMcCloghrie、デヴィッド・T.パーキンス、ランディPresuhn、ダンRomascanu、ユルゲンSchoenwaelder、フランク・ストラウス、デーヴThaler、およびバートWijnen。
Heard Best Current Practice [Page 31] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[31ページ]RFC4181ガイドライン
6. Security Considerations
6. セキュリティ問題
Implementation and deployment of a MIB module in a system may result in security risks that would not otherwise exist. It is important for authors and reviewers of documents that define MIB modules to ensure that those documents fully comply with the guidelines in http://www.ops.ietf.org/mib-security.html so that all such risks are adequately disclosed.
システムにおける、MIBモジュールの実装と展開はそうでなければ存在しないセキュリティリスクをもたらすかもしれません。 ドキュメントの作者と評論家にとって、MIBモジュールを定義して、それらのドキュメントが http://www.ops.ietf.org/mib-security.html のガイドラインに完全に従うのを保証してください。そうすれば、そのようなすべての危険が適切に明らかにされるのは、重要です。
7. IANA Considerations
7. IANA問題
This document affects the IANA to the extent that it describes what is required to be present in the IANA Considerations section of a MIB document, but it does not require that the IANA update any existing registry or create any new registry.
このドキュメントは何が存在しているのに必要であるかをMIBドキュメントのIANA Considerations部で説明するという範囲にIANAに影響しますが、それは、IANAがどんな既存の登録もアップデートするか、またはどんな新しい登録も作成するのを必要としません。
Heard Best Current Practice [Page 32] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[32ページ]RFC4181ガイドライン
Appendix A: MIB Review Checklist
付録A: MIBレビューチェックリスト
The purpose of a MIB review is to review the MIB module both for technical correctness and for adherence to IETF documentation requirements. The following checklist may be helpful when reviewing a draft document:
MIBレビューの目的は技術的な正当性と固守のためのMIBモジュールをIETFドキュメンテーション要件に見直すことです。 草稿ドキュメントを再検討するとき、以下のチェックリストは有用であるかもしれません:
1.) I-D Boilerplate -- verify that the draft contains the required Internet-Draft boilerplate (see http://www.ietf.org/ietf/1id- guidelines.txt), including the appropriate statement to permit publication as an RFC, and that I-D boilerplate does not contain references or section numbers.
1.) I-D Boilerplate--草稿がRFCとして公表を可能にするために適切な声明を含む必要なインターネット草稿の決まり文句( http://www.ietf.org/ietf/1id- guidelines.txtを見る)を含んでいて、そのI-Dの決まり文句が参照かセクション番号を含まないことを確かめてください。
2.) Abstract -- verify that the abstract does not contain references, that it does not have a section number, and that its content follows the guidelines in http://www.ietf.org/ietf/1id-guidelines.txt.
2.) 要約--要約が参照を含んでいなくて、それにはセクション番号がなくて、内容が http://www.ietf.org/ietf/1id-guidelines.txt のガイドラインに従うことを確かめてください。
3.) MIB Boilerplate -- verify that the draft contains the latest approved SNMP Network Management Framework boilerplate from the OPS area web site (http://www.ops.ietf.org/mib-boilerplate.html).
3.) MIB Boilerplate--草稿がOPS領域ウェブサイト( http://www.ops.ietf.org/mib-boilerplate.html )からの最新の承認されたSNMP Network Management Frameworkの決まり文句を含むことを確かめてください。
4.) Security Considerations Section -- verify that the draft uses the latest approved template from the OPS area web site (http://www.ops.ietf.org/mib-security.html) and that the guidelines therein have been followed.
4.) セキュリティConsiderationsセクション--草稿がOPS領域ウェブサイト( http://www.ops.ietf.org/mib-security.html )から最新の承認されたテンプレートを使用して、そこにガイドラインに従ってあることを確かめてください。
5.) IANA Considerations Section -- this section must always be present. If the draft requires no action from the IANA, ensure that this is explicitly noted. If the draft requires OID values to be assigned, ensure that the IANA Considerations section contains the information specified in Section 3.5 of these guidelines. If the draft contains the initial version of an IANA-maintained module, verify that the MODULE-IDENTITY invocation contains maintenance instructions that comply with the requirements in RFC 2434. In the latter case, the IANA Considerations section that will appear in the RFC MUST contain a pointer to the actual IANA-maintained module.
5.) IANA Considerationsセクション--このセクションはいつも存在していなければなりません。 草稿がIANAから動作を全く必要としないなら、これが明らかに注意されるのを確実にしてください。 草稿が、OID値が割り当てられるのを必要とするなら、IANA Considerations部がこれらのガイドラインのセクション3.5で指定された情報を含むのを確実にしてください。 草稿がIANAによって維持されたモジュールの初期のバージョンを含むなら、MODULE-IDENTITY実施がRFC2434で要件に従う保守指示を含むことを確かめてください。 後者の場合では、RFC MUSTに現れるIANA Considerations部は実際のIANAによって維持されたモジュールに指針を含みます。
6.) References -- verify that the references are properly divided between normative and informative references, that RFC 2119 is included as a normative reference if the terminology defined therein is used in the document, that all references required by the boilerplate are present, that all MIB modules containing imported items are cited as normative references, and that all citations point to the most current RFCs unless there is a valid reason to do otherwise (for example, it is OK to include an informative reference to a previous version of a specification to help explain a feature included for backward compatibility).
6.) 参照; 参照が規範的で有益な参照の間で適切に分割されて、そこに定義された用語がドキュメントで使用されるならRFC2119が引用規格として含まれていて、決まり文句によって必要とされたすべての参照が存在していることを確かめてください; 引用規格は輸入品目を含むすべてのMIBモジュールに挙げられます、そして、別の方法でする正当な理由がない場合(例えば、特徴が後方のために互換性を含んでいたと説明するのを助けるために仕様の旧バージョンの有益な指示するものを含んでいるのはOKです)、すべての引用が最も現在のRFCsを示します。
Heard Best Current Practice [Page 33] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[33ページ]RFC4181ガイドライン
7.) Copyright Notices -- verify that the draft contains an abbreviated copyright notice in the DESCRIPTION clause of each MODULE-IDENTITY invocation and that it contains the full copyright notice and disclaimer specified in Sections 5.4 and 5.5 of RFC 3978 at the end of the document. Make sure that the correct year is used in all copyright dates.
7.) Copyright Notices--草稿がそれぞれのMODULE-IDENTITY実施の記述節の簡略化された版権情報を含んでいて、ドキュメントの端でRFC3978のセクション5.4と5.5で指定された完全な版権情報と注意書きを含むことを確かめてください。 正しい年がすべての著作権登録年紀で費やされるのを確実にしてください。
8.) IPR Notice -- if the draft does not contains a verbatim copy of the IPR notice specified in Section 5 of RFC 3979, recommend that the IPR notice be included.
8.) IPR Notice--草稿が、RFC3979のセクション5で指定されたIPR通知の逐語的なコピーを含んでいて、IPR通知が含まれることを勧めないなら。
9.) Other Issues -- check for any issues mentioned in http://www.ietf.org/ID-Checklist.html that are not covered elsewhere.
9.) 他のIssues--ほかの場所にカバーされていない http://www.ietf.org/ID-Checklist.html で参照されたあらゆる問題がないかどうかチェックしてください。
10.) Technical Content -- review the actual technical content for compliance with the guidelines in this document. The use of a MIB compiler is recommended when checking for syntax errors; see http://www.ops.ietf.org/mib-review-tools.html for more information. Checking for correct syntax, however, is only part of the job. It is just as important to actually read the MIB document from the point of view of a potential implementor. It is particularly important to check that DESCRIPTION clauses are sufficiently clear and unambiguous to allow interoperable implementations to be created.
10.) 技術的なContent--本書ではガイドラインへの承諾のための実際の技術的な内容を再検討してください。 構文エラーがないかどうかチェックするとき、MIBコンパイラの使用はお勧めです。 詳しい情報に関して http://www.ops.ietf.org/mib-review-tools.html を見てください。 しかしながら、正しい構文がないかどうか唯一のチェックするのは、仕事の一部です。 実際に潜在的作成者の観点からMIBドキュメントを読むのはちょうど同じくらい重要です。 記述節が共同利用できる実装が作成されるのを許容するために十分明確であって、明白であることをチェックするのは特に重要です。
Appendix B: Commonly Used Textual Conventions
付録B: 一般的に使用された原文のコンベンション
The following TCs are defined in SNMPv2-TC [RFC2579]:
以下のTCsはSNMPv2-TC[RFC2579]で定義されます:
DisplayString OCTET STRING (SIZE (0..255)) PhysAddress OCTET STRING MacAddress OCTET STRING (SIZE (6)) TruthValue enumerated INTEGER TestAndIncr INTEGER (0..2147483647) AutonomousType OBJECT IDENTIFIER VariablePointer OBJECT IDENTIFIER RowPointer OBJECT IDENTIFIER RowStatus enumerated INTEGER TimeStamp TimeTicks TimeInterval INTEGER (0..2147483647) DateAndTime OCTET STRING (SIZE (8 | 11)) StorageType enumerated INTEGER TDomain OBJECT IDENTIFIER TAddress OCTET STRING (SIZE (1..255))
DisplayString OCTET STRING(SIZE(0 .255))PhysAddress OCTET STRING MacAddress OCTET STRING、(SIZE(6))TruthValue列挙されたINTEGER TestAndIncr INTEGER(0 .2147483647)AutonomousType OBJECT IDENTIFIER VariablePointer OBJECT IDENTIFIER RowPointer OBJECT IDENTIFIER RowStatus列挙されたINTEGER TimeStamp TimeTicks TimeInterval INTEGER(0 .2147483647)DateAndTime OCTET STRING(SIZE(8|11))StorageTypeはINTEGER TDomain OBJECT IDENTIFIER TAddress OCTET STRINGを数え上げました。(サイズ(1 .255))
Note 1. InstancePointer is obsolete and MUST NOT be used.
1に注意してください。 InstancePointerは時代遅れであり、使用されてはいけません。
Note 2. DisplayString does not support internationalized text. It
MUST NOT be used for objects that are required to hold
2に注意してください。 DisplayStringは国際化しているテキストをサポートしません。 成立しなければならないオブジェクトにそれを使用してはいけません。
Heard Best Current Practice [Page 34] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[34ページ]RFC4181ガイドライン
internationalized text (which is always the case if the
object is intended for use by humans [RFC2277]). Designers
SHOULD consider using SnmpAdminString, Utf8String, or
LongUtf8String for such objects.
テキスト(オブジェクトが使用のために人間[RFC2277]によって意図されるなら、いつもケースである)を国際的にしました。 デザイナーSHOULDは、そのようなオブジェクトにSnmpAdminString、Utf8String、またはLongUtf8Stringを使用すると考えます。
Note 3. TDomain and TAddress SHOULD NOT be used in new MIB modules.
The TransportDomain, TransportAddressType, and
TransportAddress TCs (defined in TRANSPORT-ADDRESS-MIB
[RFC3419]) SHOULD be used instead.
3に注意してください。 TDomainとTAddress SHOULD、新しいMIBモジュールで、使用されないでください。 TransportDomain、TransportAddressType、およびTransportAddress TCs(TRANSPORT-ADDRESS-MIB[RFC3419]では、定義される)SHOULD、代わりに使用されてください。
The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411]:
以下のTCはSNMP-FRAMEWORK-MIB[RFC3411]で定義されます:
SnmpAdminString OCTET STRING (SIZE (0..255))
SnmpAdminString八重奏ストリング(サイズ(0 .255))
The following TCs are defined in SYSAPPL-MIB [RFC2287]:
以下のTCsはSYSAPPL-MIB[RFC2287]で定義されます:
Utf8String OCTET STRING (SIZE (0..255)) LongUtf8String OCTET STRING (SIZE (0..1024))
Utf8String八重奏ストリング(サイズ(0 .255))LongUtf8String八重奏ストリング(サイズ(0 .1024))
The following TCs are defined in INET-ADDRESS-MIB [RFC4001]:
以下のTCsはINET-ADDRESS-MIB[RFC4001]で定義されます:
InetAddressType enumerated INTEGER InetAddress OCTET STRING (SIZE (0..255)) InetAddressPrefixLength Unsigned32 (0..2040) InetPortNumber Unsigned32 (0..65535)) InetAutonomousSystemNumber Unsigned32 InetScopeType enumerated INTEGER InetZoneIndex Unsigned32 InetVersion enumerated INTEGER
InetAddressTypeはINTEGER InetAddress OCTET STRING(SIZE(0 .255))InetAddressPrefixLength Unsigned32(0 .2040)InetPortNumber Unsigned32(0 .65535)を数え上げました。 InetAutonomousSystemNumber Unsigned32 InetScopeType、列挙されたINTEGER InetZoneIndex Unsigned32 InetVersionはINTEGERを数え上げました。
The following TCs are defined in TRANSPORT-ADDRESS-MIB [RFC3419]:
以下のTCsはTRANSPORT-ADDRESS-MIB[RFC3419]で定義されます:
TransportDomain OBJECT IDENTIFIER TransportAddressType enumerated INTEGER TransportAddress OCTET STRING (SIZE (0..255))
TransportDomain OBJECT IDENTIFIER TransportAddressTypeはINTEGER TransportAddress OCTET STRINGを数え上げました。(サイズ(0 .255))
The following TC is defined in RMON2-MIB [RFC2021]:
以下のTCはRMON2-MIB[RFC2021]で定義されます:
ZeroBasedCounter32 Gauge32
ZeroBasedCounter32 Gauge32
The following TCs are defined in HCNUM-TC [RFC2856]:
以下のTCsはHCNUM-TC[RFC2856]で定義されます:
ZeroBasedCounter64 Counter64 CounterBasedGauge64 Counter64
ZeroBasedCounter64 Counter64 CounterBasedGauge64 Counter64
The following TCs are defined in IF-MIB [RFC2863]:
以下のTCsが定義される、-、MIB、[RFC2863]:
InterfaceIndex Integer32 (1..2147483647)
InterfaceIndex Integer32(1..2147483647)
Heard Best Current Practice [Page 35] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[35ページ]RFC4181ガイドライン
InterfaceIndexOrZero Integer32 (0..2147483647)
InterfaceIndexOrZero Integer32(0..2147483647)
The following TCs are defined in ENTITY-MIB [RFC4133]:
以下のTCsはENTITY-MIB[RFC4133]で定義されます:
PhysicalIndex Integer32 (1..2147483647) PhysicalIndexOrZero Integer32 (0..2147483647)
PhysicalIndex Integer32(1 .2147483647)PhysicalIndexOrZero Integer32(0..2147483647)
The following TCs are defined in PerfHist-TC-MIB [RFC3593]:
以下のTCsはPerfHist-TC-MIB[RFC3593]で定義されます:
PerfCurrentCount Gauge32 PerfIntervalCount Gauge32 PerfTotalCount Gauge32
PerfCurrentCount Gauge32 PerfIntervalCount Gauge32 PerfTotalCount Gauge32
The following TCs are defined in HC-PerfHist-TC-MIB [RFC3705]:
以下のTCsはHC-PerfHist-TC-MIB[RFC3705]で定義されます:
HCPerfValidIntervals Integer32 (0..96) HCPerfInvalidIntervals Integer32 (0..96) HCPerfTimeElapsed Integer32 (0..86399) HCPerfIntervalThreshold Unsigned32 (0..900) HCPerfCurrentCount Counter64 HCPerfIntervalCount Counter64 HCPerfTotalCount Counter64
HCPerfValidIntervals Integer32(0 .96)HCPerfInvalidIntervals Integer32(0 .96)HCPerfTimeElapsed Integer32(0 .86399)HCPerfIntervalThreshold Unsigned32(0 .900)HCPerfCurrentCount Counter64 HCPerfIntervalCount Counter64 HCPerfTotalCount Counter64
Appendix C: Suggested Naming Conventions
付録C: 提案された命名規則
Authors and reviewers of IETF MIB modules have often found the following naming conventions to be helpful in the past, and authors of new IETF MIB modules are urged to consider following them.
IETF MIBモジュールの作者と評論家は、過去にしばしば以下の命名規則に役立っているのがわかりました、そして、新しいIETF MIBモジュールの作者が、それらに続くと考えるよう促されます。
- The module name should be of the form XXX-MIB (or XXX-TC-MIB for a
module with TCs only), where XXX is a unique prefix (usually all
caps with hyphens for separators) that is not used by any existing
module. For example, the module for managing optical interfaces
[RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB.
- モジュール名はフォームXXX-MIB(または、TCsだけがあるモジュールのためのXXX-TC-MIB)のものであるはずです。そこでは、XXXがどんな既存のモジュールでも使用されないユニークな接頭語(通常分離符のためのハイフンがあるすべて大文字)です。 例えば、光学インタフェース[RFC3591]を管理するためのモジュールが使用する、接頭語、OPT、-、モジュール名を持っている、OPT、MIBです。
- The descriptor associated with the MODULE-IDENTITY invocation
should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx is
a mixed-case version of XXX starting with a lowercase letter and
without any hyphens. For example, the OPT-IF-MIB uses the prefix
optIf, and the descriptor associated with its MODULE-IDENTITY
invocation is optIfMibModule.
- MODULE-IDENTITY実施に関連している記述子はxxxがXXXが小文字から始まる複雑なケースバージョンであるところと少しもハイフンのないフォームのxxxMIB、xxxMib、またはxxxMibModuleのものであるはずです。 MODULE-IDENTITY実施に関連している接頭語optIf、および記述子はそうです。例えば、OPT、MIBである、用途、optIfMibModule。
- Other descriptors within the MIB module should start with the same
prefix xxx. OPT-IF-MIB uses the prefix optIf for all descriptors.
- MIBモジュールの中の他の記述子は同じ接頭語xxxから始まるべきです。 OPT、MIBである、すべての記述子に接頭語optIfを使用します。
Heard Best Current Practice [Page 36] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[36ページ]RFC4181ガイドライン
- Names of TCs that are specific to the MIB module and names of
SEQUENCE types that are used in conceptual table definitions should
start with a prefix Xxx that is the same as xxx but with the
initial letter changed to uppercase. OPT-IF-MIB uses the prefix
OptIf on the names of TCs and SEQUENCE types.
- TCsというMIBモジュールに特定の名前と概念的なテーブル定義に使用されるSEQUENCEタイプの名前は、xxxと同じ接頭語Xxxにもかかわらず、変える大文字から大文字し始めるべきです。 OPT、MIBである、TCsとSEQUENCEタイプの名前で接頭語OptIfを使用します。
- The descriptor associated with a conceptual table should be of the
form xxxZzzTable; the descriptor associated with the corresponding
conceptual row should be of the form xxxZzzEntry; the name of the
associated SEQUENCE type should be of the form XxxZzzEntry; and the
descriptors associated with the subordinate columnar objects should
be of the form xxxZzzSomeotherName. An example from the OPT-IF-MIB
is the OTMn table. The descriptor of the table object is
optIfOTMnTable, the descriptor of the row object is optIfOTMnEntry,
the name of the associated SEQUENCE type is OptIfOTMnEntry, and the
descriptors of the columnar objects are optIfOTMnOrder,
optIfOTMnReduced, optIfOTMnBitRates, optIfOTMnInterfaceType,
optIfOTMnTcmMax, and optIfOTMnOpticalReach.
- 概念的なテーブルに関連している記述子はフォームxxxZzzTableのものであるはずです。 対応する概念的な列に関連している記述子はフォームxxxZzzEntryのものであるはずです。 関連SEQUENCEタイプの名前はフォームXxxZzzEntryのものであるはずです。 そして、下位の円柱状の物に関連している記述子はフォームxxxZzzSomeotherNameのものであるはずです。 例、OPT、MIBである、OTMnはテーブルですか? 円柱状の物に関する記述子は、テーブル物に関する記述子がoptIfOTMnTableであり、列の物に関する記述子はoptIfOTMnEntryであり、関連SEQUENCEタイプの名前はOptIfOTMnEntryであり、optIfOTMnOrderと、optIfOTMnReducedと、optIfOTMnBitRatesと、optIfOTMnInterfaceTypeと、optIfOTMnTcmMaxと、optIfOTMnOpticalReachです。
- When abbreviations are used, then they should be used consistently.
Inconsistent usage such as
- 略語が使用されていると、それらは一貫して使用されるべきです。 矛盾した用法
xxxYyyDestAddr
xxxZzzDstAddr
xxxYyyDestAddr xxxZzzDstAddr
should be avoided.
避けられるべきです。
Appendix D: Suggested OID Layout
付録D: 提案されたOIDレイアウト
As noted in RFC 2578 Section 5.6, it is common practice to use the value of the MODULE-IDENTITY invocation as a subtree under which other OBJECT IDENTIFIER values assigned within the module are defined. That, of course, leaves open the question of how OIDs are assigned within that subtree. One assignment scheme that has gained favor -- and that is RECOMMENDED unless there is a specific reason not use it -- is to have three separate branches immediately below the MODULE-IDENTITY value dedicated (respectively) to notification definitions, object definitions, and conformance definitions, and to further subdivide the conformance branch into separate sub-branches for compliance statements and object/notification groups. This structure is illustrated below, with naming conventions following those outlined in Appendix C. The numbers in parentheses are the sub-identifiers assigned to the branches.
RFC2578セクション5.6に述べられるように、モジュールの中で割り当てられた他のOBJECT IDENTIFIER値が定義される下位木としてMODULE-IDENTITY実施の値を使用するのは、一般的な習慣です。 それはもちろんOIDsがその下位木の中でどう割り当てられるかに関する質問を戸外に発ちます。 好意(すなわち、特定の理由がない場合、RECOMMENDEDはそれを使用しない)を獲得した1つの課題計画は、MODULE-IDENTITY値のすぐ下における3つの別々のブランチを通知定義、オブジェクト定義、および順応定義に捧げさせて(それぞれ)、承諾声明と物/通知グループのためにさらに順応ブランチを別々のサブブランチに細分することです。 この構造は以下で例証されて、括弧の数はそれらに続くとコンベンションを命名するのとAppendix C.に概説されている、ブランチに配属されたサブ識別子です。
Heard Best Current Practice [Page 37] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[37ページ]RFC4181ガイドライン
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)
xxxMIB| +--xxxNotifications(0)+--xxxObjects(1)+--xxxConformance(2)| +--xxxCompliances(1)+--xxxGroups(2)
When using this scheme, notification definition values are assigned immediately below the xxxNotifications node. This ensures that each OID assigned to a notification definition has a next-to-last sub- identifier of zero, which is REQUIRED by Section 4.7 above. The other sub-branches may have additional sub-structure, but none beyond that specified in Section 4.6.5 above is actually required.
この計画を使用するとき、通知定義値はxxxNotificationsノードのすぐ下で割り当てられます。 これは、通知定義に割り当てられた各OIDがセクション4.7上のREQUIREDであるゼロに関する持続する次サブ識別子を持っているのを確実にします。 他のサブブランチには、追加基礎があるかもしれませんが、上のセクション4.6.5で指定されたそれを超えたなにも実際に必要ではありません。
One example of a MIB module whose OID assignments follow this scheme is the POWER-ETHERNET-MIB [RFC3621].
OID課題がこの計画に続くMIBモジュールに関する1つの例がPOWERイーサネットMIB[RFC3621]です。
Normative References
引用規格
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58, RFC
2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., and S. Waldbusser, "Textual Conventions
for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズ、M.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case,
J., Rose, M., and S. Waldbusser, "Conformance Statements
for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズ、M.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirements Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirements LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table
Extension to the Interfaces Group MIB", RFC 2864, June
2000.
[RFC2864] McCloghrieとK.とG.ハンソン、「インタフェースグループMIBへの逆さのスタックテーブル拡大」、RFC2864、2000年6月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Heard Best Current Practice [Page 38] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[38ページ]RFC4181ガイドライン
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC
3978, March 2005.
[RFC3978] ブラドナー、S.、「貢献におけるIETF権利」、BCP78、RFC3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] ブラドナー、S.、「IETF技術による知的所有権」、BCP79、RFC3979、2005年3月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
[RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using
Performance History Based on 15 Minute Intervals", RFC
3593, September 2003.
[RFC3593]Tesink、K.、「MIBモジュールのための15分の間隔に基づくパフォーマンス歴史を使用する原文のコンベンション」、RFC3593、2003年9月。
[RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions
for MIB Modules Using Performance History Based on 15
Minute Intervals", RFC 3705, February 2004.
[RFC3705]レイ、B.とR.Abbi、「15分の間隔に基づくパフォーマンス歴史を使用するMIBモジュールのための高容量の原文のコンベンション」RFC3705(2004年2月)。
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021,
January 1997.
[RFC2021] Waldbusser、S.、「1997年1月にSMIv2"、RFC2021を使用するリモートネットワーク監視管理情報ベースバージョン2。」
[RFC2856] Bierman, A., McCloghrie, K., and R. Presuhn, "Textual
Conventions for Additional High Capacity Data Types",
RFC 2856, June 2000.
[RFC2856] Bierman、A.、McCloghrie、K.、およびR.Presuhn、「追加高容量データ型のための原文のコンベンション」、RFC2856、2000年6月。
[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月)。
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of
System-Level Managed Objects for Applications", RFC
2287, February 1998.
[RFC2287]KrupczakとC.とJ.Saperia、「アプリケーションのためのシステムレベル管理オブジェクトの定義」、RFC2287、1998年2月。
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[RFC3418] Presuhn、R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのための管理情報ベース(MIB)は(SNMP)について議定書の中で述べます」、STD62、RFC3418、2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S.
Waldbusser, "Protocol Operations for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3416, December
2002.
[RFC3416]Presuhn(R.、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMP)のための操作について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)",
RFC 4133, August 2005.
[RFC4133]BiermanとA.とK.McCloghrie、「実体MIB(バージョン3)」、RFC4133 2005年8月。
Heard Best Current Practice [Page 39] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[39ページ]RFC4181ガイドライン
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions
for Transport Addresses", RFC 3419, December 2002.
[RFC3419] ダニエルとM.とJ.Schoenwaelder、「輸送アドレスのための原文のコンベンション」、RFC3419、2002年12月。
Informative References
有益な参照
[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。
[RFC2223bis] Reynolds, J. and R. Braden, "Instructions to Request for
Comments (RFC) Authors", Work in Progress, August 2004.
[RFC2223bis] 「(RFC)が書くコメントのために要求する指示」というレイノルズ、J.、およびR.ブレーデンは進歩、2004年8月に働いています。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネット標準の管理枠組みのための序論と適用性声明」、RFC3410(2002年12月)。
[RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4
Multicast Routing MIB", RFC 2932, October 2000.
2000年10月の[RFC2932]McCloghrieとK.とファリナッチ、D.とD.ターレル、「IPv4マルチキャストルート設定MIB」RFC2932。
[RFC1573] McCloghrie, K. and F. Kastenholz, "Evolution of the
Interfaces Group of MIB-II", RFC 1573, January 1994.
[RFC1573] McCloghrieとK.とF.Kastenholz、「MIB-IIのインタフェースグループの発展」、RFC1573、1994年1月。
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC
3621, December 2003.
[RFC3621]バーガーとA.とD.Romascanu、「パワーイーサネットMIB」、RFC3621 2003年12月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
BCP 74, RFC 3584, August 2003.
[RFC3584]フライとR.とレビとD.とRouthier、S.とB.Wijnen、「インターネット標準ネットワークマネージメント枠組みのバージョン1と、バージョン2と、バージョン3の間の共存」BCP74、RFC3584(2003年8月)。
[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K.
McCloghrie, "Definitions of Managed Objects for IEEE
802.3 Repeater Devices using SMIv2", RFC 2108, February
1997.
[RFC2108] deグラーフ、K.、Romascanu、D.、マクマスター、D.、およびK.McCloghrie、「1997年2月にSMIv2"、RFC2108を使用するIEEE802.3リピータ装置のための管理オブジェクトの定義。」
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management
Information Base for the Differentiated Services
Architecture", RFC 3289, May 2002.
[RFC3289]ベイカー(F.とチェン、K.とA.スミス、「微分されたサービス構造のための管理情報ベース」RFC3289)は2002がそうするかもしれません。
Heard Best Current Practice [Page 40] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[40ページ]RFC4181ガイドライン
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets - MIB-
II", STD 17, RFC 1213, March 1991.
[RFC1213] McCloghrie、K.、およびM.ローズ、「MIB II」、STD17、RFC1213、3月1991日TCP/IPベースのインターネットのNetwork Managementのための管理Information基地--
[RFC1595] Brown, T. and K. Tesink, "Definitions of Managed Objects
for the SONET/SDH Interface Type", RFC 1595, March 1994.
[RFC1595]ブラウンとT.とK.Tesink、「Sonet/SDHインターフェース型のための管理オブジェクトの定義」、RFC1595、1994年3月。
[RFC2558] Tesink, K., "Definitions of Managed Objects for the
SONET/SDH Interface Type", RFC 2558, March 1999.
[RFC2558]Tesink、K.、「Sonet/SDHインターフェース型のための管理オブジェクトの定義」、RFC2558、1999年3月。
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of
Managed Objects for the Optical Interface Type", RFC
3591, September 2003.
[RFC3591]ラム、H-K.、スチュワート、M.、およびA.Huynh、「光学インターフェース型のための管理オブジェクトの定義」、RFC3591(2003年9月)。
Editor's Address
エディタのアドレス
C. M. Heard 158 South Madison Ave. #207 Pasadena, CA 91101-2569 USA
C.M.は158の南マディソン街を聞きました。 #207 パサディナ、カリフォルニア91101-2569米国
Phone: +1 626 795 5311 EMail: heard@pobox.com
以下に電話をしてください。 +1 5311年の626 795メール: heard@pobox.com
Heard Best Current Practice [Page 41] RFC 4181 Guidelines for MIB Documents September 2005
MIBドキュメント2005年9月のための聞かれた最も良い現在の習慣[41ページ]RFC4181ガイドライン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Heard Best Current Practice [Page 42]
聞かれた最も良い現在の習慣[42ページ]
一覧
スポンサーリンク
