[要約] RFC 4181は、MIB文書の作成者とレビューアーのためのガイドラインです。その目的は、MIB文書の品質と一貫性を向上させることです。
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
MIB文書の著者およびレビュアーのガイドライン
Status of This Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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標準トラック仕様の専門家レビューを要求するポリシーを制定しました。これらのレビューは、そのような仕様が確立されたIETFドキュメントプラクティスに従い、それらに含まれるMIBモジュールが、SMIV2（STD 58）のすべての構文およびセマンティック要件へのコンプライアンスを含む（ただし、これらに限定されない）、一般的に受け入れられている品質基準を満たすことを保証するために確立されました[STD 58）[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.
このメモのガイドラインは、既存のRFC 2119 [RFC2119]で定義されているように、「必須」、「そうでない」、「そうでない」、「そうしない」という意味での要件や禁止の意味を変更することを意図していないことに注意してください。これらの要件または禁止が曖昧または矛盾している場合を除き、BCPまたはインターネット標準。あいまいさまたは矛盾が存在する例外的な場合、このメモは、一般的に受け入れられている解釈を文書化しています。特定の例では、このメモのガイドラインは、既存のBCPまたはインターネット標準の推奨事項を変更します。これは、公開された推奨事項が最適ではないことを実際の経験が示している場合に行われました。さらに、このメモは、好ましいアプローチにコンセンサスがある場合に、特定のSMIV2オプション（RFC 2119で定義されている「5月」または「オプション」の意味で）を選択するためのガイドラインを提供します。
Although some of the guidelines in this memo are not applicable to non-standards track or non-IETF MIB documents, authors and reviewers of those documents should consider using the ones that do apply.
このメモのガイドラインのいくつかは、非標準のトラックまたは非ITF 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（STD 16）[RFC1155] [RFC1212] [RFC1215]からSMIV2に翻訳されたMIBモジュールに適用されないことに注意する必要があります。
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].
キーワード「必須」、「しない」、「必須」、「shall」、「shall」、「obs "of"、 "not"、 "becommended"、 "becommented"、 "may"、 "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 セキュリティ上の考慮事項セクション
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.
他のMIBモジュールからの仕様インポート定義で定義されたMIBモジュール（SMIV2ドキュメント[RFC2578] [RFC2579] [RFC2580]で定義されているものを除く）、または他の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;
1つ以上のMIBモジュールを定義する各仕様には、それらのモジュールに関連するセキュリティに関する考慮事項を議論するセクションを含める必要があります。このセクションは、最新の承認済みテンプレート（http://www.ops.ietf.org/mib-security.htmlで入手可能）をパターン化する必要があります。特に、虐待された場合に特に破壊的である可能性のある書き込み可能なMIBオブジェクトは、名前で明示的にリストされなければならず、関連するセキュリティリスクを綴る必要があります。同様に、特に機密情報を含む、または重大なプライバシーの懸念を提起する読みやすいMIBオブジェクトは、名前で明示的にリストされなければならず、感度/プライバシーの懸念の理由を説明する必要があります。MIBオブジェクトの特定のカテゴリにリスク/脆弱性がない場合、その事実を明示的に述べなければなりません。MIBオブジェクトの特定のカテゴリに言及しないことは、そのカテゴリのリスク/脆弱性のない主張とは等しくありません。
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.
むしろ、それは省略の行為として扱われ、その結果、文書は修正のために著者に返されます。目的は、テンプレートからテキストを盲目的にコピーすることではなく、リスク/脆弱性を考えて評価し、この評価の結果を述べ/文書化することであることを忘れないでください。
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モジュールに収容されています。これらのIANAが維持したMIBモジュールは、標準トラック仕様で定義されているMIBモジュールとは別に、標準トラックRFCを再発行することなく新しい割り当てを作成できます。IANAが維持したMIBモジュールの例には、IANAIFTYPE-MIB（http://www.iana.org/assignments/ianaiftype-mib）が含まれます。-MIB（http://www.iana.org/assignments/ianaiprouteprotocol-mib）。これは、IPMroute-std-mib [rfc2932]で使用される名前空間を定義します。
The current practice for such cases is to include a detailed IANA Considerations section complying with RFC 2434 in the DESCRIPTION clause of the MODULE-IDENTITY invocation in each IANA-maintained MIB module and for the IANA Considerations section of the MIB document that defines the name spaces to refer to the URLs for the relevant modules. See RFC 2932 [RFC2932] for an example. This creates a chicken-and-egg problem for MIB documents that have not yet been published as RFCs because the relevant IANA-maintained MIB modules will not yet exist. The accepted way out of this dilemma is to include the initial content of each IANA-maintained MIB module in a non-normative section of the initial issue of the document that defines the name space; for an example, see [RFC1573], which 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]).
このようなケースの現在の慣行は、各IANAが維持したMIBモジュールのモジュール同意の呼び出しの説明句と、名前のスペースを定義するMIBドキュメントのIANAに関する考慮事項セクションに、RFC 2434に準拠した詳細なIANAの考慮事項セクションを含めることです。関連するモジュールのURLを参照します。例については、RFC 2932 [RFC2932]を参照してください。これにより、関連するIANAが維持したMIBモジュールがまだ存在しないため、RFCSとしてまだ公開されていないMIBドキュメントに鶏と卵の問題が生じます。このジレンマからの認められた方法は、名前空間を定義するドキュメントの初期問題の非規範的なセクションに、各IANAが維持したMIBモジュールの初期コンテンツを含めることです。たとえば、[RFC1573]を参照してください。これは、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モジュールの提案された初期コンテンツを含むインターネットドラフトのレビュー担当者は、モジュール同意の呼び出しの説明条項に、RFC 2434のガイドラインに準拠したIANA考慮事項が含まれていることも確認する必要があります。
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モジュールのモジュール同一性値にオブジェクト識別子値を割り当て、場合によっては他の割り当てを行う必要があります。このようなMIBモジュールを含むインターネットドラフトには、更新されるレジストリ、オブジェクト識別子値が割り当てられている記述子、および値が割り当てられるサブトリーを指定するIANA考慮事項セクションを含める必要があります。テキストは、公開後にオブジェクト識別子の割り当てを文書化するのに役立つように作成する必要があります。たとえば、「MIB-2」サブツリーの下に値を割り当てられるモジュールアイデンティティ記述子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エディターは「xxx」（ここおよびMIBモジュール内）を割り当てられた値に置き換え、このメモを削除するように求められます。
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の側でのアクションは必要ありませんが、以前のバージョンの既存の割り当てを文書化するIANAの考慮事項セクションを継承する場合があります。MIBモジュール。そのような場合、ドラフトには、IANAから何も必要ないことを明示的に示すメモ（公開前に削除される）を含める必要があります。たとえば、Power-Ethernet-Mib [RFC3621]の更新バージョンを含むドラフトには、次のようなIANAの考慮事項セクションが含まれる場合があります。
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モジュールの項目が定義セクションのインポートステートメントに表示される場合、それらの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ドキュメントには、RFC 3978 [RFC3978]のセクション5.4および5.5に指定された著作権通知と免責事項を含める必要があります。著者とレビュアーは、これらの通知に正しい年が挿入されることを確認するためにチェックする必要があります。さらに、公開されているRFCに表示される各MIBモジュールのモジュール同一性呼び出しの説明条項には、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 ed。：yyyyを実際のRFC番号に置き換えて、このメモを削除します
A template suitable for MIB modules that are to be maintained by the IANA is as follows:
IANAによって維持されるMIBモジュールに適したテンプレートは次のとおりです。
DESCRIPTION " [ ... ]
説明 " [ ... ]
Copyright (C) The Internet Society (date). The initial version of this MIB module was published in RFC yyyy; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." -- RFC Ed.: replace yyyy with actual RFC number & remove this note In each case, the current year is to be inserted in place of the word "date".
著作権（c）インターネット協会（日付）。このMIBモジュールの初期バージョンは、RFC Yyyyで公開されました。完全な法的通知については、RFC自体をご覧ください。補足情報は、http：//www.ietf.org/copyrights/ianamib.html。 " - RFC ed。：yyyyを実際のRFC番号に置き換えて、それぞれのケースでこのメモを削除することができます。「日付」という単語の代わりに挿入されます。
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 [RFC3979]のセクション5には、すべての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モジュールは、「標準」MIBモジュールに適用されるSMIV2 [RFC2579] [RFC2579] [RFC2580]のSMIV2 [RFC2579] [RFC2580]のすべての構文およびセマンティック要件に準拠する必要があります。このセクションのガイドラインは、次の方法でSMIV2ドキュメントを補足することを目的としています。
o to document the current generally accepted interpretation when those documents contain ambiguities or contradictions;
o これらの文書に曖昧さまたは矛盾が含まれている場合、一般に受け入れられている解釈を文書化する。
o to update recommendations in those documents that have been shown by practical experience to be out-of-date or otherwise suboptimal;
o 実際の経験によって時代遅れであるか、そうでなければ最適ではないことが示されているドキュメントの推奨事項を更新する。
o to provide guidance in selection of SMIv2 options in cases where there is a consensus on a preferred approach.
o 優先アプローチにコンセンサスがある場合に、SMIV2オプションの選択に関するガイダンスを提供する。
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は、列挙された整数とビット値に関連するマクロの呼び出しとラベルに関連する記述子と名前が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.
記述子、TC名、および32文字へのラベルを制限することは、多くの場合、それらがニーモニックであり（記述子とTC名の場合）、それらが一意であるという要件との推奨と競合することがよくあります（RFC 2578セクション3.1およびRFC 2579セクション3を参照）。MIBレビュアーの現在のプールのコンセンサスは、記述子、TC名、およびラベルを32文字に制限する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によって維持されているオブジェクト識別子サブツリーを説明し、それらのサブツリーの使用法を指定します。特に、MGMTサブツリー{ISO 3 6 1 2}はIETF「標準」オブジェクトを識別するために使用され、実験サブツリー{ISO 3 6 1 3}を使用して、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.
この一般的な要件の免除は、モジュールコンプライアンスステートメントのオブジェクト節またはエージェントキャピリティステートメントのバリエーション節に表示されるオブジェクトの記述子に対して、RFC 2580セクション5.4.3および6.5.2によって認められることに注意してください。また、一部のMIBコンパイラは、バリエーション条項に表示される通知の記述子およびオブジェクトグループの記述子および必須グループ条項、グループ条項、または含まれる条項で参照される通知グループの記述子に免除を認めますが、RFC 2580（見かけの監視を介して）これらの場合は言及していません。免除は、輸入ルールをより複雑にし、モジュール間の依存関係を他の方法よりも明白ではないため、役に立たないと見なされることがあります。したがって、コンプライアンスステートメントと機能ステートメントによって参照される外部シンボルは、インポートステートメントにリストされる場合があります。これが行われた場合、一貫して行う必要があります。
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モジュールがモジュール同一マクロの1つの呼び出しから始まることを要求しています。この呼び出しは、インポートステートメントの直後に表示されなければなりません。
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ワーキンググループによって開発された場合、組織条項はワーキンググループのフルネームを提供する必要があり、連絡先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時間は、最後のアップデート条項のそれと一致する必要があります。各改訂に関連付けられた説明条項は、改訂が登場したRFCがすべての重要な変更のリストを提供する必要があると述べなければなりません。MIBモジュールが改訂されると、すべてのリビジョン条項の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.
- モジュールアイデンティティ記述子に割り当てられた値は一意でなければならず、（IETF標準トラックMIBモジュールの場合）MGMTサブツリー[RFC2578]の下に存在する必要があります。ほとんどの場合、それはMIB-2 [RFC2578]の下で直接IANAによって割り当てられた値になりますが、IF-MIB [RFC2863]を拡張するメディア固有のMIBモジュールの場合[RFC2578]の下でIANAが割り当てられた値を使用することが慣習です[RFC2578]。過去には、一部の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 "200212132358Z" -- December 13, 2002 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note
リビジョン「200212132358Z」 - 2002年12月13日説明「RFC Yyyyとして公開された初期バージョン」-RFC ed。：yyyyを実際のRFC番号に交換し、このメモを削除します
Note that after RFC publication, a REVISION clause is present only for published versions of a MIB module and not for interim versions that existed only as Internet-Drafts. Thus, a draft version of a MIB module MUST contain just one new REVISION clause that covers all changes since the last published version (if any).
RFCの公開後、改訂節は、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モジュールの初期バージョンが開発中の場合、RFCとして公開される直前に割り当てが行われるため、モジュール同一性記述子に割り当てられた値が使用されているかどうかは不明になります。このようなモジュールのドラフトバージョンのモジュールアイデンティティステートメントの受け入れフォームは、次の行に沿ったものです。
<descriptor> MODULE-IDENTITY
<decriptor>モジュール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.
ここで、<decriptor>はモジュール用に選択された記述子であり、<subtree>はモジュールを登録するサブツリー（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ビット整数データ型整数、integer32、ゲージ32、および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.
- 整数が必要です。-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].
RFC 2578は、整数値の列挙が1から始まり、連続的に番号が付けられることを推奨している（ただし必要ない）ことに注意してください。この推奨事項は、例えば、外部データの値を一致させるか、特別なケースを示すために、特別なケースを示すための正当な理由がない限り、従うべきです。たとえば、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.
- integer32をお勧めします。 - 整数は受け入れられます。-unsigned32およびGauge32を使用しないでください。
- If the value range is between 0..4294967295 (inclusive) and the value of the information being modelled may increase above the maximum value or decrease below the minimum value, then:
- 値範囲が0..4294967295（包括的）の間で、モデル化されている情報の値が最大値を超えるか、最小値を下回る場合に増加する可能性があります。
- Gauge32 is RECOMMENDED; - Unsigned32 is acceptable; - INTEGER and Integer32 MUST NOT be used if values greater than 2147483647 are possible.
- Gauge32をお勧めします。-unsigned32は許容されます。-integerおよびinteger32は、2147483647を超える値が可能な場合は使用しないでください。
- If the value range is between 0..4294967295 (inclusive), and values greater than 2147483647 are possible, and the value of the information being modelled does not increase above the maximum value nor decrease below the minimum value, then:
- 値範囲が0..4294967295（包括的）の間で、2147483647を超える値が可能であり、モデル化されている情報の値が最大値を超えたり、最小値を下回ったりすることはありません。
- Unsigned32 is RECOMMENDED; - Gauge32 is acceptable; - INTEGER and Integer32 MUST NOT be used.
- unsigned32をお勧めします。-Gauge32は許容されます。-integerおよびinteger32を使用してはなりません。
- If the value range is between 0..2147483647 (inclusive), and the value of the information being modelled does not increase above the maximum value nor decrease below the minimum value, then:
- 値の範囲が0..2147483647（包括的）の間で、モデル化されている情報の値が最大値を超えたり、最小値を下回ったりしない場合、次のとおりです。
- Unsigned32 is RECOMMENDED; - INTEGER, Integer32, and Gauge32 are acceptable.
- unsigned32をお勧めします。-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:
- インデックス句に表示される整数オブジェクトまたはインデックス列で使用される整数値TCSの場合：
- Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause.
- ゼロを除外する範囲のunsigned32は、ほとんどのインデックスオブジェクトに推奨されます。それが意味的に有意である場合、または特別な特性を持つ一意の行のインデックス値として使用される場合、範囲にゼロを含めることは許容されます。このような使用法は、説明条項に明確に文書化する必要があります。
- 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のインデックスルールの両方を、28ページの弾丸（1）に加えて最後から最後まで次の段落を含む両方を組み合わせています。
Sometimes it will be necessary for external variables to represent values of an index object -- e.g., ifIndex [RFC2863]. In such cases, authors of the module containing that object SHOULD consider defining TCs such as InterfaceIndex and/or InterfaceIndexOrZero [RFC2863].
時には、外部変数がインデックスオブジェクトの値（例えば、ifindex [RFC2863]）を表す必要がある場合があります。そのような場合、そのオブジェクトを含むモジュールの著者は、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.
整数は事前に定義されたASN.1タイプであり、モジュールのインポートステートメントに存在しないでください。一方、integer32、gauge32、およびunsigned32は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:
Counter32とCounter64には、それぞれRFC 2578セクション7.1.6および7.1.10で説明されているように特別なセマンティクスがあります。オブジェクトの定義は、これらのセマンティクスを尊重する必要があります（およびテキストの慣習が必要です）。つまり、
- 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を使用しても構いません（例：ラインカードに維持されているカウンターは、ラインカードがリセットされたときにリセットされる場合があります）。ただし、そのような他の異常な/不規則なイベントが発生する可能性がある場合、説明条項は、これがそうであると述べ、他の異常な/不規則なイベントを十分に詳細に説明する必要があります。カウンターが最後に投票されたときから発生しました。これを行うための推奨される方法は、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.
- カウンター32/64の説明条項を掲載しても、カウンターがゼロまたは他の特定の値にリセットする必要があるという要件があるということは問題ありません。
- 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).
- 特定の時間/イベント（真夜中など）でリセットする必要があるという要件があるというカウンター32/64の説明条項を掲載しても問題ありません。
- It is NOT OK for one manager to request the agent to reset the value(s) of counter(s) to zero, and Counter32/64 is the wrong syntax for "counters" that regularly reset themselves to zero. For the latter, it is better to define or use textual conventions such as those in RFC 3593 [RFC3593] or RFC 3705 [RFC3705].
- 1人のマネージャーがエージェントにカウンターの値をゼロにリセットするように要求することは問題ありません。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 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.
RFC 2578セクション7.1.10「標準」MIBモジュールの要件を、モデル化されている情報が代わりに使用された場合にモデル化されている情報が1時間以内にラップされる場合にのみ使用できるという要件を配置します。Snmpv3はインターネット標準であり、Snmpv1は歴史的です（ステータスについてはhttp://www.rfc-editor.org/rfcxx00.htmlを参照し、[RFC3410]を根拠のために[RFC3410]を参照）、この制限を執行し続ける理由はありません。以降、「標準」MIBモジュールは、それが理にかなっているときにCounter64タイプを使用する場合があり、モデル化されている情報が代わりに使用された場合は1時間以内に包装する場合はCounter64を使用する必要があります。また、各counter64オブジェクトのカウンター32のカウンターパートを定義するための要件はもうないことに注意してください。ただし、1つは許可されています。
There also exist closely-related textual conventions ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB [RFC2021] and HCNUM-TC [RFC2856], respectively.
また、RMON2-MIB [RFC2021]およびHCNUM-TC [RFC2856]で定義されている密接に関連するテキストコンベンションZerobasedCounter32およびZerobasedCounter64も存在します。
The only difference between ZeroBasedCounter32/64 TCs and Counter32/64 is their starting value; at time=X, where X is their minimum-wrap-time after they were created, the behavior of ZeroBasedCounter32/64 becomes exactly the same as Counter32/64. Thus, the preceding paragraphs/rules apply not only to Counter32/64, but also to ZeroBasedCounter32/64 TCs.
ZerobasedCounter32/64 TCSとCounter32/64の唯一の違いは、開始値です。時刻= xでは、xは作成後の最小-rap-timeであるため、ZerobasedCounter32/64の動作はCounter32/64とまったく同じになります。したがって、前の段落/ルールは、Counter32/64だけでなく、ZerobasedCounter32/64 TCSにも適用されます。
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ビットの整数ベースタイプを提供しません。この省略を補うために、CounterbasedGage64テキスト条約はHCNUM-TC [RFC2856]で定義されています。このTCは、Counter64をベースタイプとして使用しますが、RFC 2579セクション3.3の一般的に受け入れられている解釈の下で許可されている特別なカウンターセマンティクスを破棄します。それはそのタイプのすべての構文制限を継承します。つまり、それはサブタイプではなく、それで定義されたオブジェクトがインデックス条項に表示されてはならず、defval句を持っている必要はなく、読み取りの最大アクセスが必要です - notifyのみまたはアクセスしやすい。
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が別のTCを改良できないため、Counter64に基づく別のTCを使用する必要があります（RFC 2579セクション3.5を参照）。
The OCTET STRING type is described in RFC 2578 Section 7.1.2. It represents arbitrary binary or textual data whose length is between 0 and 65535 octets inclusive. Objects and TCs whose SYNTAX is of this type SHOULD have a size constraint when the actual bounds are more restrictive than the SMI-imposed limits. This is particularly true for index objects. Note, however, that size constraints SHOULD NOT be imposed arbitrarily, as the SMI does not permit them to be changed afterward.
Octet文字列タイプは、RFC 2578セクション7.1.2で説明されています。これは、長さが0〜65535オクテットを含む任意のバイナリまたはテキストデータを表します。このタイプの構文があるオブジェクトとTCは、実際の境界がSMIが課した制限よりも制限的である場合、サイズの制約を持つ必要があります。これは、インデックスオブジェクトに特に当てはまります。ただし、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.
専門化されたオクテット弦タイプのより一般的な要件のいくつかに対応する多くの標準TCが存在します。特に、SNMPV2-TC [RFC2579]には、DisplayString、PhysAddress、MacAddress、およびDateandtime TCSが含まれています。snmp-framework-mib [rfc3411]には、snmpadminstring tcが含まれています。SYSAPPL-MIB [RFC2287]には、UTF8STRINGおよびLONGUTF8STRING TCSが含まれています。標準のTCが目的のセマンティクスを提供する場合、Octet Stringまたは同等のローカル定義TCの代わりに、オブジェクトの構文節で使用する必要があります。
Note that OCTET STRING is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
Octet Stringは事前定義されたASN.1タイプであり、モジュールのインポートステートメントに存在しないでください。
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.
オブジェクト識別子値の目的は、何らかのタイプのアイテムまたは何らかのタイプのアイテムの特定のインスタンスのいずれかに対して権威ある識別を提供することです。この方法で識別できる項目の中には、モジュール同一性、オブジェクトアイデンティティ、オブジェクトタイプ、通知型、オブジェクトグループ、通知グループ、モジュールコンプライアンス、およびエージェントキャピリティを介して作成された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]には、自律型、可変ポインター、およびRowpointer TCSが含まれています。標準のTCが目的のセマンティクスを提供する場合、オブジェクト識別子または同等のローカル定義TCの代わりに、オブジェクトの構文節で使用する必要があります。
Note that OBJECT IDENTIFIER is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
オブジェクト識別子は事前定義されたASN.1タイプであり、モジュールのインポートステートメントに存在しないでください。
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で説明されています。名前付きビットの列挙を表します。このタイプの構文が0から始まり、隣接する必要があるTCまたはオブジェクト定義のビット位置。
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コンストラクトは、それを使用するマクロによって定義されているため、モジュールのインポートステートメントに存在してはなりません。
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で説明されているiPaddressタイプは、新しい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秒での時間を表し、Modulo 2^32を減らします。サブタイプしてはなりません。また、このタイプの構文があるオブジェクトまたは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]で定義されています。これは列挙された整数型で、値はtrue（1）とfalse（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は、ブール型タイプを必要とするオブジェクト定義の構文節で使用する必要があります。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]で定義されているTCSに特に当てはまります。そのような参照。
MIB module authors need to be aware that enumerated INTEGER or BITS TCs may in some cases be extended with additional enumerated values or additional bit positions. When an imported TC that may be extended in this way is used to define an object that may be written or that serves as an index in a read-create table, then the set of values or bit positions that needs to be supported SHOULD be specified either in the object's DESCRIPTION clause or in an OBJECT clause in the MIB module's compliance statement(s). This may be done by explicitly listing the required values or bit positions, or it may be done by stating that an implementation may support a subset of values or bit positions of its choosing.
MIBモジュールの著者は、列挙された整数またはビットTCが追加の列挙値または追加のビット位置で拡張される場合があることに注意する必要があります。この方法で拡張される可能性のあるインポートされたTCを使用して、書かれているオブジェクト、または読み取りテーブルのインデックスとして機能するオブジェクトを定義する場合、サポートする必要がある値またはビット位置のセットを指定する必要があります。オブジェクトの説明条項またはMIBモジュールのコンプライアンスステートメントのオブジェクト条項のいずれか。これは、必要な値またはビットの位置を明示的にリストすることで行うことができます。または、実装が選択の値またはビット位置のサブセットをサポートする可能性があることを示すことによって行われる場合があります。
It is hard to overemphasize the importance of an accurate and unambiguous DESCRIPTION clause for all objects and TCs. The DESCRIPTION clause contains the instructions that implementors will use to implement an object, and if they are inadequate or ambiguous, then implementation quality will suffer. Probably the single most important job of a MIB reviewer is to ensure that DESCRIPTION clauses are sufficiently clear and unambiguous to allow interoperable implementations to be created.
すべてのオブジェクトとTCSの正確で明確な説明条項の重要性を強調することは困難です。説明条項には、実装者がオブジェクトを実装するために使用する指示が含まれており、それらが不十分または曖昧な場合、実装の品質が損なわれます。おそらく、MIBレビュアーの最も重要な仕事は、説明条項が相互運用可能な実装を作成できるように十分に明確で明確であることを確認することです。
A very common problem is to see an object definition for, say, 'stdMIBPoofpoofCounter' with a DESCRIPTION clause that just says "Number of poofpoofs" with no indication what a 'poofpoof' is. In such cases, it is strongly RECOMMENDED that there either be at least a minimal explanation or else a REFERENCE clause to point to the definition of a 'poofpoof'.
非常に一般的な問題は、「poofpoofs」とは何かを示す「poofpoofsの数」と書かれた説明条項を備えた「stdmibpoofpoofcounter」のオブジェクト定義を見ることです。そのような場合、少なくとも最小限の説明があるか、「poofpoof」の定義を指す参照条項があることを強くお勧めします。
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.
ディスプレイヒント句は、TCでは、TCの構文で定義されたオブジェクトのインスタンスの値が表示される方法について、管理アプリケーションに結合のヒントを提供するためにTCで使用されます。その存在はオプションです。
Although management applications typically default to decimal format ("d") for integer TCs that are not enumerations and to a hexadecimal format ("1x:" or "1x " or "1x_") for octet string TCs when the DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not actually specify any defaults. MIB authors should be aware that a clear hint is provided to applications only when the DISPLAY-HINT clause is present.
管理アプリケーションは通常、列挙されていない整数TCSの小数形式（ "d"）と、ディスプレイヒント句が表示される場合のオクテット文字列TCSの16進形式（ "1x：" "または" 1x "または" 1x_ "）にデフォルトですが不在は、SMIV2が実際にデフォルトを指定していないことに注意する必要があります。MIBの著者は、表示ヒント節が存在する場合にのみ、アプリケーションに明確なヒントが提供されることに注意する必要があります。
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.
- 行が他のテーブルの行の延長である場合、関係が1対1である場合はAugments句を使用する必要があり、関係がまばらな場合はインデックス条項を使用する必要があります。後者の場合、インデックス句は元のテーブルの節と同一である必要があります。
- 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.
- 行の外部オブジェクトがインデックス条項に存在する場合、概念行の説明句は、柱状オブジェクトのインスタンスを識別する際にそれらのオブジェクトがどのように使用されるかを指定する必要があり、特にそれらのインデックスオブジェクトの値が概念行のどの値を指定する必要があります。存在。
- 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.
- 拡張テーブルのインデックス節に表示される可能性のあるインデックスオブジェクトには、暗黙のキーワードの使用は推奨されません。このキーワードは、インデックス句の最後のオブジェクトにのみ関連付けられる可能性があるため、プライマリテーブルの同じインデックスオブジェクトと拡張テーブルに関連付けることはできません。これにより、プライマリテーブルと拡張テーブルでソート順序が異なります。結果として、実装により、拡張テーブルのプライマリテーブルからインデックス作成コードを再入力できなくなり、拡張することを意図したデータ構造を実際に複製する必要がある場合があります。Impliedを使用するように誘惑されているデザイナーは、結果として生じるソートオーダーは、特に大文字と小文字の両方を含む文字列について、ユーザーの期待を満たすことはめったになく、ユーザー言語やロケールを考慮しないことを考慮する必要があります。
- If dynamic row creation and/or deletion by management applications is supported, then:
- 管理アプリケーションによる動的な行の作成および/または削除がサポートされている場合、次のとおりです。
- There SHOULD be one columnar object with a SYNTAX value of RowStatus [RFC2579] and a MAX-ACCESS value of read-create. This object is called the status column for the conceptual row. All other columnar objects MUST have a MAX-ACCESS value of read-create, read-only, accessible-for-notify, or not-accessible; a MAX-ACCESS value of read-write is not allowed.
- RowStatus [RFC2579]の構文値を備えた1つの柱状オブジェクトと、読み取りの最大アクセス値が必要です。このオブジェクトは、概念行のステータス列と呼ばれます。他のすべての柱状オブジェクトには、読み取りのみ、読み取り専用、アクセス可能、またはアクセス不可の最大アクセス値が必要です。読み取りワイトの最大アクセス値は許可されていません。
- 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]とRead-Createの最大アクセス値を持つ1つの柱状オブジェクトが必要です。または、Agent Objectの最大値（テーブルエントリ）説明条項は、エージェントの後に動的に作成された行に何が起こるかを指定する必要があります。再起動。
- 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.
- ステータス列の説明条項は、行を有効にする前に有効な値に設定する必要がある列オブジェクトを指定する必要があります。Cascadingテーブルのオブジェクトに、行をアクティブにする前に関連データを入力する必要がある場合は、これも指定する必要があります。
- 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では、ベース行を補強する概念行のインスタンスの寿命が、ベース行の対応するインスタンスと同じでなければならないことに注意してください。そのため、基本行に既に存在している場合、拡張行に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の完全な要件は、これらのTCSの説明条項に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.
- 概念テーブルには、概念的行である1つの下位オブジェクトが必要です。概念の行に割り当てられたOIDは、概念テーブルに割り当てられたOIDに「1」のサブIDENTIFIERを追加することにより導出する必要があります。
- A conceptual row has as many subordinate objects as there are columns in the row; there MUST be at least one. The OID assigned to each columnar object MUST be derived by appending a non-zero sub-identifier, unique within the row, to the OID assigned to the conceptual row.
- 概念的行には、行に列があるのと同じくらい多くの下位オブジェクトがあります。少なくとも1つある必要があります。各柱状オブジェクトに割り当てられたOIDは、概念の行に割り当てられたOIDに、行内で一意の非ゼロサブインテッドIDを追加することにより導出する必要があります。
- 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の連結で構成されているためです。テーブルに、複数のサブ識別子に解決するOctet文字列またはオブジェクト識別子などのタイプの複数のインデックスがある場合、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.
- アクセスできないオブジェクトは、Objects句に表示されてはなりません。
- For each object type mentioned in the OBJECTS clause, the DESCRIPTION clause MUST specify which object instance is to be present in the transmitted notification and MUST specify the information/meaning conveyed.
- Objects句に記載されている各オブジェクトタイプについて、説明条項は、送信された通知に存在するオブジェクトインスタンスを指定し、伝達される情報/意味を指定する必要があります。
- The OBJECT IDENTIFIER (OID) value assigned to each notification type MUST have a next-to-last sub-identifier of zero, so that it is possible to convert an SMIv2 notification definition into an SMIv1 trap definition and back again without information loss (see [RFC3584] Section 2.1.2) and possible for a multilingual proxy chain to translate an SNMPv2 trap into an SNMPv1 trap and back again without information loss (see [RFC3584] Section 3). In 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）値は、ゼロの次の次のサブ識別子を持つ必要があります。そのため、SMIV2通知定義をSMIV1トラップ定義に変換し、情報の損失なしに再び戻ることができます（[RFC3584]セクション2.1.2）および多言語プロキシチェーンがSNMPV2トラップをSNMPV1トラップに変換し、情報の損失なしに再び戻す可能性があります（[RFC3584]セクション3を参照）。さらに、通知定義に割り当てられた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がリーフOIDSであることも慣習的です（そして強く推奨されます）（つまり、通知定義に従属する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の任意の時間間隔で各イベントソースに1つの通知を生成する必要があります。ケース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.
- 「アクセスできない」以外の最大アクセス値を持つすべてのオブジェクトは、少なくとも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.
- 必須グループ条項またはモジュールコンプライアンスステートメントの任意のグループ条項で言及されていないオブジェクトグループまたは通知グループは、そのコンプライアンスステートメントに関して無条件にオプションです。オブジェクトグループまたは通知グループがオプションであることを示す別の方法は、説明条項がグループがオプションであると述べているグループ条項で言及することです。後者の方法は、オプションのステータスが省略行為の結果ではなく意図されていることを明確にするために、（コンプライアンスステートメントに関連するオプションのグループの場合）推奨されます。
- 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.
- read-writeまたはread-createの最大アクセス値を持つオブジェクトがある場合、読み取り専用の最小アクセスを指定するオブジェクト条項がない場合、実装はそれらのオブジェクトへの書き込みアクセスをサポートする必要があります。そのモジュールコンプライアンスステートメントに準拠しています。この事実は、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モジュールの著者は、準拠した実装では、オブジェクトの構文節で許可されている値のサブセットのみをサポートする必要があることを指定する場合があります。アクセス可能なオブジェクトの場合、これは、オブジェクトの説明条項で必要な値を指定するか、コンプライアンスステートメントに洗練された構文をオブジェクト句に提供することにより、実行できます。後者の方法は、ほとんどの場合に推奨され、異なる値サブセットが必要な複数のコンプライアンスステートメントがある場合は必要です。diffserv-mib [rfc3289]はこの点を示しています。diffservmibfullcomplianceステートメントには、次のオブジェクト句が含まれています。（セクション4.8.1、「これらの例とRFC 2578に関する注意」を参照してください。）
OBJECT diffServDataPathStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
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."
オブジェクトdiffservdatapathstatus構文rowStatus {active（1）} min-access read-only説明「書き込みアクセスは不要であり、アクティブはサポートする必要がある唯一のステータスです。」
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).
オブジェクトグループに存在することができず、オブジェクト節で言及できないため、アクセスできないインデックスオブジェクトに対してこれを行うことはできません。ただし、読み取りテーブルの何らかのインデックスの可能な値のサブセットのみをサポートするために実装が必要であることを示すことを望む状況があります。そのような場合、要件は、インデックスオブジェクトの説明句（値サブセットが1つだけある場合は推奨）またはモジュールコンプライアンスステートメントの説明条項（値サブセットがコンプライアンスステートメントに固有の場合に必須）のいずれかで指定する必要があります。。
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.ただし、MIBモジュールAがモジュールBのコンプライアンスステートメントで表されるものとは異なる要件を持つ可能性もあります。たとえば、モジュールAは、無条件に必須のオブジェクトグループを必要としない場合があります。モジュールBですが、モジュールBのコンプライアンスステートメントに関して条件付きでのみ必須のオブジェクトグループの必須実装が必要になる場合があります。そのような場合、推奨されるアプローチはモジュールAのコンプライアンスステートメント（適切なモジュール、必須グループ、グループ、およびオブジェクト条項を介して、モジュールBに関する要件を正式に指定します。例は、diffserv-mib [rfc3289]のコンプライアンスステートメントによって提供されています。これは、if-mib [rfc2863]のifcounterdiscontinuitygroupを必須グループとしてリストしています。そのグループは、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 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セクション9）がTCSで許可されているのか、それとも基本タイプの整数とビットでのみ許可されているかどうかについて、いくつかの論争がありました。RFC 2578. SMIV2ドキュメントの編集者とMIBレビュアーの現在のプールの大まかなコンセンサスは、TCSで許可されるべきであるということです。MIBモジュールの著者は、一部のMIBコンパイラがRFC 2578の厳格な読みに従い、列挙が改良されているときにTCをそのベースタイプ（整数またはビット）に置き換えることを要求することに注意する必要があります。その使用法は合法であり、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.
- 改訂に関する情報を含めるために、モジュール同一性の呼び出しを更新する必要があります。特に、最終更新句の値は、改訂時間、同じUTC時間の改訂節、および変更を説明する関連する説明条項を追加する必要があり、既存の説明、組織、および連絡先の時代遅れの情報を設定する必要があります。-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モジュールが、モジュールの以前のバージョンに基づいてフィールドされた実装と互換性があることを確認することであることに注意することが重要です。この後方互換性の要件には、2つの異なる側面があります。1つは、MIBモジュールのさまざまな改訂に基づいたエージェントとマネージャーの実装の「Over the Wire」の互換性です。もう1つは、改訂された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.
- Bullet（1）は、列挙された整数またはビットのタイプの構文条項の名前付き番号と名前付きビットのラベルを変更することを許可します。これらのラベルは、影響を受けるオブジェクトの定義をインポートするモジュールの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）では特に許可されていませんが、整数値のオブジェクトの構文節に範囲の制約を追加することは一般に許容されると考えられています。オブジェクトの。最も一般的な例は、範囲の制約がない整数または整数の構文を備えた補助オブジェクトです。補助オブジェクトは負の値を想定することは許可されていないため、範囲の制約（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.
- Bullet（1）は、列挙された整数またはビットのタイプの構文条項の名前付き番号と名前付きビットのラベルを変更することを許可します。これらのラベルは、影響を受けるTCSの定義をインポートするモジュールの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は、適合グループの改訂に適用されるルールを指定します。2つのポイントは繰り返す価値があります：
- 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コンプライアンスステートメントの改訂に適用されるルールを指定します。次のガイドラインは、これらのルールからの省略を修正し、1つの重要なポイントを強調します。
- RFC 2580 should (but does not) recommend that an OBJECT clause specifying support for the original set of values be added to a compliance statement when an enumerated INTEGER object or a BITS object referenced by the compliance statement has enumerations or named bits added, assuming that no such clause is already present and that the effective MIN-ACCESS value is read-write or read-create. This is necessary in order to avoid a silent change to the meaning of the compliance statement. MIB module authors and reviewers SHOULD watch for this to ensure that such OBJECT clauses are added when needed. Note that this may not always be possible to do, since affected compliance statements may reside in modules other than the one that contains the revised definition(s).
- RFC 2580は、列挙された整数オブジェクトまたはコンプライアンスステートメントによって参照されている列挙オブジェクトが列挙または名前付きビットが追加された場合、元の値のサポートを指定するオブジェクト句をコンプライアンスステートメントに追加することを推奨する必要があります（ただし）推奨する必要はありません（ただし）推奨する必要はありません。そのような条項は既に存在しておらず、効果的な最小アクセス値は読み取りされているか、読み取りされていることです。これは、コンプライアンスステートメントの意味への無言の変更を避けるために必要です。MIBモジュールの著者とレビュアーは、必要に応じてそのようなオブジェクト条項が追加されるように、これを監視する必要があります。影響を受けるコンプライアンスステートメントは、改訂された定義を含むモジュール以外のモジュールに存在する可能性があるため、これが常にできるとは限らないことに注意してください。
- 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は、元の値のセットのサポートを指定するバリエーション句を、機能ステートメントによって参照されている整数オブジェクトまたはビットオブジェクトが列挙されている場合、そのような条項が既に存在しないと仮定して列挙されている場合、バリエーション句を推奨する必要はありません（ただし）推奨する必要はありません。。これは、機能ステートメントの意味への無言の変更を避けるために必要です。
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規則に厳密に続くコストは、利益を上回る可能性があります。そのような場合、規則を放棄することができますが、それが行われた場合、変更とその正当化の両方を徹底的に文書化する必要があります。1つの例は、RFC 2863のセクション3.1.5で提供されています。これは、MIB-II [RFC1213]からIF-MIB [RFC2863]への移行でIFINDEXに行われたセマンティック変更を文書化し、その変更の詳細な正当化を提供します。別の例は、SONET-MIB [RFC2558]の修正条項で提供されています。これは、以前のバージョンとの互換性のために読み取り専用の最小アクセスを追加しながら、いくつかのオブジェクトの最大アクセスを読み取りろうそくに追加する文書を記録しています[RFC1595]。
Authors and reviewers may find it helpful to use tools that can list the differences between two revisions of a MIB module. Please see http://www.ops.ietf.org/mib-review-tools.html for more information.
著者とレビュアーは、MIBモジュールの2つのリビジョン間の違いをリストできるツールを使用することが役立つ場合があります。詳細については、http：//www.ops.ietf.org/mib-review-tools.htmlをご覧ください。
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.
データ型の使用に関する資料のほとんどは、Keith McCloghrie、David T. Perkins、およびJuergen Schoenwaelderの支援を受けて、Bert Wijnenが提供する入力に基づいていました。SMIV2の使用に関する他の資料の多くは、Juergen SchoenwaelderによるMIBの著者とレビュアー向けの未発表のガイドから取得されました。これらのガイドラインの推奨事項のいくつかは、http：//www.ibr.cs.tu-bs.de/ietf/smi-errata/のオンラインSMIV2 Errataリストから描かれた資料に基づいています。そのリストを維持してくれたフランク・シュトラウスとジュエルゲン・シェーンワエルダーと、そのリストに資料を提供した貢献者に感謝します。最後に、このメモの以前のバージョンに関するコメントが、追加、説明、修正に関する多くの貴重な提案が含まれていた以下の個人に感謝します。キース・マクログリー、デビッド・T・パーキンス、ランディ・プレスフーン、ダン・ロマスカヌ、ジュエルゲン・シェーンワエルダー、フランク・シュトラウス、デイブ・サラー、バート・ウィジネン。
Implementation and deployment of a MIB module in a system may result in security risks that would not otherwise exist. It is important for authors and reviewers of documents that define MIB modules to ensure that those documents fully comply with the guidelines in http://www.ops.ietf.org/mib-security.html so that all such risks are adequately disclosed.
システム内のMIBモジュールの実装と展開により、他の方法では存在しないセキュリティリスクが発生する可能性があります。MIBモジュールを定義するドキュメントの著者やレビュアーにとって、これらの文書がhttp://www.ops.ietf.org/mib-security.htmlのガイドラインを完全に遵守していることを確認して、そのようなリスクがすべて適切に開示されるようにすることが重要です。
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レビューの目的は、MIBモジュールの技術的正しさとIETFドキュメント要件の順守の両方についてレビューすることです。ドラフトドキュメントを確認する際には、次のチェックリストが役立つ場合があります。
1.) I-D Boilerplate -- verify that the draft contains the required Internet-Draft boilerplate (see http://www.ietf.org/ietf/1id-guidelines.txt), including the appropriate statement to permit publication as an RFC, and that I-D boilerplate does not contain references or section numbers.
1.）I-Dボイラープレート - ドラフトに必要なインターネットドラフトボイラープレートが含まれていることを確認します（http://www.ietf.org/ietf/1Id-guidelines.txtを参照）。また、I-Dボイラープレートには参照またはセクション番号が含まれていません。
2.) Abstract -- verify that the abstract does not contain references, that it does not have a section number, and that its content follows the guidelines in http://www.ietf.org/ietf/1id-guidelines.txt.
2.）要約 - 要約には参照が含まれておらず、セクション番号がないこと、およびそのコンテンツがhttp://www.ietf.org/ietf/1id-guidelines.txtのガイドラインに従うことを確認します。
3.) MIB Boilerplate -- verify that the draft contains the latest approved SNMP Network Management Framework boilerplate from the OPS area web site (http://www.ops.ietf.org/mib-boilerplate.html).
3.）MIBボイラープレート - ドラフトに、OPSエリアWebサイト（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.）セキュリティ上の考慮事項セクション - ドラフトが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値を割り当てる必要がある場合は、これらのガイドラインのセクション3.5で指定された情報が含まれていることを確認してください。ドラフトにIANAが維持したモジュールの初期バージョンが含まれている場合、モジュール同一性の呼び出しにRFC 2434の要件に準拠するメンテナンス指示が含まれていることを確認します。実際のIANAが維持したモジュールへのポインター。
6.) References -- verify that the references are properly divided between normative and informative references, that RFC 2119 is included as a normative reference if the terminology defined therein is used in the document, that all references required by the boilerplate are present, that all MIB modules containing imported items are cited as normative references, and that all citations point to the most current RFCs unless there is a valid reason to do otherwise (for example, it is OK to include an informative reference to a previous version of a specification to help explain a feature included for backward compatibility).
6.）参照 - 参照が規範的参照と有益な参照の間に適切に分割されていることを確認します。RFC2119は、文書で定義されている用語が使用されている場合、規範的参照として含まれていることを確認します。インポートされたアイテムを含むすべてのMIBモジュールは、規範的参照として引用されており、すべての引用は、特に正当な理由がない限り、最新のRFCを指しています（たとえば、以前のバージョンの仕様の有益な参照を含めても構いません。後方互換性のための機能を説明するのに役立ちます）。
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.）著作権通知 - ドラフトには、各モジュール同意の呼び出しの説明条項に短縮された著作権通知が含まれていることを確認し、RFC 3978のセクション5.4および5.5で指定された完全な著作権通知と免責事項が含まれていることを確認します。書類。すべての著作権日に正しい年が使用されていることを確認してください。
8.) IPR Notice -- if the draft does not contains a verbatim copy of the IPR notice specified in Section 5 of RFC 3979, recommend that the IPR notice be included.
8.）IPR通知 - ドラフトに、RFC 3979のセクション5で指定されているIPR通知の逐語的なコピーが含まれていない場合、IPR通知を含めることをお勧めします。
9.) Other Issues -- check for any issues mentioned in http://www.ietf.org/ID-Checklist.html that are not covered elsewhere.
9.）その他の問題 - 他の場所ではカバーされていない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))
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.ディスプレイストリングは、国際化されたテキストをサポートしていません。国際化されたテキストを保持するために必要なオブジェクトに使用してはなりません（オブジェクトが人間[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モジュールでは使用しないでください。代わりに、TransportDomain、TransportAddressType、およびTransportAddress TCS（Transport-Address-Mib [RFC3419]で定義）を使用する必要があります。
The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411]:
次のTCは、SNMP-Framework-Mib [RFC3411]で定義されています。
SnmpAdminString OCTET STRING (SIZE (0..255))
snmpadminstringオクテット文字列（サイズ（0..255））
The following TCs are defined in SYSAPPL-MIB [RFC2287]:
次のTCは、Sysappl-Mib [RFC2287]で定義されています。
Utf8String OCTET STRING (SIZE (0..255))
LongUtf8String OCTET 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
The following TCs are defined in TRANSPORT-ADDRESS-MIB [RFC3419]:
次のTCは、Transport-Address-Mib [RFC3419]で定義されています。
TransportDomain OBJECT IDENTIFIER
TransportAddressType enumerated 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 CounterBasedGage64 Counter64
The following TCs are defined in IF-MIB [RFC2863]:
次のTCは、if-mib [rfc2863]で定義されています。
InterfaceIndex Integer32 (1..2147483647) InterfaceIndexOrZero Integer32 (0..2147483647)
interfaceindex integer32（1..2147483647）interfaceindexorzero integer32（0..2147483647）
The following TCs are defined in ENTITY-MIB [RFC4133]:
次のTCは、エンティティ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
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
Appendix C: Suggested Naming Conventions
付録C：命名規則を提案しました
Authors and reviewers of IETF MIB modules have often found the following naming conventions to be helpful in the past, and authors of new IETF MIB modules are urged to consider following them.
IETF MIBモジュールの著者とレビュアーは、以下の命名規則が過去に役立つことをしばしば発見し、新しいIETF MIBモジュールの著者は、それらをフォローすることを検討することを求められています。
- The module name should be of the form XXX-MIB (or XXX-TC-MIB for a module with TCs only), where XXX is a unique prefix (usually all caps with hyphens for separators) that is not used by any existing module. For example, the module for managing optical interfaces [RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB.
- モジュール名はxxx-mib（またはTCSのみのモジュールのxxx-tc-mib）の形式である必要があります。ここで、xxxは既存のモジュールでは使用されていない一意のプレフィックス（通常はセパレータにハイフンを含むすべてのキャップ）です。たとえば、光インターフェイス[RFC3591]を管理するモジュールは、プレフィックスopt-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.
- モジュール同一性の呼び出しに関連付けられた記述子は、xxxmib、xxxmib、またはxxxmibmoduleの形式でなければなりません。ここでは、xxxはxxxの混合ケースバージョンであり、xxxは低ケースで始まります。たとえば、Opt-if-mibはプレフィックスoptifを使用し、そのモジュール同一性の呼び出しに関連付けられた記述子は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モジュールに固有のTCの名前と概念的なテーブル定義で使用されるシーケンスタイプの名前は、xxxと同じプレフィックスxxxで始まる必要がありますが、最初の文字は大文字に変更されます。Opt-if-MIBは、TCSの名前とシーケンスタイプの接頭辞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.
- 概念テーブルに関連付けられた記述子は、xxxzzzztable形式である必要があります。対応する概念行に関連付けられた記述子は、xxxzzzzentryの形式でなければなりません。関連するシーケンスタイプの名前は、xxxzzzzentryの形式でなければなりません。また、下位の柱状オブジェクトに関連付けられた記述子は、xxxzzzzsomeothernameの形式でなければなりません。Opt-if-MIBの例は、OTMNテーブルです。
- When abbreviations are used, then they should be used consistently. Inconsistent usage such as
- 略語が使用される場合、それらは一貫して使用する必要があります。などの一貫性のない使用
xxxYyyDestAddr xxxZzzDstAddr
xxxyyydestaddr xxxzzzdstaddr
should be avoided.
避けるべきです。
Appendix D: Suggested OID Layout
付録D：OIDレイアウトを提案します
As noted in RFC 2578 Section 5.6, it is common practice to use the value of the MODULE-IDENTITY invocation as a subtree under which other OBJECT IDENTIFIER values assigned within the module are defined. That, of course, leaves open the question of how OIDs are assigned within that subtree. One assignment scheme that has gained favor -- and that is RECOMMENDED unless there is a specific reason not use it -- is to have three separate branches immediately below the MODULE-IDENTITY value dedicated (respectively) to notification definitions, object definitions, and conformance definitions, and to further subdivide the conformance branch into separate sub-branches for compliance statements and object/notification groups. This structure is illustrated below, with naming conventions following those outlined in Appendix C. The numbers in parentheses are the sub-identifiers assigned to the branches.
RFC 2578セクション5.6で述べたように、モジュール内で割り当てられた他のオブジェクト識別子値が定義されているサブツリーとして、モジュール同一性呼び出しの値をサブツリーとして使用することが一般的な慣行です。もちろん、そのサブツリー内にOIDがどのように割り当てられているかという問題が残っています。好意を得た1つの割り当てスキーム - それを使用しない特定の理由がない限り推奨されます - は、モジュール同意値のすぐ下に（それぞれ）通知定義、オブジェクト定義、および適合性に専用の3つの分岐を持つことです。定義、およびコンプライアンスステートメントとオブジェクト/通知グループのために、適合ブランチを別々のサブブランチにさらに細分化するため。この構造を以下に示します。付録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モジュールの1つの例は、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、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] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、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、「The Interfaces Group 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. Hanson、「インターフェースグループ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] Bradner、S。、「貢献におけるIETFの権利」、BCP 78、RFC 3978、2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979] Bradner、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] Daniele、M.、Haberman、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。、「15分間隔に基づくパフォーマンス履歴を使用したMIBモジュールのテキストコンベンション」、RFC 3593、2003年9月。
[RFC3705] Ray, B. and R. Abbi, "High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals", RFC 3705, February 2004.
[RFC3705] Ray、B。およびR. Abbi、「15分間隔に基づくパフォーマンス履歴を使用したMIBモジュールの大容量のテキストコンベンション」、RFC 3705、2004年2月。
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management Information Base Version 2 using SMIv2", RFC 2021, January 1997.
[RFC2021] Waldbusser、S。、「リモートネットワーク監視管理情報ベース2バージョン2」、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] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを説明するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998.
[RFC2287] Krupczak、C。およびJ. Saperia、「アプリケーション用のシステムレベルの管理オブジェクトの定義」、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.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMP）の管理情報ベース（MIB）」、STD 62、RFC3418、2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Simple Network Management Protocol（SNMP）のプロトコル操作」、STD 62、RFC 3416、2002年12月。
[RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", RFC 4133, August 2005.
[RFC4133] Bierman、A。およびK. McCloghrie、「Entity 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] Daniele、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] Rose、M。およびK. McCloghrie、「TCP/IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212] Rose、M。およびK. McCloghrie、「Concise MIB Definitions」、STD 16、RFC 1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215] Rose、M。、「SNMPで使用するためのトラップを定義するための条約」、RFC 1215、1991年3月。
[RFC2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[RFC2223BIS] Reynolds、J。およびR. Braden、「コメントを要求する指示（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] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000.
[RFC2932] McCloghrie、K.、Farinacci、D。、およびD. Thaler、「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] Berger、A。およびD. Romascanu、「Power Ethernet 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] Frye、R.、Levi、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] de Graaf、K.、Romascanu、D.、McMaster、D.、およびK. McCloghrie、「SMIV2を使用したIEEE 802.3リピーターデバイスの管理オブジェクトの定義」、RFC 2108、1997年2月。
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002.
[RFC3289] Baker、F.、Chan、K。、およびA. Smith、「差別化されたサービスアーキテクチャの管理情報ベース」、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. Rose、「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] Brown、T。およびK. Tesink、「SONET/SDHインターフェイスタイプの管理オブジェクトの定義」、RFC 1595、1994年3月。
[RFC2558] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC 2558, March 1999.
[RFC2558] Tesink、K。、「SONET/SDHインターフェイスタイプの管理オブジェクトの定義」、RFC 2558、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] Lam、H-K。、Stewart、M。、およびA. Huynh、「光インターフェイスタイプの管理オブジェクトの定義」、RFC 3591、2003年9月。
Editor's Address
編集者のアドレス
C. M. Heard 158 South Madison Ave. #207 Pasadena, CA 91101-2569 USA
C. M.ハード158サウスマディソンアベニュー＃207パサデナ、カリフォルニア91101-2569 USA
Phone: +1 626 795 5311
EMail: heard@pobox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。