Network Working Group C. Heard, Ed.
Request for Comments: 4181 September 2005
BCP: 111
Category: Best Current Practice
Guidelines for Authors and Reviewers of MIB Documents
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).
著作権（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
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
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標準トラック仕様の専門家のレビューを必要とする方針を制定しました。これらのレビューは、[SMIv2のすべての構文とセマンティック要件（STD 58）の遵守（これらに限定されない）を含む、そのような仕様がIETFドキュメントの慣行を確立し、彼らは品質の一定の一般的に認められた基準を満たす含まれているMIBモジュールいること従っていることを確認するために設立されましたRFC2578]、[RFC2579]、[RFC2580] "標準" MIBモジュールに適用可能です。このメモの目的は、このようなレビューに続いているガイドラインを文書化することです。
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」の意味での「MUST NOT」、または「SHALL NOT」RFCで定義されている2119 [RFC2119]）このメモのガイドラインは、要件や禁止事項を変更するものではないことに注意してください、既存のこれらの要件や禁止事項があいまいか、矛盾している場合を除くのBCPまたはインターネット規格。曖昧さや矛盾が存在する例外的なケースでは、このメモは、現在一般的に認められた解釈を説明します。特定の場合では、このメモのガイドラインは、勧告を変更し、既存のBCPやインターネットの標準（RFC 2119で定義されているように、「べきでない」、「推奨」、「すべきである」という意味で、または「推奨しません」）です。実務経験が公開勧告は最適ではないことが示されているところで行われています。また、このメモは好ましいアプローチでコンセンサスが存在する場合には（RFC 2119で定義されるように、「MAY」又は「任意」の意味で）特定のSMIv2のオプションを選択するためのガイドラインを提供します。
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からSMIv2のに翻訳されているMIBモジュール（STD 16）[RFC1155] [RFC1212] [RFC1215]には適用されないことに注意する必要があります。
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"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONALこのメモのガイドラインで使用する場合、」、RFC 2119 [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モジュール」と「情報モジュールは、」このメモで交換可能に使用されます。ここで使用されるように、両方の用語は、RFC 2578 [RFC2578]のセクション3で定義された情報モジュール3種類のいずれかを指します。
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]と同じ意味で使用されています。特に、「標準」モジュールまたは「標準」のオブジェクト上でこれらの文書の課税要件を参照するために使用されます。
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標準トラックのRFCと同じ要件（[RFC2223bis]参照）の対象となっています。レビュー対象バージョンは、インターネットドラフトになりますので、特に、フロントページ上の通知はしていないのものとhttp://www.ietf.org/ietf/1id-guidelines.txtの要件を遵守しなければなりません[ RFC2223bis]。また、検討中の仕様がIESGに提出されることが予想されているので、それは必ずしものRFCには適用されません一定の要件を遵守しなければなりません。詳細については、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 Security Considerations部
o IANA Considerations section
O IANAの考慮事項のセクション
o References section
Oリファレンスセクション
Section-by-section guidelines follow.
セクション毎のガイドラインが続きます。
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でのオンライン利用可能である最新の承認のインターネット標準管理フレームワークの決まり文句の逐語的なコピーを含まなければなりません。
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モジュールの関係を（もしあれば）を指定概要セクションを含まなければなりません。物語の一部を簡単仕様で定義された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.
（SMIv2の文書で定義されたものを除いて、[RFC2578]、[RFC2579]、[RFC2580]）他のMIBモジュールから指定インポート定義によって定義されるか、またはMIBモジュールが常に他のMIBモジュールと組み合わせて実装されている場合、それらの事実は注意しなければなりません概要セクションでは、他のMIBモジュール内のオブジェクトのいずれかの特別な解釈しなければならないので。例えば、いわゆるメディア固有のMIBモジュールは常にIF-MIB [RFC2863]に関連して実装され、IF-MIB内の特定のオブジェクトを使用する方法を文書化する必要があります。また、のifStackTable [RFC2863]とifInvStackTable [RFC2864]に依存しているメディア固有のMIBモジュールは、階層化モデルの記述を含まなければならないインターフェイスサブレイヤの構成と多重化に関する情報を維持します。
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モジュール（複数可）を含有します。これらのMIBモジュールはSMIv2の[RFC2578]、[RFC2579]、[RFC2580]に書き込まれなければなりません。でSMIv1 [RFC1155] [RFC1212] [RFC1215]は、ステータス[RFC3410]を "推奨しない" とIETF MIBモジュールにはもはや許容されています。
See Section 4 for guidelines on SMIv2 usage.
SMIv2の使用に関するガイドラインについては、セクション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; 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.
一個の以上のMIBモジュールを定義し、各仕様は、それらのモジュールに関連するセキュリティ上の考慮事項について説明セクションを含まなければなりません。このセクションでは、最新の承認テンプレート（http://www.ops.ietf.org/mib-security.htmlで入手可能）の後にパターン化されなければなりません。具体的には、虐待を受けた場合に特に破壊的な可能性があり、書き込み可能なMIBオブジェクトは、明示的に名前が記載されている必要があり、および関連するセキュリティリスクが綴られなければなりません。同様に、特に機密性の高い情報が含まれているか、その重要なプライバシーの問題を提起読めるMIBオブジェクトは、明示的に名前が記載されている必要がありかつ感度/プライバシーの問題の理由を説明しなければなりません。 MIBオブジェクトの特定のカテゴリにはリスク/脆弱性が存在しない場合は、その事実が明確に記載しなければなりません。 MIBオブジェクトの特定のカテゴリを言及に失敗すると、そのカテゴリにリスク/脆弱性の主張と同一視されることはありません。むしろ、それは不作為の行為として扱われ、補正のために著者に返却された文書になります。目的は、この評価の結果を盲目的テンプレートからテキストをコピーするのではなく、リスク/脆弱性を考え、評価すると、その後の状態/文書ではないことに注意してください。
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の考慮事項のセクションを含まなければなりません。このセクションの要件は、アクションがIANAに求めているものによって異なります。
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によって投与される新しい名前空間を定義した場合、名前空間が投与されるか、その文書を指定RFC 2434 [RFC2434]に記載されたガイドラインに準拠したIANAの考慮事項のセクションを含まなければなりません。
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文書により定義された名前空間は、一般に、テキストの表記法（TC）によって定義されるいくつかのタイプ（通常は列挙された整数）の値の範囲または管理に定義されたオブジェクト識別子（OID）値のセットから成ります。各場合において、定義は、IANAによって維持されているスタンドアロンのMIBモジュールに収容されています。新しい割り当てが標準トラックRFCを再発行することなく行うことができるように、これらのIANA-維持MIBモジュールは、標準トラック仕様で定義されたMIBモジュールから分離されています。 IANA-維持MIBモジュールの例には、IF-MIB [RFC2863]で使用される名前空間を定義IANAifType-MIB（http://www.iana.org/assignments/ianaiftype-mib）、及びIANA-RTPROTOを含みますIPMROUTE-STD-MIB [RFC2932]で使用される名前空間を定義-MIB（http://www.iana.org/assignments/ianaiprouteprotocol-mib）。
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
このような場合のための現在の慣行は、各IANA-維持MIBモジュールおよび名前空間を定義するMIBドキュメントのIANA Considerations部のためのMODULE-IDENTITY呼び出しの記述節にRFC 2434に準拠した詳細なIANA Considerations部を含むことです関連するモジュールのURLを参照することができます。例えばRFC 2932 [RFC2932]を参照してください。これは、関連するIANA-維持MIBモジュールがまだ存在していますので、まだRFCとして発表されていないMIBドキュメントの鶏と卵の問題を作成します。このジレンマのうち受け入れ方法は、名前空間を定義し、文書の最初の問題の非標準セクションの各IANA-維持MIBモジュールの初期コンテンツを含むことです。例えば、[RFC1573]を参照して、どの
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保守モジュールは（参照[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の考慮事項のセクションが存在し、適切なIANA-維持MIBモジュールへのポインタが含まれていることをチェックしなければなりません。 IANA-維持MIBモジュールの提案された初期コンテンツを含むインターネットドラフトのレビューアはまた、MODULE-IDENTITY呼び出しの記述句は、RFC 2434のガイドラインに準拠しIANA Considerations部を含むことを確かめなければなりません。
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:
インターネットドラフトは、RFCとして公表前に、既存のレジストリを更新するために、IANAが必要な場合は、ドラフトにIANA問題セクションには、その事実を文書化しなければなりません。 MIBモジュールの初期バージョンが含まれているMIB文書は、一般的にIANAはMIBモジュールのMODULE-IDENTITY値のオブジェクト識別子の値を代入し、おそらく同様に他の割り当てを行うことが必要になります。更新されるレジストリを指定するIANA Considerations部は、オブジェクト識別子の値が割り当てされていた記述子、および値の割り当てが行われるその下のサブツリーを含まなければならないようなMIBモジュールを含むインターネットドラフト。出版後、それはオブジェクト識別子の割り当てを文書化するのに役立つであろうように、テキストが細工されるべきである（SHOULD）。例えば、次の線に沿って何か「は、MIB-2」サブツリーの下の値を割り当てられるMODULE-IDENTITY記述子powerEthernetMIB有する単一のMIBモジュールを含むインターネットドラフトのために適切であろう。
The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
この文書に記載されているMIBモジュールはSMI番号のレジストリに記録されている以下のIANAによって割り当てられたオブジェクト識別子の値を使用します。
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
powerEthernetMIB { mib-2 XXX }
powerEthernetMIB {MIB-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.
編集者注（出版前に除去される）：IANAは「MIB-2」サブツリーの下に「XXX」の値を割り当て、SMI番号レジストリの割り当てを記録することが要求されます。割り当てが行われた場合には、RFC Editorが割り当てられた値で（ここではとMIBモジュールで）「XXX」を交換すると、このノートを削除するように求めています。
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を参照してください。
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の考慮事項のセクションで文書化されなければなりません。インターネットドラフトは、以前に発表されたMIBモジュールのアップデートが含まれている場合、それは通常、IANAの一部上の任意のアクションを必要としませんが、それは、以前のバージョンを含むRFCから既存の割り当てを文書化するIANAの考慮事項のセクションを継承することができますMIBモジュール。このような場合、ドラフトノートを含まなければなりません明示的に何もIANAから必要とされないことを示している（出版前に除去されます）。例えば、POWER-ETHERNET-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によって割り当てられたオブジェクト識別子の値を使用します。
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
powerEthernetMIB { mib-2 105 }
powerEthernetMIB {MIB-2 105}
Editor's Note (to be removed prior to publication): this draft makes no additional requests of the IANA.
編集者注（出版前に削除される）：この草案は、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のアクションは、この文書で必要ありません。
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はインターネットドラフトで同じ要件を課します。具体的には、規範的で有益参照の別々のリスト、別々のセクションの各存在していなければなりません。スタイルは、最近発表されたRFCのものに従ってください。
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 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).
http://www.ops.ietf.org/mib-boilerplate.htmlで利用可能な標準MIBの決まり文句は、MIBモジュールを含むすべてのIETF仕様に現れなければならない規範的で有益な参考文献のリストを含んでいます。他のMIBモジュールからの項目が定義セクションのImportsステートメントに表示された場合、それらのMIBモジュールを含む仕様は、引用規格のリストに含まれなければなりません。項目はIANA-維持MIBモジュールからインポートされると、対応する規範的基準は、MIBモジュールのオンラインバージョンを指すものとします。これは、すべての参照がテキストで引用されなければならないことをRFC編集者の方針です。そのような引用は、（既にMIBボイラープレートに記載されたもの以外の）インポートされた定義を含む文書が言及する必要がある概要セクション（参照セクション3.2）に現れなければなりません。
In general, each normative reference SHOULD point to the most recent version of the specification in question.
一般的には、各引用規格は、問題の仕様の最新バージョンを指している必要があります。
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]セクション5.4およびRFC 3978の5.5に指定された著作権表示と免責事項を含まなければなりません。著者と査読は正しい年度はこれらの通知に挿入されていることを確認するためにチェックしなければなりません。また、公表RFCに表示される各MIBモジュールのMODULE-IDENTITYの呼び出しの説明句は、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
著作権（C）インターネット協会（日）。このMIBモジュールのこのバージョンはRFCのYYYYの一部です。完全な適法な通知についてはRFC自体を参照してください「 - 。RFCエド：実際のRFC番号にYYYYを置き換える＆このノートを削除
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
著作権（C）インターネット協会（日）。このMIBモジュールの初期バージョンはRFCのYYYYに掲載されました。完全な適法な通知についてはRFC自体を参照してください。補足で利用できる：http://www.ietf.org/copyrights/ianamib.html「 - RFCエド：実際のRFC番号にYYYYを置き換える＆このノートを削除してください。
In each case, the current year is to be inserted in place of the word "date".
それぞれのケースで、現在の年は、単語「日」の代わりに挿入されます。
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.
RFC 3979のセクション5 [RFC3979]は、すべてのIETFのRFCに表示する必要があり、知的財産権やその他の権利に関する注意事項が含まれています。その予告の逐語的なコピーがすべてのIETF MIBドキュメントに表示されます。
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モジュールがSMIv2のすべての構文とセマンティック要件を遵守しなければならない[RFC2578] [RFC2579] [RFC2580]「標準」のMIBモジュールに適用されることと下記のよう除いSMIv2の勧告に準拠すべきです。このセクションのガイドラインは次の方法で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.
好ましいアプローチについて合意がある場合にSMIv2のオプションを選択する際の指針を提供するために、O。
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).
RFC 2578第3節では、モジュール名の規則を指定します。 RFC 2578第3節の構文規則に従わなければならない、「標準」モジュールの名前は一意でなければならないことに特に注意し、MIBモジュールが改訂されたときに変更してはなりません（また、RFC 2578のセクション10を参照）。
It is RECOMMENDED that module names be mnemonic. See Appendix C for suggested naming conventions.
モジュール名は、ニーモニックすることをお勧めします。提案命名規則については、付録Cを参照してください。
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.
RFC 2578個のセクション3.1、7.1.1、および7.1.4およびRFC 2579第3節が記述子と名前を列挙INTEGERに関連付けられているマクロの呼び出しやラベルに関連付けられているとBITS値が32文字よりも、もはやすることをお勧めしませんが、彼らはもはやであることを必要としません64文字を超えます。
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.
32文字まで記述子、TC名、およびラベルを制限することは、多くの場合、（RFC 2578のセクション3.1およびRFC 2579のセクション3を参照）、彼らは一意であることが要件とニーモニックと（記述子とTC名用）も勧告と矛盾します。 MIBの審査の現在のプールのコンセンサスは32文字まで記述子、TC名、およびラベルを制限するためのSMIv2勧告は、明快さと独自性を促進に有利に確保されるべきであることと、そのようなMIBコンパイラなどの自動化ツールがデフォルトで生成してはならないことですその勧告に違反に対する警告。
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の命名規則については、付録Cを参照してください。
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.
RFC 2578のセクション4は、IANAによって維持されているオブジェクト識別子サブツリーを説明し、それらのサブツリーの用途を指定します。実験サブツリー{ISO 3 6 1 3}はIETFにおいて開発されているオブジェクトを識別するために使用されている間、特に、MGMTサブツリー{ISO 3 6 1 2}は、IETF「標準」オブジェクトを識別するために使用されます。 MIBモジュールは、IETF標準トラックに入ったときにオブジェクトがMGMTのサブツリーへの実験的なサブツリーから移動する必要があります。
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.
経験は、これらのオブジェクトは、運用環境での大規模な使用を見たら、別のサブツリーからオブジェクトを移動することは非現実的であることが示されています。したがって、運用環境での展開を対象としている任意のオブジェクトは関係なく、そのオブジェクトの標準化状況の、実験的なサブツリーの下で登録されてはなりません。実験サブツリーは、限られた実験的な展開のために意図されているオブジェクトに使用する必要があります。このようなオブジェクトは、通常の実験RFCで定義されています。
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.
注：用語「オブジェクト」は、ここで及びRFC 2578、セクション4で使用されることは、広くオブジェクト識別子の登録をもたらす任意の構築物として解釈されるべきです。このような構築物のリストは、RFC 2578のセクション3.6で指定されています。
RFC 2578 Section 3.2 specifies which symbols must be imported and also lists certain predefined symbols that must not be imported.
シンボルがインポートされ、また、輸入してはならない特定の事前定義されたシンボルを示していますする必要があり、RFC 2578個のセクション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 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.
一般的な要件は、事前に定義されたASN.1型またはBITS構築物以外の外部シンボルが使用される場合、それはモジュールの輸入文で言及されなければならないことです。そのセクションの最初の段落の単語「外部オブジェクトは、」次の段落を明確にすべきであるとして、そのようなシンボルが定義オブジェクトを参照するものに限定されているが、それはそうではないという印象を与えることができます。
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-準拠宣言のOBJECT句またはAGENT-CAPABILITIES文のVARIATION節に登場するオブジェクトの記述子については、RFC 2580個のセクション5.4.3と6.5.2で付与されていることに注意してください。 （見かけ上の見落としを介して）RFC 2580はないが、いくつかのMIBコンパイラはまたVARIATION節に現れる通知の記述子へと強制的GROUPS句、GROUP句によって参照されるオブジェクトグループの記述子と通知グループに免除を許可、または句を含みますこれらの例に言及していません。彼らは、彼らが本来よりも輸入のルールはより複雑で、モジュール間の依存関係あまり目立たせるための免除は時々助けにならないと見られています。コンプライアンスステートメントおよび機能ステートメントで参照される外部シンボルは、したがって、Importsステートメントに記載されているかもしれません。これが行われている場合、それは一貫して行うべきです。
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モジュールは、そうすべきではありません。
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.
RFC 2578第3節では、すべてのSMIv2 MIBモジュールがMODULE-IDENTITYマクロの正確に一つの呼び出しで開始する必要があります。この呼び出しは、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:
RFC 2578第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句はまた、ワーキンググループのWebページへのポインタを提供する必要があります。
- 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.
- リビジョン句は、MIBモジュールの各リビジョンのために存在していなければなりません、そして最新の改訂句のUTC時間がLAST更新句と一致しなければなりません。各リビジョンに関連付けられた記述句は、RFCにそのリビジョンが現れ、すべての重要な変更のリストを提供すべきで述べなければなりません。 MIBモジュールが改訂された場合、すべてのREVISION節でUTC時間は、4桁の年表記を使用するために更新する必要があります。
- 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記述子に割り当てられた値は、ユニークでMGMTサブツリー[RFC2578]の下に存在する必要があり（IETF標準トラックMIBモジュール用）でなければなりません。 IF-MIB [RFC2863]を延ばすメディア固有のMIBモジュールのために送信下でIANAによって割り当てられた値を使用することが通例であるが、ほとんどの場合、それは、[RFC2578]に直接MIB-2 [RFC2578]のIANAによって割り当てられた値となります。過去には、いくつかのIETFのワーキンググループは、IANAによってそれらに委任サブツリーから、自分の割り当てを行っているが、その練習は問題があることが証明されたとお勧めしません。
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編集者が記入しなければなりません。開発中のバージョンに適用さ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日DESCRIPTION - RFCエド：実際のRFC番号にYYYYを置き換える＆このノートを削除
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の発行後、改訂句のみMIBモジュールの公開バージョンのためだけでなく、インターネットドラフトとして存在中間バージョンの存在であることに留意されたいです。このように、MIBモジュールのドラフト版は、最後の公開バージョン（もしあれば）以来のすべての変更をカバーしてちょうど1新しいリビジョン句を含まなければなりません。
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によって割り当てられた値が使用される場合割り当て直前RFCとして文書に対して行われているため、MODULE-IDENTITY記述子に割り当てられた値は、不明であろう。このようなモジュールのドラフト版でMODULE-IDENTITY文の受け入れフォームは、次の線に沿って何かであります：
<descriptor> MODULE-IDENTITY
<記述> MODULE-IDENTITY
[ ... ]
「 。。。 」
::= { <subtree> XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this note
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を一時的にモジュールをコンパイルするために数で交換しなければならないことに留意されたいです。
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（参照セクション4.3）から得ることができます。
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のは、RFC 2578のセクション2で説明し、さらにRFC 2578のにセクション7.1.1を精緻、7.1.7、および7.1.11れます。オブジェクト定義またはテキストの表記これらのデータ型のいずれかを選択する場合は、次のガイドラインが適用されます。
- For integer-valued enumerations:
- 整数値の列挙の場合：
- INTEGER is REQUIRED; - Integer32, Unsigned32, and Gauge32 MUST NOT be used.
- INTEGERは必須です。 - 構文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].
その整数値の列挙は1から始まり、連続して番号付けされていることがRFC 2578が推奨する（しかし必要はない）に留意されたいです。そうでない場合、例えば、外部データの値に一致するように実行するか、特別な場合を示すために正当な理由がない限り、この推奨に従わなければならず、このような特殊なケースの使用は、明らかに文書化されるべきです。例えば、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節は、ラベルまたは数値のいずれかによって、デフォルト値を指定することができますが、RFC 2578のすべての例は、そのフォームのものであり、いくつかのツールは、数値形式を受け入れないので、ラベルの形が好ましいです。
- 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.
- 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（包括的）、次いで、最大値を超えて増加または最小値以下に低下することがモデル化されている情報の値の間にある場合。
- Gauge32 is RECOMMENDED;
- Unsigned32 is acceptable;
- INTEGER and Integer32 MUST NOT be used if
values greater than 2147483647 are possible.
- 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.
- 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のをお勧めします。 - 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句またはインデックス列で使用される整数値のTCに対して表示整数値オブジェクトの場合：
- 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のが最もインデックスオブジェクトに推奨されます。特殊な特性を有する一意の行のインデックス値として使用される場合、それが意味的に有意である場合、または範囲内にゼロを含めることが許容されます。このような使用方法が明確に説明節に文書化する必要があります。
- 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の又は非陰性範囲の整数で許容可能です。再び、ゼロは、それが特別な特性を有する一意の行のインデックス値として使用される場合、それは意味的に重要であるか、または場合を除き、範囲から除外されるべきであり、そのような場合には使用が明確に記述節に文書化されるべきです。
- 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.
上記のガイドラインは、最大RFC 2578のセクション7.7に整数データ型とINDEXルールの利用ルールの両方を組み合わせて、弾丸（1）を加えた28ページの最後から段落を含みます。
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] - 時にはそれは、インデックスオブジェクトの値を表すために外部変数のために必要であろう。このような場合には、そのオブジェクトを含むモジュールの作者は、InterfaceIndexの及び/又はInterfaceIndexOrZeroの[RFC2863]としてのTCを規定考慮すべきです。
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型であり、Integer32の、Gauge32、及びUnsigned32のに対し、モジュールのImportsステートメントに存在してはならないのSNMPv2-SMIによって定義され、使用される場合、そのモジュールからインポートされなければならないことに留意されたいです。
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:
2578セクション7.1.6と7.1.10、それぞれRFCで説明したようにCounter32のとカウンターには特別な意味を持っています。オブジェクトの定義は、必要があります（とテキストの表記法は、必要があります）、これらのセマンティクスを尊重します。それは意味します：
- 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であります）リセットします。しかしながら、そのような他の異常な/不規則なイベントが発生することが可能である場合、記述節は、これがそうであることを述べなければならないと管理アプリケーションがリセットするかどうかを判断することが可能であることを十分に詳細にこれらの他の異常な/不規則なイベントを記述しなければなりませんカウンタがポーリングされた最後の時間以降に発生しました。これを実行することをお勧めの方法は、RFC 2578個のセクション7.1.6と7.1.10で説明したように不連続性指標を提供することです。そのような不連続性指標の、例えば、IF-MIB [RFC2863]でifCounterDiscontinuityTimeオブジェクトを参照。
- 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].
- それはゼロにカウンタ（S）の値（複数可）をリセットするために、エージェントを要求する1人のマネージャーのためのOKはなく、Counter32の/ 64は、定期的にゼロに自分自身をリセットする「カウンター」の間違った構文です。後者のためには、RFC 3593 [RFC3593]またはRFC 3705 [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
「標準」MIBのRFC 2578個のセクション7.1.10場所要件Counter32のタイプが代わりに使用された場合Counter64のタイプは情報がモデル化されている場合にのみ使用することができるモジュールが1時間未満でラップします。今のSNMPv3は、インターネット標準とのSNMPv1が（根拠のステータスと[RFC3410]のためのhttp://www.rfc-editor.org/rfcxx00.htmlを参照してください）歴史的であることが、この制限を強制継続する理由はありません。今後は「標準」のMIBモジュールは、それがそうすることは理にかなっていたときにCounter64のタイプを使用することができ、使用しなければなりません
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時間未満でラップします。 1はまだそうすることを許可されているものの、各Counter64のオブジェクトのCounter32のカウンターパートを定義する必要がなくなっていることに注意してください。
There also exist closely-related textual conventions ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB [RFC2021] and HCNUM-TC [RFC2856], respectively.
またZeroBasedCounter32とZeroBasedCounter64それぞれRMON2-MIB [RFC2021]とHCNUM-TC [RFC2856]で定義された密接に関連するテキストの表記法が存在します。
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のTCとCounter32の/ 64の間の唯一の違いは、その開始値です。 Xは、それらが作成された後にそれらの最小ラップ・タイムであるX、=時、ZeroBasedCounter32 / 64の挙動が正確にCounter32の/ 64と同じになります。したがって、前の段落/ルールは、Counter32の/ 64だけでなく、ZeroBasedCounter32 / 64のTCのみならず当てはまります。
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のを使用するが、RFC 2579のセクション3.3の一般に認められた解釈の下で許可されている特殊なカウンタセマンティクスを破棄する。それはサブタイプとそれに定義されたオブジェクトは、INDEX句にも現れてはなりませんDEFVAL節を持ってはならない、と読み取りのMAX-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は、ゲージのセマンティクスを持つ64ビットの符号なしデータ型を必要とするオブジェクトの定義に使用されるべきです。異なる意味を持つ64ビットの符号なしデータ・タイプが必要とされる場合は、1つのTCは別の（参照RFC 2579のセクション3.5）を絞り込むことができないので、その後、カウンターに基づいて異なるTCは、使用しなければなりません。
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.
オクテット文字列型は、RFC 2578のセクション7.1.2に記載されています。これは、長さが0〜65535オクテット包括的である任意のバイナリまたはテキストデータを表します。実際の境界は、SMI-課される制限よりも制限されている場合、その構文このタイプのあるオブジェクトとTCSがサイズの制約を有しているべきです。これは、索引オブジェクトに当てはまります。 SMIは彼らが後で変更することが許可されていないよう注意は、しかし、そのサイズの制約は、任意に課されるべきではありません。
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.
専門のオクテットSTRINGタイプのためのより一般的な要件の一部に応える標準のTCの数が存在します。具体的には、SNMPv2の-TC [RFC2579]はDisplayStringの、PhysAddress、のMacAddress、及びのDateAndTimeのTCを含有します。 SNMP-FRAMEWORK-MIB [RFC3411]はれるSnmpAdminString TCが含まれています。そしてSYSAPPL-MIB [RFC2287]はUTF8STRINGとLongUtf8StringのTCが含まれています。標準TCが所望のセマンティクスを提供する場合、それは代わりオクテット文字列または同等のローカルに定義されたTCのオブジェクトのSYNTAX節で使用されるべきです。
Note that OCTET STRING is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
オクテット文字列は、事前に定義されたASN.1型であり、モジュールのImportsステートメントに存在してはならないことに注意してください。
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.
オブジェクト識別子タイプはRFC 2578のセクション7.1.3に記載されています。そのインスタンスは、管理上割り当てられた名前を表します。 SMIとSNMPプロトコル限界128サブ識別子にこのタイプのインスタンスとの両方が、各副識別子は、範囲内の0包括4294967295にあることを必要とすることに留意されたいです。サブタイピングは許可されていません。
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.
オブジェクト識別子値の目的は、アイテムのいくつかのタイプまたはアイテムのいくつかのタイプの特定のインスタンスのためのいずれかの権限の識別を提供することです。このように識別することができます項目のうちMODULE-IDENTITY、OBJECT-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、OBJECT-GROUP、NOTIFICATION-GROUP、MODULE-コンプライアンス、およびAGENT-CAPABILITIESを経て作成されたMIBモジュールの定義は、構築します。そしてMIBモジュール、プロトコル、言語、仕様、インターフェイスタイプ、ハードウェア、およびソフトウェアで定義されたオブジェクトのインスタンスを介し。これらのいくつかのために他の可能性は、例えば、オクテットストリングまたは列挙された整数値を使用して存在します。識別値のセットは、集中調整を提供するために、レジストリを必要とせずに独立して拡張可能である必要があるときにオブジェクト識別子タイプが代わりの選択肢の使用されるべきです。
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.
専門的なオブジェクト識別子タイプのためのより一般的な要件の一部に応える標準のTCの数が存在します。具体的には、SNMPv2の-TC [RFC2579]はAutonomousTypeの、VariablePointer、およびRowPointerのTCを含有します。標準TCが所望のセマンティクスを提供する場合、それはオブジェクトのSYNTAX節の代わりにオブジェクト識別子または同等のローカルに定義されたTCで使用されるべきです。
Note that OBJECT IDENTIFIER is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
オブジェクト識別子が事前に定義されたASN.1型であり、モジュールのImportsステートメントに存在してはならないことに注意してください。
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構築物は、RFC 2578のセクション7.1.4に記載されています。これは、名前のビットの列挙を表します。 SYNTAXこの型であるTCまたはオブジェクト定義内のビット位置は0で始まる必要があり、連続であるべきです。
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ステートメントに存在してはならないことに注意してください。
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.
RFC 2578のセクション7.1.5で説明したIPアドレスのタイプは、新しいMIBモジュールでは使用しないでください。 InetAddressの/ InetAddressTypeのテキストの表記法[RFC4001]は代わりに使用する必要があります。
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.
時間刻みタイプはRFC 2578のセクション7.1.8に記載されています。これは、2つのエポックの間の100分の1秒単位の時間は、モジュロ2 ^ 32を減少表します。これは、サブタイプであってはなりませんと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.
時間刻みタイプはのsysUpTime [RFC3418]のスナップショットであるオブジェクトの定義で直接使用するべきではありません。タイムスタンプTC [RFC2579]は既に所望のセマンティクスを搬送し、代わりに使用されるべきです。
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）。
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は、ブールタイプが必要なオブジェクト定義のSYNTAX句で使用する必要があります。 MIBモジュールは、列挙された整数型を使用するか、その意味を複製するのTCを定義するべきではありません。
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.
特殊なデータタイプのためのより一般的な要件の一部に応える標準のTCの数が存在します。いくつかは、上記されており、および付録Bは、それらに加えて、もう少し専門的ないくつか他の人が含まれて部分的なリストが含まれています。新しいTCSは開発されているように更新されたリストのオンライン版は、http://www.ops.ietf.org/mib-common-tcs.htmlで見つけることができます。
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が既に所望のセマンティクスを伝達するたびに、それは代わりに、対応する基本型または局所的に定義されたTCのオブジェクト定義で使用されるべきです。彼らはインターネット標準であるので、それらを参照モジュールが標準に発展の遅れを受けないので、これはSNMPv2の-TC [RFC2579]およびSNMP-FRAMEWORK-MIB [RFC3411]で定義されたTCの特にそうであるの口座に追跡このような参照。
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モジュールの作者は、列挙された整数またはBITS TCSはいくつかのケースでは、追加の列挙値または追加のビット位置で拡張することができることに注意する必要があります。このように拡張することができるインポートTCは、その後、サポートされる必要がある値またはビット位置の組が指定されるべきであり、リード作成テーブルに書き込まれ、またはそれが指標となることができるオブジェクトを定義するために使用された場合オブジェクトの説明節またはMIBモジュールの準拠宣言（複数可）でのOBJECT句のいずれか。これは、明示的に必要な値またはビット位置をリストすることによって行うことができる、またはそれは実装が値またはその選択したビット位置のサブセットをサポートすることを示すことによって行うことができます。
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.
すべてのオブジェクトとのTCのために、正確かつ明確な説明句の重要性を過度に強調することは困難です。 DESCRIPTION句は、実装者はオブジェクトを実装するために使用する命令が含まれ、それらが不十分または曖昧であれば、実装品質が低下します。おそらく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'.
非常に共通の問題は、単に「poofpoof」はどのような表示なしで「poofpoofsの数を」言うDESCRIPTION節で、たとえば、「stdMIBPoofpoofCounter」のオブジェクト定義を確認することです。このような場合には、それが強く推奨されるかは、少なくとも最低限の説明や他の「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.
（明確に定義された持続性を有するリード作成表の列以外）読み書きオブジェクトの場合には、説明句は、エージェントの再起動後の値がどうなるかを指定することをお勧めします。可能性の中で値が、それが明確に定義されたデフォルト値に戻り、または結果という実装依存であること、変わらないままであることです。
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-HINT句は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.
DISPLAY-HINT句である場合、オクテットストリングのTC用：管理アプリケーションは、典型的には列挙されない整数のTCのための16進形式（又は「1X」または「1x_」「1X」）に進形式（「D」）をデフォルトが不在、SMIv2のは、実際に任意のデフォルト値を指定していないことに留意すべきです。 MIBの著者は、明確なヒントがDISPLAY-ヒント句が存在する場合にのみアプリケーションに提供されていることを認識する必要があります。
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:
RFC 2578個のセクション7.1.12と7.1.12.1概念テーブルを定義するための規則を指定し、RFC 2578個のセクション7.7、7.8、および7.8.1は、概念テーブルの索引付け規則を指定します。次のガイドラインは、このような定義に適用されます。
- 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.
- 行が他のテーブルの行の拡張である場合の関係は一対一で、関係が疎である場合INDEX句を使用する必要がある場合、その後AUGMENTS句が使用されなければなりません。後者の場合には、INDEX句は、元の表のものと同一であるべきです。
- 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.
複数の行インスタンスがいくつかの他のテーブル内の単一の行インスタンスに対応する場合、ある - - 行は、拡張テーブルの要素が - の場合、インデックスの句を使用しなければなりません、そして最初に述べた要素は、インデックスであるべきですそのほかのテーブルの、同じ順序でリストされています。
- 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 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.
- 暗黙のキーワードの使用は、拡張テーブルのINDEX句に表示される可能性のあるインデックスオブジェクトにはお勧めできません。このキーワードのみINDEX句の最後のオブジェクトに関連付けることができるので、プライマリ・テーブル内の同じインデックスオブジェクトと拡張テーブルに関連付けることができません。これは、ソート順がプライマリ・テーブルとすべての拡張テーブルに異なることになります。その結果、実装は、拡張テーブルの主テーブルからインデックスコードを再利用することができなくなり、かつ拡張することを意図したデータ構造は、実際に複製する必要がある場合があります。黙示を使用するように誘惑されている設計者は、結果のソート順はめったに特に大文字と小文字の両方が含まれた文字列のため、ユーザーの期待を満たしていない、そしてそれは、アカウントにユーザーの言語またはロケールを取らないことを考慮すべきです。
- 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.
- RowStatusの[RFC2579]とリード作成のMAX-ACCESS値の構文値を有するもの円柱状のオブジェクトが存在すべきです。このオブジェクトは概念的な行のステータス列と呼ばれます。他のすべての円柱状のオブジェクトをリード作成し、読み取り専用、アクセス-FOR-通知、またはアクセス不可能のMAX-ACCESS値を持たなければなりません。読み書きのMAX-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]とのMAX-ACCESS値の構文値を有するもの円柱状のオブジェクトが存在していなければなりませんリード作成、あるいは行オブジェクト（テーブルエントリ）DESCRIPTION句は後行を動的に作成するために何が起こるかを指定しなければなりませんエージェントの再起動。
- 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（ステータス値がアクティブであるときに、行がアクティブである場合、その列に変更することができ、及びステータス欄の記述句は、他の列の修正可能を述べる必要があるかどうかを明記してください））、むしろ個々に修正列をリストよりも、（それらの列の説明句で指定されています。
- 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.
そのRFC 2578のセクション7.8注ベース行を増強概念的な列のインスタンスの寿命がベース行の対応するインスタンスと同じでなければならないことを要求します。 1つが既にベース行に存在する場合に増強行のRowStatusの又はStorageTypeカラムの必要がないことになります。
Complete requirements for the RowStatus and StorageType TCs can be found in RFC 2579, in the DESCRIPTION clauses for those TCs.
RowStatusのとStorageTypeのTCのための完全な要件は、これらのTCのための記述節では、RFC 2579で見つけることができます。
RFC 2578 Section 7.10 specifies the rules for assigning OBJECT IDENTIFIER (OID) values to OBJECT-TYPE definitions. In particular:
RFC 2578のセクション7.10に定義型のオブジェクトのオブジェクト識別子（OID）値を割り当てるための規則を指定します。特に：
- 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.
- 概念テーブルは、概念的な行で正確に一つの下位オブジェクトを有していなければなりません。概念的な列に割り当てられたOIDは、概念テーブルに割り当てられたOIDに「1」のサブ識別子を付加することにより誘導されなければなりません。
- 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.
- 行の列があるように概念的な列は、多くの従属オブジェクトを持ちます。少なくとも一つがあるに違いありません。各柱状オブジェクトに割り当てられた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登録もたらす別の定義に割り当てられてはいけません。 RFC 2578のセクション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, capabilities statements, and notification definitions not be registered beneath object definitions. See Appendix D for a RECOMMENDED OID assignment scheme.
それは、具体的にSMIによって必要とされないが、そのオブジェクト定義は、グループ定義、コンプライアンスステートメント、機能文、または通知の定義の下に登録されていない慣用（強く推奨）です。グループの定義、コンプライアンス・ステートメント、能力文、および通知の定義は、オブジェクト定義の下に登録されていないことも慣例（強く推奨）です。推奨OID割り当て方式については、付録Dを参照してください。
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.
RFC 2578のセクション3.5で指定されるように、全てのOIDは、128のサブ識別子に制限されています。これは、管理者の割り当てに問題が発生する可能性はありませんが、それはテーブルのインデックス作成にいくつかの制限を置きません。長さの制限は、オブジェクトインスタンスのOIDに適用されるので、それは本当であり、これらはオブジェクト定義に加えて、インデックスコンポーネントに割り当てられた「ベース」OIDの連結から成ります。表は、複数のサブ識別子に解決するようなオクテット文字列やオブジェクト識別子などのタイプの複数のインデックスを有する場合、次いで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（RFC 3416のセクション4.1での最後の段落[RFC3416]を参照）によって課されます。この制限に違反するのに十分なインデックスコンポーネントを持つ任意のテーブルが読み取りまたはSNMPを使用して書かれたので、使用できないことはできないということになります。したがって、テーブルデザインを考慮に128サブ識別子の制限を取らなければなりません。すべてのMIBの文書がインデックスコンポーネントの明示的な制限事項は、管理ソフトウェアが守らなければならないことを長することをお勧めします。これは、インデックスコンポーネントのサイズの制約を含めることによって、または概念的な行の記述節内または周囲のドキュメントに適用可能な制約を指定することによってのいずれかで行うことができます。
RFC 2578 Section 8 specifies the rules for notification definitions. In particular:
RFC 2578のセクション8は、通知の定義のための規則を指定します。特に：
- Inaccessible objects MUST NOT appear in the OBJECTS clause.
- アクセス不可能なオブジェクトは、オブジェクトの節に現れてはいけません。
- 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.
- オブジェクト節で述べた各オブジェクトタイプについて、説明句は、インスタンスが送信される通知に存在することで、搬送された情報/意味を指定しなければならないオブジェクトを指定しなければなりません。
- 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
- 情報の損失なしに再びでSMIv1トラップ定義にSMIv2の通知定義を変換することができるように、各通知タイプに割り当てられたオブジェクト識別子（OID）値（ゼロの次から最後のサブ識別子が必要（[RFC3584]セクション3を参照）の情報を失うことなく再びSNMPv1トラップへのSNMPv2トラップを翻訳とする多プロキシチェーンは[RFC3584]セクション2.1.2）と可能な参照。に
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の登録になり、別の定義に割り当てることはできません。 RFC 2578のセクション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.
それは、具体的にSMIによって必要とされないが、（それが生じ得るように、この最後は、特に賢明であるという通知定義はグループ定義、コンプライアンスステートメント、機能文、またはオブジェクト定義の下に登録されていない慣用（強く推奨）でありますオブジェクト・インスタンスと同一のOIDを共有通知定義）。また、通知タイプに割り当てられたOIDが葉のOID（通知定義に従属ないOID登録が存在しない、すなわち、こと）であることが通例（強く推奨）です。推奨OID割り当て方式については、付録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が設定可能である期間Tの任意の所定の時間間隔で各イベントソースには、複数の通知を生成しないことを要求するもので場合は、それが通知定義で指定された場合には、MIBオブジェクトで指定されている、またはそれが固定されていてもよいです。固定された時間間隔の技術の例は、SNMP-REPEATER-MIB [RFC2108]およびENTITY-MIB [RFC4133]に見出すことができます。
RFC 2580 Sections 3, 4, and 5 specify the rules for conformance groups and compliance statements. In particular:
RFC 2580のセクション3、4、および5は、適合グループとコンプライアンスステートメントのための規則を指定します。特に：
- Every object with a MAX-ACCESS value other than "not-accessible" MUST be contained in at least one object group.
- 「アクセス不可」以外のMAX-ACCESS値を持つすべてのオブジェクトは、少なくとも1つのオブジェクトグループに含まれなければなりません。
- 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:
コンプライアンス文を書くには、簡単に見落としている点がいくつかあります。
- 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.
- 必須-GROUPS句またはMODULE-COMPLIANCEステートメントの任意のグループ句のいずれかで言及されていないオブジェクトグループまたは通知グループは、コンプライアンスステートメントに対して無条件に任意です。オブジェクトグループまたは通知グループがオプションであることを示すために別の方法は、その記述句グループがオプションであることを述べてGROUP句にそれを言及することです。オプションのステータスが漏れの行為の結果ではなく、意図されていることを、後者の方法は、それを明確にするために（準拠宣言に関連するオプションのグループのために）推奨されています。
- 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.
- 任意のオブジェクトは読み取り専用のMIN-ACCESSを指定する一切OBJECT句がありませんそのため、書き込みを読んだり、リード作成のMAX-ACCESSの値である場合、その実装はさせるためにそれらのオブジェクトへの書き込みアクセスをサポートしている必要がありますそのMODULE-準拠宣言に準拠します。この事実は、時には驚きでMIBモジュールの作者をキャッチ。このような場合に直面すると、レビューアはそれは多くの場合ではありませんので、これは、作者が意図したもの確かであることを確認する必要があります。
- 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]によって与えられます。著者は、それが適用されたときに、この技術を使用して検討すべきです。
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節で許可された値のサブセットのみをサポートする必要があることを指定したいと思うでしょう。アクセス可能なオブジェクトの場合、これはオブジェクトの説明節に必要な値を指定することによって、またはコンプライアンス文で洗練された構文のオブジェクト句を提供することにより、いずれかを行うことができます。後者の方法は、ほとんどの場合に推奨され、そして必要とされる異なる値のサブセットを持つ複数のコンプライアンスステートメントが存在する場合に必要とされます。 DIFFSERV-MIB [RFC3289]はこの点を示しています。 diffServMIBFullCompliance文は、次のOBJECT句が含まれています。 （「これらの実施例およびRFC 2578に関する注記」、4.8.1項を参照してください。）
OBJECT diffServDataPathStatus SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required."
OBJECT diffServDataPathStatus構文RowStatus {アクティブ（1）} WRITE-構文RowStatus {createAndGo（4）、（6）を破壊}説明は "createAndWaitにおよびnotInServiceのためのサポートが必要とされません。"
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構文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の実装はリード作成表にいくつかの指標の可能な値のサブセットのみをサポートするために必要であることを示すことを望む可能性のあるしかし状況は、あります。このような場合、要求は（唯一の値のサブセットがある場合に推奨）インデックスオブジェクトの記述節または（値のサブセットが準拠ステートメントに一意である場合は必須）MODULE-COMPLIANCE文の記述節のいずれかで指定しなければなりません。
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モジュールと組み合わせて実装されています。その事実は、周囲のドキュメントに記載される必要がある（3.2節上記を参照）、そしてそれはまた、関連するコンプライアンス・ステートメントに注意すべきです。 （例えば）MIBモジュールAにおける特定のコンプライアンスステートメントがいくつかの他のMIBモジュールBの完全な実装を必要とする場合には、次に推奨されるアプローチは、MIBに準拠ステートメント（単数または複数）の記述節でその旨を含めることです例えば、モジュールAから無条件に必須のオブジェクトグループのいずれかを必要としないかもしれない - モジュールAはMIBモジュールAがモジュールBのいずれかの準拠ステートメントによって発現されるものとは異なる要件があるかもしれない、しかし、ことも可能ですモジュールBだけ条件付き必須このような場合、モジュールBのコンプライアンスステートメント（単数または複数）に関してはモジュールBからオブジェクトグループの必須の実装が必要になる場合があり、推奨されるアプローチは、モジュールAに準拠ステートメント（単数または複数）のためのものです正式に適切なモジュールを介してモジュールBに対する要件、強制的グループ、グループ、およびOBJECT句を指定します。例は必須のグループとしてIF-MIB [RFC2863]からifCounterDiscontinuityGroupをリストDIFFSERV-MIB [RFC3289]に準拠ステートメントによって提供されます。そのグループは、任意のIF-MIBの準拠宣言を満たすのに十分ではなく、IF-MIBの現在の準拠宣言ifCompliance3に条件付き必須です。
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
列挙を制限する構文の改良（RFC 2578、セクション9）上記の実施例に示すように、トップレベルユーザーと許可され、またはだけベースタイプで許可されるかどうかなど、いくつかの論争がありました
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].
RFC 2578 SMIv2の文書およびMIBの審査の現在のプールの編集者の荒いコンセンサスの厳密な解釈によって示唆されているようにINTEGERとBITSは、彼らは技術委員会で許可されなければならないということです。 MIBモジュールの作成者は、いくつかのMIBコンパイラは、RFC 2578の厳密な読み取りに従い、列挙が洗練されたときTCは、その基本型（整数またはBITS）によって置き換えられることを必要とすることを認識しなければなりません。その使用量は合法であり、それは、そのようなIF-MIB [RFC2863]などの一部の古いMIBモジュールで見つけることができます。
RFC 2578 Section 10 specifies general rules that apply any time a MIB module is revised. Specifically:
RFC 2578のセクション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更新句値が同じUTC時刻と変更を記述する関連した記述句を改訂句が追加されなければならない、改訂時間に設定しなければなりません、そして既存のDESCRIPTION、組織、および接触している任意の古い情報-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モジュールから除去してはいけません、そして既存の定義に関連した記述子とオブジェクト識別子の値があるはずがありません変更または再割り当て。
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モジュールは、モジュールの以前のバージョンに基づいて、フィールド化の実装と互換性があることを保証することであることに留意することが重要です。この下位互換性要件の二つの異なる側面があります。一つは、MIBモジュールの異なるリビジョンに基づいてエージェントとマネージャの実装の「ワイヤ上」互換性です。他には、改訂されたMIBモジュールの定義をインポートするMIBモジュールを搭載した「コンパイル」の互換性です。変更または再割り当てオブジェクト識別子値を禁止ルールは、互換性「ワイヤー上」確保するために必要です。モジュール名または記述子を変更したり、廃止された定義を除去に対するルールは、コンパイルの互換性を確保するために必要です。
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:
RFC 2578のセクション10.2は、オブジェクト定義の改正に適用される規則を指定します。次のガイドラインは、これらのルールに多少の誤差を修正し、いくつかの明確化を提供します。
- 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）弾丸を変更するという名前の数とタイプ列挙された整数またはBITSのSYNTAX節内の名前付きビットのラベルを可能にします。これらのラベルは、影響を受けるオブジェクトの定義をインポートするモジュールにDEFVAL節で使用することができるので、これは、コンパイルの互換性を破ることができます。したがって、（入力ミスを修正する以外）IETF MIBモジュールを修正するとき名前番号および名前付きビットのラベルは変更してはならない、およびエンタープライズ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.
- 具体的に弾丸（1）（8）、一般に整数値オブジェクトのSYNTAX節の範囲の制約を追加するために、許容されると考えられる介して許可されていないが、制約が単純で暗黙た明示的ないくつかの値の制限を行うことを条件としますオブジェクトの定義。最も一般的な例ではない範囲制約を持つ整数またはInteger32のの構文を使用して補助オブジェクトです。補助オブジェクトが負の値をとるように許可されていないので、範囲の制約（0 2147483647）を添加して、おそらく任意の「ワイヤ上」変化をもたらすことができない、またそれは正しく書き込まMIBモジュールとコンパイル・互換性の問題を引き起こすであろう。このような変化は社説変化としてではなく、意味的な変化として校閲者によって扱われるべきです。同様に、オブジェクト定義の範囲またはサイズ制約の除去、その範囲又はサイズ制約は、基礎となるデータの種類によって適用され、編集変化として投稿者によって扱われるべきです。
RFC 2578 Section 10.3 specifies rules that apply to revisions of notification definitions. No clarifications or corrections are required.
RFC 2578のセクション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:
RFC 2579第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）弾丸を変更するという名前の数とタイプ列挙された整数またはBITSのSYNTAX節内の名前付きビットのラベルを可能にします。これらのラベルは、影響を受けたのTCの定義をインポートモジュールにDEFVAL節で使用することができるので、これは、コンパイルの互換性を破ることができます。したがって、（入力ミスを修正する以外）IETF MIBモジュールを修正するとき名前番号および名前付きビットのラベルは変更してはならない、およびエンタープライズMIBモジュールを修正するとき、それらは変更してはなりません。
RFC 2580 Section 7.1 specifies rules that apply to revisions of conformance groups. Two point are worth reiterating:
RFC 2580のセクション7.1には、適合グループのリビジョンに適用される規則を指定します。二つのポイントは反復する価値があります：
- 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.
- 適合グループのステータスは、そのメンバーの状態とは無関係です。このように、現在のグループは、非推奨のオブジェクトまたは通知を参照してもよいです。これらは定義のより最新のセットで置き換えられるとき、これは、特定の場合には、例えば、広く展開されたオブジェクトまたは通知のセットが望ましい廃止されることができるが、それらを含む適合グループは、順番に、現在残っていることがあり非推奨のオブジェクトおよび通知の継続的な実施を奨励します。
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:
RFC 2580のセクション7.2には、コンプライアンス・ステートメントの改訂に適用される規則を指定します。次のガイドラインは、これらのルールからの漏れを訂正し、一つの重要なポイントを強調する：
- 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).
- RFC 2580は、べき（しかしない）列挙された整数オブジェクトまたはコンプライアンスステートメントによって参照されるBITSオブジェクトが列挙または名前付きビットと仮定すると、追加したときの値のオリジナルセットのオブジェクト句指定サポートが準拠ステートメントに追加することをお勧めしますそのような句が既に存在せず、有効なMIN-ACCESS値がされていることを読み取り書き込みまたは読み取り作成すること。これは、コンプライアンス文の意味にサイレントな変化を避けるために必要です。 MIBモジュールの作成者とレビューアは、必要なときに、このような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.
- 準拠宣言のステータスは、そのメンバーの状態とは無関係です。このように、現在の準拠宣言は非推奨オブジェクトグループまたは通知先グループを参照してもよいです。これらは定義のより最新のセットで置き換えられるとき、これは、特定の場合には、例えば、広く展開されたオブジェクトまたは通知グループのセットが望ましい廃止されることができるが、それらを参照して、コンプライアンス・ステートメントは、現在の残ることがあり廃止予定のグループの継続的な実施を奨励するため。
RFC 2580 Section 7.3 specifies rules that apply to revisions of capabilities statements. The following guideline corrects an omission from these rules:
RFC 2580のセクション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 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.
- RFC 2580は、べき（しかしない）機能ステートメントによって参照列挙INTEGERオブジェクトまたはBITSオブジェクトが列挙は、そのような句が既にされていないことを仮定して、追加したときの値のオリジナルセットのサポートを指定ばらつき句は、機能ステートメントに追加することをお勧めします存在。これは、能力文の意味にサイレントな変化を避けるために必要です。
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のルールを以下のコストが利益を超えてもよいです。このような場合には、ルールは適用されませんが、それが行われたときにそれのための変化と正当化の両方が完全に文書化されなければなりません。一例では、IF-MIB [RFC2863]にMIB-II [RFC1213]からの遷移でのifIndexに作られ、その変更の詳細な正当化を提供した意味論的変化を文書RFC 2863のセクション3.1.5によって提供されます。読み取り専用の以前のバージョン[RFC1595]との互換性のためのMIN-ACCESSを添加しながら別の例は、いくつかのオブジェクトのMAX-ACCESSを上げる文書が読み書きすることSONET-MIB [RFC2558]の改訂句によって提供されます。
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モジュールの二つのリビジョン間の差分を一覧表示することができますツールを使用するかもしれません。詳細についてはhttp://www.ops.ietf.org/mib-review-tools.htmlを参照してください。
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、ボブブレーデン、ミシェル・コットン、デヴィッド・ハリントン、Harrie Hazewinkel、Dinakaranジョセフ、マイケルKirkham：最後に、感謝は、そのコメントがこのメモの以前のバージョンの追加、明確化、および訂正のための多くの貴重な示唆を含んで以下の個人によるものですキースMcCloghrie、デヴィッドT.パーキンス、ランディPresuhn、ダンRomascanu、ユルゲンSchoenwaelder、フランク・シュトラウス、デーブターラー、およびバートWijnen。
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モジュールの実装と展開は、そうでない場合は存在しないだろう、セキュリティリスクをもたらすことができます。これは、すべてのそのようなリスクが適切に開示されているように、それらの文書は、完全にhttp://www.ops.ietf.org/mib-security.htmlのガイドラインに準拠していることを確認するためにMIBモジュールを定義する文書の著者と査読のために重要です。
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の考慮事項のセクションに存在することが要求される内容を説明する程度にIANAに影響を与えますが、それはIANAは既存のレジストリを更新したり、新しいレジストリを作成する必要はありません。
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のレビューの目的は、技術的な正確さとIETF文書化要件の遵守のために、両方のMIBモジュールを検討することです。ドラフト文書をレビューするときは、次のチェックリストが役立つことがあります
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.）IDボイラープレートが - RFCとして公表を可能にするために適切な声明を含め、（http://www.ietf.org/ietf/1id-guidelines.txtを参照）の草案が必要なインターネットドラフトの定型が含まれていることを確認し、そのIDの定型を参照またはセクション番号が含まれていません。
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定型 - ドラフトはOPSエリアのウェブサイト（http://www.ops.ietf.org/mib-boilerplate.html）から最新の承認されたSNMPネットワーク管理フレームワークの決まり文句が含まれていることを確認します。
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.）Security Considerations部 - ドラフトはOPSエリアのWebサイトから最新の承認済みのテンプレートを使用していることを確認します（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問題部 - このセクションでは、常に存在する必要があります。草案は、IANAからのアクションを必要としない場合は、これを明示的に指摘されていることを確認してください。ドラフトが割り当てられるOID値を必要とする場合は、IANAの考慮事項のセクションでは、これらのガイドラインの3.5節で指定された情報が含まれていることを確認してください。ドラフトはIANA-保持モジュールの初期バージョンが含まれている場合は、MODULE-IDENTITYの呼び出しは、後者の場合にはRFC 2434の要求に準拠メンテナンス命令を含む、RFCに表示される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）参照 - 参照が正しく規範と有益参考間で分割されていることを確認し、そのRFC 2119は、内部に画定された用語が文書内で使用される場合、ボイラープレートによって必要とされるすべての参照が存在することを、規範的基準として含まれていることをインポートされた項目を含むすべてのMIBモジュールは、規範的参照として引用され、そうでなければ実行する正当な理由がない限り、すべての引用は、最新のRFCを指していること（例えば、仕様の以前のバージョンに有益な参照を含むことがOKであるれています下位互換性のために含まれる特徴を説明するために）。
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.）著作権 - ドラフトは各MODULE-IDENTITYの呼び出しの説明句の省略著作権情報が含まれていることを確認し、それがの終わりに、セクション5.4およびRFC 3978の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のお知らせ - ドラフトはRFC 3979のセクション5で指定されたIPR通知の逐語的なコピーが含まれていない場合には、知的財産権の通知が含まれることをお勧めします。
9.) Other Issues -- check for any issues mentioned in http://www.ietf.org/ID-Checklist.html that are not covered elsewhere.
9.）その他の問題 - 他の場所でカバーされていない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）技術的な内容 - このドキュメントのガイドラインに準拠して、実際の技術的な内容を確認します。構文エラーをチェックするとき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]:
以下のTCは、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))
TruthValueがINTEGER TestAndIncr INTEGER（0 2147483647）AutonomousTypeのオブジェクト識別子VariablePointerオブジェクト識別子RowPointerオブジェクト識別子のRowStatusがINTEGERタイムスタンプ時間刻み時間間隔を列挙列挙DisplayStringのオクテットSTRING（SIZE（0..255））PhysAddress OCTET STRINGのMacAddressオクテットSTRING（SIZE（6）） INTEGER（0 2147483647）のDateAndTimeオクテットSTRING（SIZE（8 | 11））StorageType列挙INTEGERのTDomainオブジェクト識別子TAddressオクテットSTRING（SIZE（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 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.
2. DisplayStringのは、国際化テキストをサポートしていません。これは、（オブジェクトが人間[RFC2277]での使用のために意図されている場合は常にそうである）国際テキストを保持するために必要とされる目的のために使用してはいけません。設計者は、このようなオブジェクトに対してれる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は、新しいMIBモジュールでは使用しないでください。 （TRANSPORT-ADDRESS-MIB [RFC3419]で定義される）TransportDomain、TransportAddressType、及びTransportAddress TCSを代わりに使用してください。
The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411]:
以下TCは、SNMP-FRAMEWORK-MIB [RFC3411]で定義されます。
SnmpAdminString OCTET STRING (SIZE (0..255))
れるSnmpAdminStringオクテットSTRING（SIZE（0 255））
The following TCs are defined in SYSAPPL-MIB [RFC2287]:
以下のTCは、SYSAPPL-MIB [RFC2287]で定義されています。
Utf8String OCTET STRING (SIZE (0..255)) LongUtf8String OCTET STRING (SIZE (0..1024))
UTF8STRINGオクテットSTRING（SIZE（0..255））LongUtf8StringオクテットSTRING（SIZE（0..1024））
The following TCs are defined in INET-ADDRESS-MIB [RFC4001]:
以下のTCは、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のはInetAutonomousSystemNumber Unsigned32のInetScopeTypeがINTEGER InetZoneIndex Unsigned32のInetVersionはINTEGERを列挙列挙INTEGER InetAddressのOCTET STRING（SIZE（0..255））InetAddressPrefixLengthのUnsigned32（0..2040）InetPortNumberのUnsigned32（0 65535））を列挙しました
The following TCs are defined in TRANSPORT-ADDRESS-MIB [RFC3419]:
以下のTCは、トランスポート・アドレス・MIB [RFC3419]で定義されています。
TransportDomain OBJECT IDENTIFIER TransportAddressType enumerated INTEGER TransportAddress OCTET STRING (SIZE (0..255))
TransportDomain OBJECT IDENTIFIER TransportAddressTypeはINTEGER TransportAddress OCTET STRING（SIZE（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]:
以下のTCはHCNUM-TC [RFC2856]で定義されています。
ZeroBasedCounter64 Counter64 CounterBasedGauge64 Counter64
ZeroBasedCounter64 Counter64のCounterBasedGauge64 Counter64の
The following TCs are defined in IF-MIB [RFC2863]:
以下のTCは、IF-MIB [RFC2863]で定義されています。
InterfaceIndex Integer32 (1..2147483647)
InterfaceIndexの構文Integer32（1 2147483647）
InterfaceIndexOrZero Integer32 (0..2147483647)
InterfaceIndexOrZeroの構文Integer32（0 2147483647）
The following TCs are defined in ENTITY-MIB [RFC4133]:
以下のTCは、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]:
以下のTCは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]:
以下のTCは、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は任意の既存のモジュールによって使用されていない固有のプレフィックス（セパレータのためのハイフン付き通常すべて大文字）で、（唯一のTCを有するモジュールまたはXXX-TC-MIB）形式XXX-MIBであるべきです。例えば、光インタフェース[RFC3591]を管理するためのモジュールは、プレフィックスOPT-IFを使用して、モジュール名OPT-IF-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、でなければなりません。例えば、OPT-IF-MIBには、接頭辞optIfを使用し、そのMODULE-IDENTITYの呼び出しに関連付けられた記述子は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-IF-MIBは、すべての記述子のプレフィックスoptIfを使用しています。
- 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.
- MIBモジュールと概念的なテーブル定義で使用されているSEQUENCE型の名前に固有の技術委員会の名前はXXXと同じですが、最初の文字が大文字に変更されているプレフィックスxxxの起動する必要があります。 OPT-IF-MIBは、技術委員会と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でなければなりません。関連配列型の名前は、フォームXxxZzzEntryでなければなりません。そして下位の円柱状のオブジェクトに関連付けられた記述子は、フォームxxxZzzSomeotherNameでなければなりません。 OPT-IF-MIBの例はOTMnテーブルです。表オブジェクトの記述子はoptIfOTMnTableで、行オブジェクトの記述子はoptIfOTMnEntry、関連配列の型の名前はOptIfOTMnEntryである、柱状オブジェクトの記述子はoptIfOTMnOrder、optIfOTMnReduced、optIfOTMnBitRates、optIfOTMnInterfaceType、optIfOTMnTcmMax、及びoptIfOTMnOpticalReachあります。
- When abbreviations are used, then they should be used consistently. Inconsistent usage such as
- 略語が使用される場合、それらは一貫して使用する必要があります。以下のような使用法に一貫性がありません
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.
RFC 2578のセクション5.6で述べたように、モジュール内に割り当てられ、他のオブジェクト識別子の値が定義されている下のサブツリーとしてMODULE-IDENTITY呼び出しの値を使用するのが一般的です。それは、当然のことながら、OIDのはそのサブツリー内に割り当てられているかの質問を開いたまま。通知の定義、オブジェクト定義、および適合にすぐに（それぞれ）専用のMODULE-IDENTITY値以下に3本の別々の枝を持つことである - そしてそれを使用しない特別な理由がない限り、それが推奨される - 賛成を得ている1つの割り当てスキームさらに、コンプライアンスステートメントおよびオブジェクト/通知グループのために別々のサブブランチに適合ブランチを再分割するための定義、および。この構造は、括弧内の数字は分岐に割り当てられたサブ識別子で付録Cに概略を示したもの次の命名規則を用いて、以下に示されています。
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で必要とされるゼロの次から最後のサブ識別子を有することを保証します。他のサブブランチは、追加のサブ構造を有していてもよいが、4.6.5で指定される以上、いずれも上記実際に必要とされません。
One example of a MIB module whose OID assignments follow this scheme is the POWER-ETHERNET-MIB [RFC3621].
OID割り当て、このスキームに従うMIBモジュールの一例は、POWER-ETHERNET-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）の構造"、STD 58、RFC 2578 、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のためのテキストの表記法"、STD 58、RFC 2579、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のための適合性宣言"、STD 58、RFC 2580、1999年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、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への逆積層テーブル拡張"、RFC 2864、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問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]ブラドナーの、S.、 "質問の投稿IETF権"、BCP 78、RFC 3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]ブラドナーの、S.、 "IETF技術の知的財産権"、BCP 79、RFC 3979、2005年3月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]ダニエル、M.、ハーバーマン、B.、Routhier、S.、およびJ. Schoenwaelder、 "インターネットネットワークアドレスのためのテキストの表記法"、RFC 4001、2005年2月。
[RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3593, September 2003.
[RFC3593] Tesink、K.、RFC 3593、2003年9月 "15分間隔に基づいて、パフォーマンス履歴を使用してMIBモジュールのためのテキストの表記法"。
[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.アビー、RFC 3705、2004年2月「MIBモジュールは、15分間隔に基づいて、パフォーマンス履歴を使用するための大容量のテキストの表記法」。
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[RFC2021] Waldbusser、S.、 "リモートネットワーク監視管理情報ベースバージョン2のSMIv2を使用して"、RFC 2021、1997年1月。
[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、 "追加高容量データ型のテキストの表記法"、RFC 2856、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の、STD 62、RFC 3411、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"。
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998.
[RFC2287] Krupczak、C.とJ. Saperia、RFC 2287、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）"、STD 62、RFC 3418、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、STD 62、RFC 3416 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作"、2002年12月。
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
[RFC4133] Bierman、A.およびK. McCloghrie、 "エンティティMIB（バージョン3）"、RFC 4133、2005年8月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, December 2002.
[RFC3419]ダニエル、M.及びJ. Schoenwaelder、 "トランスポート・アドレスのためのテキストの表記法"、RFC 3419、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.
[RFC1155]ローズ、M.、およびK. McCloghrie、 "構造とTCP / IPベースのインターネットのための経営情報の識別"、STD 16、RFC 1155、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212]ローズ、M.、およびK. McCloghrie、 "簡潔なMIB定義"、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、M.、 "SNMPとの使用のためのDefining Trapsのための条約"、RFC 1215、1991年3月。
[RFC2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[RFC2223bis]レイノルズ、J.、およびR.ブレーデン、 "コメント（RFC）作者の要求への指示は" 進歩、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.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000.
[RFC2932] McCloghrie、K.、ファリナッチ、D.、およびD.ターラー、 "IPv4マルチキャストルーティングMIB"、RFC 2932、2000年10月。
[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のインタフェースグループの発展"、RFC 1573、1994年1月。
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003.
[RFC3621]バーガー、A.とD. Romascanu、 "パワー・イーサネットMIB"、RFC 3621、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の間の共存"、BCP 74、RFC 3584 、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]グラーフ、K.、Romascanu、D.、マクマスター、D.、およびK. McCloghrieド、RFC 2108、1997年2月 "SMIv2のを使用してIEEE 802.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.スミス、 "差別化サービスアーキテクチャのための管理情報ベース"、RFC 3289、2002年5月。
[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.ローズ、 "TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース - MIB-II"、STD 17、RFC 1213、1991年3月。
[RFC1595] Brown, T. and K. Tesink, "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC 1595, March 1994.
[RFC1595]ブラウン、T.とK. Tesink、RFC 1595 "SONET / SDHインタフェースタイプのための管理オブジェクトの定義"、1994年3月。
[RFC2558] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC 2558, March 1999.
[RFC2558] Tesink、K.、RFC 2558 "SONET / SDHインタフェースタイプのための管理オブジェクトの定義"、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.フイン、 "光インタフェースタイプのための管理オブジェクトの定義"、RFC 3591、2003年9月。
Editor's Address
編集者の住所
C. M. Heard 158 South Madison Ave. #207 Pasadena, CA 91101-2569 USA
C. M.聞い158南マディソンアベニュー。 ＃207パサデナ、CA 91101から2569 USA
Phone: +1 626 795 5311 EMail: heard@pobox.com
電話：+1 626 795 5311 Eメール：heard@pobox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。