Network Working Group C. Heard, Ed.
Request for Comments: 4181 September 2005
BCP: 111
Category: Best Current Practice
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).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo provides guidelines for authors and reviewers of IETF standards-track specifications containing MIB modules. Applicable portions may be used as a basis for reviews of other MIB documents.
本备忘录为包含MIB模块的IETF标准跟踪规范的作者和评审人员提供了指南。适用部分可作为审查其他MIB文件的基础。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. General Documentation Guidelines ................................4
3.1. MIB Boilerplate Section ....................................4
3.2. Narrative Sections .........................................5
3.3. Definitions Section ........................................5
3.4. Security Considerations Section ............................5
3.5. IANA Considerations Section ................................6
3.5.1. Documents that Create a New Name Space ..............6
3.5.2. Documents that Require Assignments in
Existing Namespace(s) ...............................7
3.5.3. Documents with No IANA Requests .....................8
3.6. References Sections ........................................8
3.7. Copyright Notices ..........................................9
3.8. Intellectual Property Section .............................10
4. SMIv2 Usage Guidelines .........................................10
4.1. Module Names ..............................................10
4.2. Descriptors, TC Names, and Labels .........................10
4.3. Naming Hierarchy ..........................................11
4.4. IMPORTS Statement .........................................11
4.5. MODULE-IDENTITY Invocation ................................12
4.6. Textual Conventions and Object Definitions ................14
1. 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
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）[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.
请注意，本备忘录中的指南无意改变现有BCP或互联网标准的要求或禁止（在RFC 2119[RFC2119]中定义的“必须”、“不得”、“应”或“不应”），除非这些要求或禁止含糊不清或相互矛盾。在存在歧义或矛盾的特殊情况下，本备忘录记录了当前普遍接受的解释。在某些情况下，本备忘录中的指南确实改变了现有BCP或互联网标准的建议（在RFC 2119中定义的“应该”、“不应该”、“建议”或“不建议”的意义上）。实践经验表明，已发布的建议不太理想时，就可以这样做。此外，本备忘录还提供了在就首选方法达成共识的情况下，选择某些SMIv2选项（在RFC 2119中定义的“可能”或“可选”的意义上）的指南。
Although some of the guidelines in this memo are not applicable to non-standards track or non-IETF MIB documents, authors and reviewers of those documents should consider using the ones that do apply.
虽然本备忘录中的一些准则不适用于非标准轨道或非IETF MIB文件，但这些文件的作者和审核员应考虑使用那些适用的文件。
Reviewers and authors need to be aware that some of the guidelines in this memo do not apply to MIB modules that have been translated to SMIv2 from SMIv1 (STD 16) [RFC1155] [RFC1212] [RFC1215].
评审员和作者需要注意，本备忘录中的一些指南不适用于已从SMIv1（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].
本备忘录指南中使用的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照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节中定义的三种信息模块中的任何一种。
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模块的结构。
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;
定义一个或多个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.
为了遵守IESG政策，如http://www.ietf.org/ID-Checklist.html，提交给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)，它定义了IF-MIB[RFC2863]和IANA-RTPROTO-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
这种情况下的当前做法是在每个IANA维护的MIB模块中的模块标识调用的描述条款中包含符合RFC 2434的详细IANA注意事项部分，以及MIB文档中定义名称空间以引用相关模块URL的IANA注意事项部分。有关示例，请参见RFC 2932[RFC2932]。这给尚未作为RFC发布的MIB文档带来了鸡和蛋的问题，因为相关IANA维护的MIB模块还不存在。摆脱这一困境的公认方法是将每个IANA维护的MIB模块的初始内容包含在定义名称空间的文件初始版本的非规范部分中；有关示例，请参见[RFC1573]，其中
documents the initial version of the IANAifType-MIB. That material is usually omitted from subsequent updates to the document since the IANA-maintained modules are then available on-line (cf. [RFC2863]).
记录IANAifType MIB的初始版本。由于IANA维护的模块可在线使用（参见[RFC2863]），因此该材料通常在后续的文件更新中被省略。
Reviewers of draft MIB documents to which these considerations apply MUST check that the IANA Considerations section proposed for publication in the RFC is present and contains pointers to the appropriate IANA-maintained MIB modules. Reviewers of Internet Drafts that contain the proposed initial content of IANA-maintained MIB modules MUST also verify that the DESCRIPTION clauses of the MODULE-IDENTITY invocations contain an IANA Considerations section compliant with the guidelines in RFC 2434.
这些注意事项适用的MIB文件草案的审核人必须检查提议在RFC中发布的IANA注意事项部分是否存在，并包含指向适当IANA维护的MIB模块的指针。包含IANA维护的MIB模块的建议初始内容的互联网草案的审阅者还必须验证模块标识调用的描述条款是否包含符合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:
如果互联网草案要求IANA在作为RFC发布之前更新现有注册，那么草案中的IANA注意事项部分必须记录该事实。包含MIB模块初始版本的MIB文档通常要求IANA为MIB模块的module-IDENTITY值分配一个对象标识符值，并可能进行其他分配。包含此类MIB模块的Internet草稿必须包含IANA注意事项部分，该部分指定要更新的注册表、要分配对象标识符值的描述符以及要分配值的子树。应精心编制文本，以便在发布后用于记录对象标识符分配。例如，以下内容适用于包含单个MIB模块的Internet草稿，该MIB模块具有模块标识描述符powerEthernetMIB，将在“MIB-2”子树下分配一个值：
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
---------- -----------------------
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注意事项部分。当Internet草稿包含以前发布的MIB模块的更新时，通常不需要IANA采取任何行动，但它可能会继承一个IANA注意事项部分，该部分记录了RFC中包含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
---------- -----------------------
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
标准MIB样板可在http://www.ops.ietf.org/mib-boilerplate.html 包括所有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).
包含MIB模块的规范。如果来自其他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模块的MODULE-IDENTITY调用的DESCRIPTION子句必须包含指向RFC中版权声明的指针。适用于除IANA维护的MIB模块以外的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编辑：将yyyy替换为实际的RFC编号并删除此注释
A template suitable for MIB modules that are to be maintained by the IANA is as follows:
适用于IANA维护的MIB模块的模板如下：
DESCRIPTION " [ ... ]
说明“[……]
Copyright (C) The Internet Society (date). The initial
version of this MIB module was published in RFC yyyy;
for full legal notices see the RFC itself. Supplementary
information may be available at:
http://www.ietf.org/copyrights/ianamib.html."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note
Copyright (C) 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".
在每种情况下，应插入当年，以取代“日期”一词。
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模块必须符合SMIv2[RFC2578][RFC2579][RFC2580]中适用于“标准”MIB模块的所有语法和语义要求，除非下文另有说明，否则应符合SMIv2建议。本节中的指南旨在通过以下方式补充SMIv2文件：
o to document the current generally accepted interpretation when those documents contain ambiguities or contradictions;
o 当这些文件包含歧义或矛盾时，记录当前普遍接受的解释；
o to update recommendations in those documents that have been shown by practical experience to be out-of-date or otherwise suboptimal;
o 更新实践经验表明过时或不理想的文件中的建议；
o to provide guidance in selection of SMIv2 options in cases where there is a consensus on a preferred approach.
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个字符通常与建议的助记符和唯一性（请参见RFC 2578第3.1节和RFC 2579第3节）相冲突（对于描述符和TC名称）。当前MIB审查人员的共识是，SMIv2建议将描述符、TC名称和标签限制为32个字符，为了提高清晰度和唯一性，应该将其放在一边，并且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标准轨道时，要求将对象从实验子树移动到管理子树。
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
一般要求是，如果使用的外部符号不是预定义的ASN.1类型或BITS构造，则必须在模块的IMPORTS语句中提及。该节第一段中的“外部物体”一词可给出
impression that such symbols are limited to those that refer to object definitions, but that is not the case, as subsequent paragraphs should make clear.
给人的印象是，这些符号仅限于涉及对象定义的符号，但事实并非如此，后面的段落应该说明这一点。
Note that exemptions to this general requirement are granted by RFC 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in the OBJECT clause of a MODULE-COMPLIANCE statement or in the VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB compilers also grant exemptions to descriptors of notifications appearing in a VARIATION clause and to descriptors of object groups and notification groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or an INCLUDES clause, although RFC 2580 (through apparent oversight) does not mention those cases. The exemptions are sometimes seen as unhelpful because they make IMPORTS rules more complicated and inter-module dependencies less obvious than they otherwise would be. External symbols referenced by compliance statements and capabilities statements MAY therefore be listed in the IMPORTS statement; if this is done, it SHOULD be done consistently.
请注意，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模块仅以一次MODULE-IDENTITY宏调用开始。此调用必须立即出现在IMPORTS语句之后。
RFC 2578 Section 5 describes how the various clauses are used. The following additional guidelines apply to all MIB modules over which the IETF has change control:
RFC 2578第5节描述了各种条款的使用方式。以下附加指南适用于IETF拥有变更控制权的所有MIB模块：
- If the module was developed by an IETF working group, then the ORGANIZATION clause MUST provide the full name of the working group, and the CONTACT-INFO clause MUST include working group mailing list information. The CONTACT-INFO clause SHOULD also provide a pointer to the working group's web page.
- 如果模块由IETF工作组开发，则组织条款必须提供工作组的全名，联系信息条款必须包括工作组邮件列表信息。CONTACT-INFO子句还应提供指向工作组网页的指针。
- 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时间必须与上次更新条款的UTC时间相匹配。与各修订相关的说明条款必须说明该修订出现的RFC，并应提供所有重大变更的列表。修订MIB模块时，应更新所有修订条款中的UTC时间，以使用四位年份符号。
- 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模块）应位于管理子树[RFC2578]下。通常是mib-2[RFC2578]下的IANA赋值，但对于扩展IF-mib[RFC2863]的媒体特定mib模块，通常在传输[RFC2578]下使用IANA赋值。在过去，一些IETF工作组根据IANA委托给他们的子树进行了自己的任务分配，但事实证明这种做法存在问题，不推荐使用。
While a MIB module is under development, the RFC number in which it will eventually be published is usually unknown and must be filled in by the RFC Editor prior to publication. An appropriate form for the REVISION clause applying to a version under development would be something along the following lines:
MIB模块在开发过程中，其最终发布的RFC编号通常未知，必须在发布前由RFC编辑器填写。适用于正在开发的版本的修订条款的适当形式如下：
REVISION "200212132358Z" -- December 13, 2002 DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note
修订版“2002132358Z”-2002年12月13日描述“初始版本，发布为RFC yyyy”-RFC版：用实际RFC编号替换yyyy并删除此注释
Note that after RFC publication, a REVISION clause is present only for published versions of a MIB module and not for interim versions that existed only as Internet-Drafts. Thus, a draft version of a MIB module MUST contain just one new REVISION clause that covers all changes since the last published version (if any).
请注意，RFC发布后，修订条款仅适用于MIB模块的已发布版本，而不适用于仅作为Internet草稿存在的临时版本。因此，MIB模块的草稿版本必须只包含一个新的修订条款，涵盖自上次发布版本（如果有）以来的所有更改。
When the initial version of a MIB module is under development, the value assigned to the MODULE-IDENTITY descriptor will be unknown if an IANA-assigned value is used, because the assignment is made just prior to publication as an RFC. The accepted form for the MODULE-IDENTITY statement in draft versions of such a module is something along the following lines:
当MIB模块的初始版本正在开发中时，如果使用IANA分配的值，分配给模块标识描述符的值将是未知的，因为分配是在作为RFC发布之前进行的。在此类模块的草稿版本中，模块标识语句的公认形式大致如下：
<descriptor> MODULE-IDENTITY
<descriptor>MODULE-IDENTITY
[ ... ]
[ ... ]
::= { <subtree> XXX }
-- RFC Ed.: replace XXX with IANA-assigned number & remove this note
::= { <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.
其中，<descriptor>是为模块选择的任何描述符，<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:
RFC 2578第2节描述了32位整数数据类型integer、Integer32、Gauge32和Unsigned32，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.
- 整数是必需的；-不得使用整数32、无符号32和量规32。
Note that RFC 2578 recommends (but does not require) that integer-valued enumerations start at 1 and be numbered contiguously. This recommendation SHOULD be followed unless there is a valid reason to do otherwise, e.g., to match values of external data or to indicate special cases, and any such special-case usage SHOULD be clearly documented. For an example, see the InetAddressType TC [RFC4001].
请注意，RFC2578建议（但不要求）整数值枚举从1开始并连续编号。除非有正当理由，否则应遵循本建议，例如，匹配外部数据值或指示特殊情况，并且应明确记录任何此类特殊情况的使用。有关示例，请参见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.
- 建议使用整数32；-整数是可接受的；-不得使用无符号32和量规32。
- 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.
- 建议使用量规32；-未签名的32是可以接受的；-如果值可能大于2147483647，则不得使用INTEGER和Integer32。
- If the value range is between 0..4294967295 (inclusive), and values greater than 2147483647 are possible, and the value of the information being modelled does not increase above the maximum value nor decrease below the minimum value, then:
- 如果值范围在0到4294967295（包括0到4294967295）之间，并且值可能大于2147483647，并且建模信息的值不会增加到最大值以上，也不会减少到最小值以下，则：
- Unsigned32 is RECOMMENDED; - Gauge32 is acceptable; - INTEGER and Integer32 MUST NOT be used.
- 建议使用Unsigned32；-可接受量规32；-不能使用整数和整数32。
- 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之间（包括0到2147483647之间），并且正在建模的信息的值不会增加到最大值以上，也不会减少到最小值以下，则：
- Unsigned32 is RECOMMENDED; - INTEGER, Integer32, and Gauge32 are acceptable.
- 建议使用Unsigned32；-可接受整数、整数32和量规32。
- For integer-valued objects that appear in an INDEX clause or for integer-valued TCs that are to be used in an index column:
- 对于出现在索引子句中的整数值对象或要在索引列中使用的整数值TC：
- Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause.
- 对于大多数索引对象，建议使用范围不包括零的Unsigned32。如果零在语义上有意义，或者当它用作具有特殊属性的唯一行的索引值时，可以在范围中包含零。此类用法应清楚地记录在说明条款中。
- Integer32 or INTEGER with a non-negative range is acceptable. Again, zero SHOULD be excluded from the range except when it is semantically significant or when it is used as the index value for a unique row with special properties, and in such cases the usage SHOULD be clearly documented in the DESCRIPTION clause.
- 可接受整数32或非负范围的整数。同样，零应该被排除在范围之外，除非它在语义上是重要的，或者当它被用作具有特殊属性的唯一行的索引值时，并且在这种情况下，应该在DESCRIPTION子句中清楚地记录其用法。
- Use of Gauge32 is acceptable for index objects that have gauge semantics.
- 对于具有量表语义的索引对象，可以使用量表32。
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]。在这种情况下，包含该对象的模块的作者应该考虑定义TCS，例如接口索引和/或接口索引Orth[RCFC663]。
Note that INTEGER is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement, whereas Integer32, Gauge32, and Unsigned32 are defined by SNMPv2-SMI and MUST be imported from that module if used.
请注意，INTEGER是预定义的ASN.1类型，不能出现在模块的IMPORTS语句中，而Integer32、Gauge32和Unsigned32由SNMPv2 SMI定义，如果使用，则必须从该模块导入。
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].
- 当管理子系统重新初始化或发生其他异常/不规则事件时（例如，线路卡上维护的计数器在线路卡重置时可能会重置），可以使用计数器32/64重置计数器。但是，如果可能发生此类其他异常/不规则事件，则说明条款必须说明这一情况，并且必须充分详细地说明这些其他异常/不规则事件，以便管理应用程序能够确定自上次轮询计数器以来是否发生了重置。建议的方法是提供RFC 2578第7.1.6节和第7.1.10节所述的不连续指示器。有关此类不连续性指示符的示例，请参见IF-MIB[RFC2863]中的IFCounterIntercontinuctionTime对象。
- 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].
- 一个管理器请求代理将计数器的值重置为零是不合适的，而计数器32/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
RFC 2578第7.1.10节对“标准”MIB模块提出了一项要求，即只有在使用Counter32类型的情况下，所建模的信息将在不到一小时的时间内包装完毕，才能使用Counter64类型。既然SNMPv3是互联网标准，SNMPv1是历史性的（参见http://www.rfc-editor.org/rfcxx00.html 对于状态和[RFC3410]的基本原理），没有理由继续执行此限制。此后，“标准”MIB模块可以在合理的情况下使用Counter64类型，并且必须使用
Counter64 if the information being modelled would wrap in less than one hour if the Counter32 type was used instead. Note also that there is no longer a requirement to define Counter32 counterparts for each Counter64 object, although one is still allowed to do so.
如果使用Counter32类型，则正在建模的信息将在不到一小时内包装完毕。还请注意，不再需要为每个Counter64对象定义Counter32对应项，尽管仍然允许这样做。
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]中分别定义了与零基计数器32和零基计数器64密切相关的文本约定。
The only difference between ZeroBasedCounter32/64 TCs and Counter32/64 is their starting value; at time=X, where X is their minimum-wrap-time after they were created, the behavior of ZeroBasedCounter32/64 becomes exactly the same as Counter32/64. Thus, the preceding paragraphs/rules apply not only to Counter32/64, but also to ZeroBasedCounter32/64 TCs.
ZeroBasedCounter32/64 TC和Counter32/64之间的唯一区别是它们的起始值；在time=X时，其中X是它们创建后的最小换行时间，ZeroBasedCounter32/64的行为与Counter32/64完全相同。因此，前面的段落/规则不仅适用于计数器32/64，还适用于ZeroBasedCounter32/64 TC。
SMIv2 unfortunately does not provide 64-bit integer base types. In order to make up for this omission, the CounterBasedGauge64 textual convention is defined in HCNUM-TC [RFC2856]. This TC uses Counter64 as a base type, but discards the special counter semantics, which is allowed under the generally accepted interpretation of RFC 2579 Section 3.3. It does inherit all the syntactic restrictions of that type, which means that it MUST NOT be subtyped and that objects defined with it MUST NOT appear in an INDEX clause, MUST NOT have a DEFVAL clause, and MUST have a MAX-ACCESS of read-only or accessible-for-notify.
很遗憾，SMIv2不提供64位整数基类型。为了弥补这一遗漏，HCNUM-TC[RFC2856]中定义了反基GAUGE64文本约定。此TC使用Counter64作为基类型，但放弃特殊的计数器语义，这是RFC2579第3.3节的普遍接受解释所允许的。它确实继承了该类型的所有语法限制，这意味着它不能是子类型，用它定义的对象不能出现在索引子句中，不能有DEFVAL子句，并且必须具有只读或可访问的MAX-ACCESS for 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位无符号数据类型，则必须使用基于Counter64的不同TC，因为一个TC不能细化另一个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.
RFC 2578第7.1.2节描述了八位字节字符串类型。它表示长度在0到65535个八位字节（含）之间的任意二进制或文本数据。当实际边界比SMI施加的限制更严格时，语法为此类型的对象和TC应该具有大小约束。对于索引对象尤其如此。但是，请注意，不应随意施加大小限制，因为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.
存在许多标准的TCs，它们满足特定八位字节字符串类型的一些更常见的要求。特别地，snmpv2tc[RFC2579]包含显示字符串、PhysAddress、MacAddress和DateAndTime TCs；SNMP-FRAMEWORK-MIB[RFC3411]包含SnmpAdminString TC；SYSAPPL-MIB[RFC2287]包含Utf8String和LongUtf8String TCs。当标准TC提供所需的语义时，应该在对象的语法子句中使用它，而不是在八位字节字符串或等效的本地定义TC中使用。
Note that OCTET STRING is a predefined ASN.1 type and MUST NOT be present in a module's IMPORTS statement.
请注意，八进制字符串是预定义的ASN.1类型，不能出现在模块的IMPORTS语句中。
The OBJECT IDENTIFIER type is described in RFC 2578 Section 7.1.3. Its instances represent administratively assigned names. Note that both the SMI and the SNMP protocol limit instances of this type to 128 sub-identifiers and require that each sub-identifier be within the range 0 to 4294967295 inclusive. Subtyping is not allowed.
RFC 2578第7.1.3节描述了对象标识符类型。其实例表示管理分配的名称。请注意，SMI和SNMP协议都将此类型的实例限制为128个子标识符，并要求每个子标识符都在0到4294967295（包括0到4294967295）的范围内。不允许使用子类型。
The purpose of OBJECT IDENTIFIER values is to provide authoritative identification either for some type of item or for a specific instance of some type of item. Among the items that can be identified in this way are definitions in MIB modules created via the MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES constructs; and via instances of objects defined in MIB modules, protocols, languages, specifications, interface types, hardware, and software. For some of these uses other possibilities exist, e.g., OCTET STRING or enumerated INTEGER values. The OBJECT IDENTIFIER type SHOULD be used instead of the alternatives when the set of identification values needs to be independently extensible without the need for a registry to provide centralized coordination.
对象标识符值的目的是为某种类型的项或某种类型的项的特定实例提供权威标识。可以通过这种方式识别的项目包括通过MODULE-IDENTITY、OBJECT-IDENTITY、OBJECT-TYPE、NOTIFICATION-TYPE、OBJECT-GROUP、NOTIFICATION-GROUP、MODULE-COMPLIANCE和AGENT-CAPABILITIES构造创建的MIB模块中的定义；以及通过MIB模块、协议、语言、规范、接口类型、硬件和软件中定义的对象实例。对于其中一些用途，还存在其他可能性，例如八位字符串或枚举整数值。当标识值集需要独立扩展而不需要注册表来提供集中协调时，应使用对象标识符类型而不是替代方法。
There exist a number of standard TCs that cater to some of the more common requirements for specialized OBJECT IDENTIFIER types. In particular, SNMPv2-TC [RFC2579] contains the AutonomousType, VariablePointer, and RowPointer TCs. When a standard TC provides the desired semantics, it SHOULD be used in an object's SYNTAX clause instead of OBJECT IDENTIFIER or an equivalent locally-defined TC.
存在许多标准TC，这些TC满足特定对象标识符类型的一些更常见的要求。特别是，SNMPv2 TC[RFC2579]包含自治类型、VariablePointer和RowPointer TC。当标准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类型，不能出现在模块的IMPORTS语句中。
The BITS construct is described in RFC 2578 Section 7.1.4. It represents an enumeration of named bits. The bit positions in a TC or object definition whose SYNTAX is of this type MUST start at 0 and SHOULD be contiguous.
RFC 2578第7.1.4节描述了BITS结构。它表示命名位的枚举。语法为这种类型的TC或对象定义中的位位置必须从0开始，并且应该是连续的。
Note that the BITS construct is defined by the macros that use it and therefore MUST NOT be present in a module's IMPORTS statement.
请注意，BITS构造是由使用它的宏定义的，因此不能出现在模块的IMPORTS语句中。
The IpAddress type described in RFC 2578 Section 7.1.5 SHOULD NOT be used in new MIB modules. The InetAddress/InetAddressType textual conventions [RFC4001] SHOULD be used instead.
RFC 2578第7.1.5节中描述的IP地址类型不应用于新的MIB模块。应改用InetAddress/InetAddressType文本约定[RFC4001]。
The TimeTicks type is described in RFC 2578 Section 7.1.8. It represents the time in hundredths of a second between two epochs, reduced modulo 2^32. It MUST NOT be subtyped, and the DESCRIPTION clause of any object or TC whose SYNTAX is of this type MUST identify the reference epochs.
RFC 2578第7.1.8节描述了时间刻度类型。它表示两个时代之间的百分之一秒时间，约化模为2^32。它不能是子类型，并且语法为该类型的任何对象或TC的DESCRIPTION子句必须标识引用年代。
The TimeTicks type SHOULD NOT be used directly in definitions of objects that are snapshots of sysUpTime [RFC3418]. The TimeStamp TC [RFC2579] already conveys the desired semantics and SHOULD be used instead.
TimeTicks类型不应直接用于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).
真实值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模块的作者需要知道，在某些情况下，枚举整数或位TCs可能会使用额外的枚举值或额外的位位置进行扩展。当以这种方式扩展的导入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.
对于所有对象和TC来说，准确明确的描述子句的重要性怎么强调都不过分。DESCRIPTION子句包含实现者用于实现对象的指令，如果指令不充分或不明确，则实现质量将受到影响。MIB审阅者最重要的一项工作可能是确保描述子句足够清晰，以允许创建可互操作的实现。
A very common problem is to see an object definition for, say, 'stdMIBPoofpoofCounter' with a DESCRIPTION clause that just says "Number of poofpoofs" with no indication what a 'poofpoof' is. In such cases, it is strongly RECOMMENDED that there either be at least a minimal explanation or else a REFERENCE clause to point to the definition of a 'poofpoof'.
一个非常常见的问题是看到一个对象定义，比如说，“stdMIBPoofpoofCounter”，其中有一个DESCRIPTION子句，该子句只表示“poofpoof数”，而没有指示“poofpoof”是什么。在这种情况下，强烈建议至少有一个最低限度的解释，或者有一个参考条款来指出“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.
对于读写对象（读创建表中具有定义良好的持久性属性的列除外），建议在DESCRIPTION子句中指定代理重新启动后该值会发生什么变化。其中一种可能性是该值保持不变，恢复为定义良好的默认值，或者结果取决于实现。
The DISPLAY-HINT clause is used in a TC to provide a nonbinding hint to a management application as to how the value of an instance of an object defined with the syntax in the TC might be displayed. Its presence is optional.
DISPLAY-HINT子句在TC中用于向管理应用程序提供非绑定提示，提示如何显示使用TC中的语法定义的对象实例的值。它的存在是可选的。
Although management applications typically default to decimal format ("d") for integer TCs that are not enumerations and to a hexadecimal format ("1x:" or "1x " or "1x_") for octet string TCs when the DISPLAY-HINT clause is absent, it should be noted that SMIv2 does not actually specify any defaults. MIB authors should be aware that a clear hint is provided to applications only when the DISPLAY-HINT clause is present.
尽管对于非枚举的整数TC，管理应用程序通常默认为十进制格式（“d”），而对于八位字符串TC，当DISPLAY-HINT子句不存在时，则默认为十六进制格式（“1x:”或“1x”或“1x\”），但应注意的是，SMIv2实际上并未指定任何默认值。MIB作者应该知道，只有当DISPLAY-hint子句存在时，才会向应用程序提供明确的提示。
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.
- 如果该行是某个其他表中某行的扩展，则如果该关系是一对一，则必须使用AUGMENTS子句；如果该关系是稀疏的，则必须使用INDEX子句。在后一种情况下，INDEX子句应该与原始表的相同。
- If the row is an element of an expansion table -- that is, if multiple row instances correspond to a single row instance in some other table -- then an INDEX clause MUST be used, and the first-mentioned elements SHOULD be the indices of that other table, listed in the same order.
- 如果行是扩展表的一个元素——也就是说，如果多个行实例对应于某个其他表中的一个行实例——那么必须使用INDEX子句，前面提到的元素应该是该其他表的索引，并按相同的顺序列出。
- If objects external to the row are present in the INDEX clause, then the conceptual row's DESCRIPTION clause MUST specify how those objects are used in identifying instances of its columnar objects, and in particular MUST specify for which values of those index objects the conceptual row may exist.
- 如果INDEX子句中存在行外部的对象，则概念行的DESCRIPTION子句必须指定如何使用这些对象来标识其列对象的实例，特别是必须指定概念行可能存在这些索引对象的哪些值。
- 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
- 对于可能出现在扩展表的index子句中的任何索引对象，不建议使用隐含关键字。由于此关键字只能与INDEX子句中的最后一个对象关联，因此不能与主表和扩展表中的同一索引对象关联。这将导致主表和任意表中的排序顺序不同
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.
扩展表。因此，实现将无法重用扩展表中主表中的索引代码，并且实际上可能必须复制要扩展的数据结构。试图使用隐含的设计者应该考虑，结果排序顺序很少满足用户的期望，特别是对于包含大写字母和小写字母的字符串，并且它不考虑用户语言或区域设置。
- 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.
- 应该有一个columnar对象，语法值为RowStatus[RFC2579]，MAX-ACCESS值为read create。此对象称为概念行的状态列。所有其他列对象的MAX-ACCESS值必须为read-create、read-only、accessible for notify或not-accessible；不允许读写的最大访问值。
- 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的列对象，否则row object（table entry）DESCRIPTION子句必须指定在代理重新启动后动态创建的行的情况。
- If the agent itself may also create and/or delete rows, then the conditions under which this can occur MUST be clearly documented in the row object DESCRIPTION clause.
- 如果代理本身也可以创建和/或删除行，则必须在row object DESCRIPTION子句中明确记录发生这种情况的条件。
- 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.
- status列的DESCRIPTION子句必须指定在激活行之前必须将哪些列对象（如果有）设置为有效值。如果在激活行之前，级联表中的任何对象都必须填充相关数据，则还必须指定该行。
- 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).
- status列的DESCRIPTION子句必须指定当status值处于活动状态时，是否可以修改同一概念行中的其他列（1）。请注意，在许多情况下，当行处于活动状态时，可以修改某些可写列，但不能修改其他列。在这种情况下，每个可写列的DESCRIPTION子句应说明行处于活动状态时该列是否可以修改，status列的DESCRIPTION子句应说明在这些列的DESCRIPTION子句中指定了状态值处于活动状态（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列的DESCRIPTION子句必须指定代理至少必须允许写入的永久（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列，则扩充行中不需要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 TCs的完整要求可在RFC 2579中找到，这些TCs的说明条款中。
RFC 2578 Section 7.10 specifies the rules for assigning OBJECT IDENTIFIER (OID) values to OBJECT-TYPE definitions. In particular:
RFC 2578第7.10节规定了为对象类型定义分配对象标识符（OID）值的规则。特别地：
- A conceptual table MUST have exactly one subordinate object, which is a conceptual row. The OID assigned to the conceptual row MUST be derived by appending a sub-identifier of "1" to the OID assigned to the conceptual table.
- 概念表必须只有一个从属对象，即概念行。分配给概念行的OID必须通过将子标识符“1”附加到分配给概念表的OID来派生。
- A conceptual row has as many subordinate objects as there are columns in the row; there MUST be at least one. The OID assigned to each columnar object MUST be derived by appending a non-zero sub-identifier, unique within the row, to the OID assigned to the conceptual row.
- 概念行的从属对象数量与行中的列数量相同；必须至少有一个。分配给每个列对象的OID必须通过向分配给概念行的OID追加一个非零子标识符（在行中是唯一的）来派生。
- A columnar or scalar object MUST NOT have any subordinate objects.
- 列对象或标量对象不能有任何从属对象。
- The last sub-identifier of an OID assigned to any object (be it table, row, column, or scalar) MUST NOT be equal to zero. Note that sub-identifiers of intermediate nodes MAY be equal to zero.
- 分配给任何对象（表、行、列或标量）的OID的最后一个子标识符不得等于零。注意，中间节点的子标识符可以等于零。
- The OID assigned to an object definition MUST NOT also be assigned to another definition that results in OID registration. RFC 2578 Section 3.6 lists the constructs that create OID registrations.
- 指定给对象定义的OID不得同时指定给导致OID注册的其他定义。RFC 2578第3.6节列出了创建OID注册的构造。
Although it is not specifically required by the SMI, it is customary (and strongly RECOMMENDED) that object definitions not be registered beneath group definitions, compliance statements, capabilities statements, or notification definitions. It is also customary (and strongly RECOMMENDED) that group definitions, compliance statements,
尽管SMI没有明确要求，但通常（并强烈建议）对象定义不应在组定义、合规性声明、功能声明或通知定义下注册。集团定义、合规性声明、，
capabilities statements, and notification definitions not be registered beneath object definitions. See Appendix D for a RECOMMENDED OID assignment scheme.
不能在对象定义下注册功能语句和通知定义。有关建议的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包括在对象定义中指定的“基本”OID加上索引组件的串联。当一个表有多个类型的索引（如八进制字符串或对象标识符）解析为多个子标识符时，可以很快达到128个子标识符的限制。
Despite its inconvenience, the 128-sub-identifier limit is not something that can be ignored. In addition to being imposed by the SMI, it is also imposed by the SNMP (see the last paragraph in Section 4.1 of RFC 3416 [RFC3416]). It follows that any table with enough indexing components to violate this limit cannot be read or written using the SNMP and so is unusable. Hence table design MUST take the 128-sub-identifier limit into account. It is RECOMMENDED that all MIB documents make explicit any limitations on index component lengths that management software must observe. This may be done either by including SIZE constraints on the index components or by specifying applicable constraints in the conceptual row DESCRIPTION clause or in the surrounding documentation.
尽管有不便之处，但128子标识符限制是不能忽略的。除了由SMI实施外，它还由SNMP实施（见RFC 3416[RFC3416]第4.1节的最后一段）。因此，任何包含足够多索引组件的表都无法使用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子句中提到的每种对象类型，DESCRIPTION子句必须指定要在传输的通知中出现的对象实例，并且必须指定传达的信息/含义。
- 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
- 分配给每种通知类型的对象标识符（OID）值必须有一个倒数第二子标识符为零，以便可以将SMIv2通知定义转换为SMIv1陷阱定义，然后再转换回来，而不会丢失信息（请参见[RFC3584]第2.1.2节）多语言代理链可以将SNMPv2陷阱转换为SNMPv1陷阱，然后再转换回来，而不会丢失信息（参见[RFC3584]第3节）。在里面
addition, the OID assigned to a notification definition MUST NOT also be assigned to another definition that results in OID registration. RFC 2578 Section 3.6 lists the constructs that create OID registrations.
此外，分配给通知定义的OID不得同时分配给导致OID注册的其他定义。RFC 2578第3.6节列出了创建OID注册的构造。
Although it is not specifically required by the SMI, it is customary (and strongly RECOMMENDED) that notification definitions not be registered beneath group definitions, compliance statements, capabilities statements, or object definitions (this last is especially unwise, as it may result in an object instance and a notification definition sharing the same OID). It is also customary (and strongly RECOMMENDED) that the OIDs assigned to notification types be leaf OIDs (i.e., that there be no OID registrations subordinate to a notification definition). See Appendix D for a RECOMMENDED OID assignment scheme.
尽管SMI没有明确要求，但通常（并强烈建议）通知定义不应在组定义、合规性声明、功能声明或对象定义下注册（后一种做法尤其不明智，因为这可能会导致对象实例和通知定义共享同一个OID）。分配给通知类型的OID通常（强烈建议）是叶OID（即，没有从属于通知定义的OID注册）。有关建议的OID分配方案，请参见附录D。
In many cases, notifications will be triggered by external events, and sometimes it will be possible for those external events to occur at a sufficiently rapid rate that sending a notification for each occurrence would overwhelm the network. In such cases, a mechanism MUST be provided for limiting the rate at which the notification can be generated. A common technique is to require that the notification generator use throttling -- that is, to require that it generate no more than one notification for each event source in any given time interval of duration T. The throttling period T MAY be configurable, in which case it is specified in a MIB object, or it MAY be fixed, in which case it is specified in the notification definition. Examples of the fixed time interval technique can be found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB [RFC4133].
在许多情况下，通知将由外部事件触发，有时这些外部事件可能以足够快的速度发生，以至于每次发送通知都会淹没网络。在这种情况下，必须提供一种机制来限制生成通知的速率。一种常见的技术是要求通知生成器使用限制——也就是说，要求它在任何给定的持续时间T的时间间隔内为每个事件源生成不超过一个通知。限制时间T可以是可配置的，在这种情况下，它在MIB对象中指定，或者是固定的，在这种情况下，它在通知定义中指定。固定时间间隔技术的示例可以在SNMP-REPEATER-MIB[RFC2108]和ENTITY-MIB[RFC4133]中找到。
RFC 2580 Sections 3, 4, and 5 specify the rules for conformance groups and compliance statements. In particular:
RFC 2580第3、4和5节规定了合规组和合规声明的规则。特别地：
- Every object with a MAX-ACCESS value other than "not-accessible" MUST be contained in at least one object group.
- 具有“不可访问”以外的MAX-ACCESS值的每个对象必须包含在至少一个对象组中。
- Every notification MUST be contained in at least one notification group.
- 每个通知必须包含在至少一个通知组中。
- 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模块定义至少一个符合性声明。它可以驻留在该MIB模块内，也可以驻留在配套的MIB模块内。
In writing compliance statements, there are several points that are easily overlooked:
在撰写合规性声明时，有几点容易被忽略：
- An object group or notification group that is not mentioned either in the MANDATORY-GROUPS clause or in any GROUP clause of a MODULE-COMPLIANCE statement is unconditionally optional with respect to that compliance statement. An alternate way to indicate that an object group or notification group is optional is to mention it in a GROUP clause whose DESCRIPTION clause states that the group is optional. The latter method is RECOMMENDED (for optional groups that are relevant to the compliance statement) in order to make it clear that the optional status is intended rather than being the result of an act of omission.
- 在模块合规性声明的强制-GROUPS条款或任何group条款中未提及的对象组或通知组对于该合规性声明是无条件可选的。指示对象组或通知组是可选的另一种方法是在group子句中提及它，group子句的DESCRIPTION子句声明该组是可选的。建议采用后一种方法（适用于与合规性声明相关的可选组），以明确可选状态是故意的，而不是不作为的结果。
- 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.
- 如果有任何对象的MAX-ACCESS值为read-write或read-create，并且没有为其指定只读的MIN-ACCESS的OBJECT子句，则实现必须支持对这些对象的写访问，以符合该MODULE-COMPLIANCE语句。这一事实有时会让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语句包含以下OBJECT子句。（见第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."
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只读说明“不需要写访问，active是唯一需要支持的状态。”
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).
不能对不可访问的索引对象执行此操作，因为它们不能出现在对象组中，也不能在对象子句中提及。然而，在某些情况下，人们可能希望指出一个实现只需要支持读-创建表中某个索引的可能值的子集。在这种情况下，必须在索引对象的描述条款（如果只有一个值子集，建议使用）或模块合规性声明的描述条款（如果值子集对于合规性声明是唯一的，则需要使用）中指定要求。
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模块总是与一个或多个其他MIB模块一起实现。这一事实需要在相关文件中注明（见上文第3.2节），也应在相关合规声明中注明。如果（比如）MIB模块a中的特定合规性声明需要完全实现其他MIB模块B，则建议的方法是在MIB模块a中的合规性声明的描述条款中包含一条声明。但是，也有可能，MIB模块A的需求可能与模块B的任何合规性声明所表达的需求不同，例如，模块A可能不需要模块B中的任何无条件强制对象组，但可能需要强制实现模块B中的对象组，该对象组仅对模块B中的合规性声明具有条件强制。在这种情况下，推荐的方法适用于合规性声明在模块A中，通过适当的模块、强制分组、分组和目标条款正式规定模块B的要求。DIFFSERV-MIB[RFC3289]中的符合性声明提供了一个示例，它将来自IF-MIB[RFC2863]的IFCounterInteractionyGroup列为强制组。该组不足以满足任何IF-MIB合规性声明，并且在IF-MIB的当前合规性声明IFCompliance 3中有条件地强制执行。
There has been some dispute as to whether syntax refinements that restrict enumerations (RFC 2578 Section 9) are permitted with TCs, as shown in the examples above, or are allowed only with the base types
对于限制枚举的语法细化（RFC2578第9节）是否允许与TCs一起使用（如上面的示例所示），还是仅允许与基类型一起使用，存在一些争议
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].
整数和位，如RFC2578的严格读数所示。SMIv2文档的编辑和当前的MIB审查人员库的大致共识是，TCs应该允许他们这样做。MIB模块的作者应该知道，一些MIB编译器遵循RFC2578的严格读取，并要求在细化枚举时用其基类型（整数或位）替换TC。这种用法是合法的，可以在一些旧的MIB模块中找到，如IF-MIB[RFC2863]。
RFC 2578 Section 10 specifies general rules that apply any time a MIB module is revised. Specifically:
RFC 2578第10节规定了MIB模块修改时适用的一般规则。明确地：
- The MODULE-IDENTITY invocation MUST be updated to include information about the revision. In particular, the LAST-UPDATED clause value MUST be set to the revision time, a REVISION clause with the same UTC time and an associated DESCRIPTION clause describing the changes MUST be added, and any obsolete information in the existing DESCRIPTION, ORGANIZATION, and CONTACT-INFO clauses MUST be replaced with up-to-date information. See Section 4.5 above for additional requirements that apply to MIB modules that are under IETF change control.
- 必须更新MODULE-IDENTITY调用，以包含有关修订的信息。特别是，必须将上次更新的条款值设置为修订时间，必须添加具有相同UTC时间的修订条款和描述更改的关联描述条款，并且必须使用最新信息替换现有描述、组织和联系人信息条款中的任何过时信息。有关适用于受IETF变更控制的MIB模块的附加要求，请参见上文第4.5节。
- On the other hand, the module name MUST NOT be changed (except to correct typographical errors), existing definitions (even obsolete ones) MUST NOT be removed from the MIB module, and descriptors and OBJECT IDENTIFIER values associated with existing definitions MUST NOT be changed or re-assigned.
- 另一方面，不得更改模块名称（纠正印刷错误除外），不得从MIB模块中删除现有定义（即使是过时的定义），不得更改或重新分配与现有定义关联的描述符和对象标识符值。
It is important to note that the purpose in forbidding certain kinds of changes is to ensure that a revised MIB module is compatible with fielded implementations based on previous versions of the module. There are two distinct aspects of this backward-compatibility requirement. One is "over the wire" compatibility of agent and manager implementations that are based on different revisions of the MIB module. The other is "compilation" compatibility with MIB modules that import definitions from the revised MIB module. The rules forbidding changing or re-assigning OBJECT IDENTIFIER values are necessary to ensure "over the wire" compatibility; the rules against changing module names or descriptors or removing obsolete definitions are necessary to ensure compilation compatibility.
需要注意的是，禁止某些类型更改的目的是确保修改后的MIB模块与基于该模块以前版本的现场实施兼容。这种向后兼容性要求有两个不同的方面。一个是基于MIB模块不同版本的代理和管理器实现的“在线”兼容性。另一个是与从修改后的MIB模块导入定义的MIB模块的“编译”兼容性。禁止更改或重新分配对象标识符值的规则是确保“在线”兼容性所必需的；禁止更改模块名称或描述符或删除过时定义的规则是确保编译兼容性所必需的。
RFC 2578 Section 10.2 specifies rules that apply to revisions of object definitions. The following guidelines correct some errors in these rules and provide some clarifications:
RFC 2578第10.2节规定了适用于对象定义修订的规则。以下指南纠正了这些规则中的一些错误，并提供了一些澄清：
- Bullet (1) allows the labels of named numbers and named bits in SYNTAX clauses of type enumerated INTEGER or BITS to be changed. This can break compilation compatibility, since those labels may be used by DEFVAL clauses in modules that import the definitions of the affected objects. Therefore, labels of named numbers and named bits MUST NOT be changed when revising IETF MIB modules (except to correct typographical errors), and they SHOULD NOT be changed when revising enterprise MIB modules.
- 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）中未明确允许，但一般认为可以将范围约束添加到整数值对象的语法子句中，前提是这些约束只是明确表示对象定义中隐含的一些值约束。最常见的示例是语法为INTEGER或Integer32且没有范围约束的辅助对象。由于不允许辅助对象采用负值，因此添加范围约束（0..2147483647）不可能导致任何“在线”更改，也不会导致与正确写入的MIB模块的编译兼容性问题。评审员应将此类变更视为编辑变更，而不是语义变更。类似地，当范围或大小约束由基础数据类型强制执行时，从对象定义中删除该范围或大小约束应由审阅者视为编辑性更改。
RFC 2578 Section 10.3 specifies rules that apply to revisions of notification definitions. No clarifications or corrections are required.
RFC 2578第10.3节规定了适用于通知定义修订的规则。无需澄清或更正。
RFC 2579 Section 5 specifies rules that apply to revisions of textual convention definitions. The following guideline corrects an error in these rules:
RFC 2579第5节规定了适用于文本约定定义修订的规则。以下指南更正了这些规则中的错误：
- Bullet (1) allows the labels of named numbers and named bits in SYNTAX clauses of type enumerated INTEGER or BITS to be changed. This can break compilation compatibility, since those labels may be used by DEFVAL clauses in modules that import the definitions of the affected TCs. Therefore, labels of named numbers and named bits MUST NOT be changed when revising IETF MIB modules (except to correct typographical errors), and they SHOULD NOT be changed when revising enterprise MIB modules.
- Bullet（1）允许更改枚举整数或位类型语法子句中命名数字和命名位的标签。这可能会破坏编译兼容性，因为导入受影响TC定义的模块中的DEFVAL子句可能会使用这些标签。因此，在修订IETF MIB模块时，不得更改命名数字和命名位的标签（除了纠正印刷错误），在修订企业MIB模块时，也不得更改它们。
RFC 2580 Section 7.1 specifies rules that apply to revisions of conformance groups. Two point are worth reiterating:
RFC 2580第7.1节规定了适用于一致性组修订的规则。有两点值得重申：
- Objects and notifications MUST NOT be added to or removed from an existing object group or notification group. Doing so could cause a compilation failure or (worse) a silent change in the meaning of a compliance statement or capabilities statement that refers to that group.
- 不得将对象和通知添加到现有对象组或通知组或从中删除。这样做可能会导致编译失败或（更糟的是）引用该组的合规性声明或功能声明的含义发生无声更改。
- The status of a conformance group is independent of the status of its members. Thus, a current group MAY refer to deprecated objects or notifications. This may be desirable in certain cases, e.g., a set of widely-deployed objects or notifications may be deprecated when they are replaced by a more up-to-date set of definitions, but the conformance groups that contain them may remain current in order to encourage continued implementation of the deprecated objects and notifications.
- 合规组的状态独立于其成员的状态。因此，当前组可能引用不推荐使用的对象或通知。这在某些情况下可能是可取的，例如，当一组广泛部署的对象或通知被一组更新的定义替换时，它们可能会被弃用，但包含它们的一致性组可能会保持最新，以鼓励继续实施弃用的对象和通知。
RFC 2580 Section 7.2 specifies rules that apply to revisions of compliance statements. The following guidelines correct an omission from these rules and emphasize one important point:
RFC 2580第7.2节规定了适用于合规性声明修订的规则。以下指南纠正了这些规则中的遗漏，并强调了一个要点：
- RFC 2580 should (but does not) recommend that an OBJECT clause specifying support for the original set of values be added to a compliance statement when an enumerated INTEGER object or a BITS object referenced by the compliance statement has enumerations or named bits added, assuming that no such clause is already present and that the effective MIN-ACCESS value is read-write or read-create. This is necessary in order to avoid a silent change to the meaning of the compliance statement. MIB module authors and reviewers SHOULD watch for this to ensure that such OBJECT clauses are added when needed. Note that this may not always be possible to do, since affected compliance statements may reside in modules other than the one that contains the revised definition(s).
- 当符合性语句引用的枚举整数对象或BITS对象添加了枚举或命名位时，RFC 2580应（但不）建议将指定对原始值集支持的OBJECT子句添加到符合性语句中，假设不存在此类子句，且有效的最小访问值为读写或读创建。这是必要的，以避免对合规声明的含义进行无声更改。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
- RFC 2580应（但不）建议在枚举整数对象或位时，将指定对原始值集支持的变体子句添加到capabilities语句中
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.
capabilities语句引用的对象添加了枚举，前提是不存在此类子句。这是必要的，以避免对capabilities语句的含义进行无声更改。
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规则的成本可能超过收益。在这种情况下，可以放弃这些规则，但当这样做时，必须彻底记录变更及其理由。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模块的两个版本之间差异的工具很有帮助。请看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.
关于数据类型使用的大部分材料都是基于伯特·维恩（Bert Wijnen）在基思·麦克洛赫里（Keith McCloghrie）、大卫·T·珀金斯（David T.Perkins）和尤尔根·舍恩瓦尔德（Juergen Schoenwaeld）的协助下提供的输入。关于SMIv2使用的许多其他材料取自Juergen Schoenwaeld为MIB作者和评审员编写的未出版指南。这些指南中的一些建议是基于以下网站的在线SMIv2勘误表中的材料：http://www.ibr.cs.tu-bs.de/ietf/smi-errata/. 感谢Frank Strauss和Juergen Schoenwaeld维护该列表，并感谢为该列表提供材料的贡献者。最后，感谢以下个人，他们对本备忘录早期版本的评论包含了许多宝贵的补充、澄清和更正建议：安迪·比尔曼、鲍勃·布莱登、米歇尔·科顿、大卫·哈林顿、哈里·哈泽文克尔、迪纳卡兰·约瑟夫、迈克尔·科克姆、基思·麦克洛赫里、大卫·T·珀金斯、兰迪·普雷森、，Dan Romascanu、Juergen Schoenwaelder、Frank Strauss、Dave Thaler和Bert Wijnen。
Implementation and deployment of a MIB module in a system may result in security risks that would not otherwise exist. It is important for authors and reviewers of documents that define MIB modules to ensure that those documents fully comply with the guidelines in http://www.ops.ietf.org/mib-security.html so that all such risks are adequately disclosed.
在系统中实现和部署MIB模块可能会导致不存在的安全风险。定义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.
本文档对IANA的影响程度如下：它描述了MIB文档的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样板——验证草稿是否包含所需的Internet草稿样板（参见http://www.ietf.org/ietf/1id-guidelines.txt)，包括允许作为RFC发布的适当声明，以及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区域网站的最新批准的SNMP网络管理框架样板文件(http://www.ops.ietf.org/mib-boilerplate.html).
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区域网站上最新批准的模板(http://www.ops.ietf.org/mib-security.html)并已遵守其中的准则。
5.) IANA Considerations Section -- this section must always be present. If the draft requires no action from the IANA, ensure that this is explicitly noted. If the draft requires OID values to be assigned, ensure that the IANA Considerations section contains the information specified in Section 3.5 of these guidelines. If the draft contains the initial version of an IANA-maintained module, verify that the MODULE-IDENTITY invocation contains maintenance instructions that comply with the requirements in RFC 2434. In the latter case, the IANA Considerations section that will appear in the RFC MUST contain a pointer to the actual IANA-maintained module.
5.）IANA注意事项部分——该部分必须始终存在。如果草案不要求IANA采取行动，请确保明确注明。如果草案要求分配OID值，请确保IANA注意事项部分包含本指南第3.5节中规定的信息。如果草稿包含IANA维护模块的初始版本，请验证模块标识调用是否包含符合RFC 2434要求的维护说明。在后一种情况下，RFC中出现的IANA注意事项部分必须包含指向实际IANA维护模块的指针。
6.) References -- verify that the references are properly divided between normative and informative references, that RFC 2119 is included as a normative reference if the terminology defined therein is used in the document, that all references required by the boilerplate are present, that all MIB modules containing imported items are cited as normative references, and that all citations point to the most current RFCs unless there is a valid reason to do otherwise (for example, it is OK to include an informative reference to a previous version of a specification to help explain a feature included for backward compatibility).
6.）参考文件——验证参考文件正确划分为规范性参考文件和信息性参考文件，如果文件中使用了RFC 2119中定义的术语，则RFC 2119包含为规范性参考文件，且样板文件要求的所有参考文件均存在，包含导入项的所有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.）知识产权通知——如果草案中未包含RFC 3979第5节规定的知识产权通知的逐字副本，建议将知识产权通知包括在内。
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]:
SNMPv2 TC[RFC2579]中定义了以下TC：
DisplayString OCTET STRING (SIZE (0..255)) PhysAddress OCTET STRING MacAddress OCTET STRING (SIZE (6)) TruthValue enumerated INTEGER TestAndIncr INTEGER (0..2147483647) AutonomousType OBJECT IDENTIFIER VariablePointer OBJECT IDENTIFIER RowPointer OBJECT IDENTIFIER RowStatus enumerated INTEGER TimeStamp TimeTicks TimeInterval INTEGER (0..2147483647) DateAndTime OCTET STRING (SIZE (8 | 11)) StorageType enumerated INTEGER TDomain OBJECT IDENTIFIER TAddress OCTET STRING (SIZE (1..255))
DisplayString八进制字符串（大小（0..255））PhysAddress八进制字符串MacAddress八进制字符串（大小（6））TruthValue枚举整数TestAndIncr INTEGER（0..2147483647）自治类型对象标识符变量指针对象标识符行指针对象标识符行状态枚举整数时间戳时间间隔整数（0..2147483647）DateAndTime八位字节字符串（大小（8 | 11））存储类型枚举整数TDomain对象标识符TAddress八位字节字符串（大小（1..255））
Note 1. InstancePointer is obsolete and MUST NOT be used.
注1。InstancePointer已过时，不能使用。
Note 2. DisplayString does not support internationalized text. It MUST NOT be used for objects that are required to hold
附注2。DisplayString不支持国际化文本。不得将其用于需要固定的对象
internationalized text (which is always the case if the object is intended for use by humans [RFC2277]). Designers SHOULD consider using SnmpAdminString, Utf8String, or LongUtf8String for such objects.
国际化文本（如果对象是供人类使用[RFC2277]）。设计人员应该考虑使用SNMPADMIN字符串、UTF8Stand或LoUTF88字符串来处理这些对象。
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和TadAddress不应用于新的MIB模块中。应改用TransportDomain、TransportAddressType和TransportAddress TCs（在TRANSPORT-ADDRESS-MIB[RFC3419]中定义）。
The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411]:
SNMP-FRAMEWORK-MIB[RFC3411]中定义了以下TC：
SnmpAdminString OCTET STRING (SIZE (0..255))
snmpadmin八位字节字符串（大小（0..255））
The following TCs are defined in SYSAPPL-MIB [RFC2287]:
SYSAPPL-MIB[RFC2287]中定义了以下TC：
Utf8String OCTET STRING (SIZE (0..255)) LongUtf8String OCTET STRING (SIZE (0..1024))
Utf8String八位字符串（大小（0..255））长Utf8String八位字符串（大小（0..1024））
The following TCs are defined in INET-ADDRESS-MIB [RFC4001]:
INET-ADDRESS-MIB[RFC4001]中定义了以下TC：
InetAddressType enumerated INTEGER InetAddress OCTET STRING (SIZE (0..255)) InetAddressPrefixLength Unsigned32 (0..2040) InetPortNumber Unsigned32 (0..65535)) InetAutonomousSystemNumber Unsigned32 InetScopeType enumerated INTEGER InetZoneIndex Unsigned32 InetVersion enumerated INTEGER
InetAddressType枚举整数InetAddress八位字节字符串（大小（0..255））inetAddressPrefixeLength Unsigned32（0..2040）InetPortNumber Unsigned32（0..65535））InetAutonomousSystemNumber Unsigned32 InetScopeType枚举整数InetZoneIndex Unsigned32 InetVersion枚举整数
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))
TransportDomain对象标识符TransportAddressType枚举整数TransportAddress八位字节字符串（大小（0..255））
The following TC is defined in RMON2-MIB [RFC2021]:
RMON2-MIB[RFC2021]中定义了以下TC：
ZeroBasedCounter32 Gauge32
零基计数器32仪表32
The following TCs are defined in HCNUM-TC [RFC2856]:
HCNUM-TC[RFC2856]中定义了以下TC：
ZeroBasedCounter64 Counter64 CounterBasedGauge64 Counter64
ZeroBasedCounter64计数器64计数器BasedGauge64计数器64
The following TCs are defined in IF-MIB [RFC2863]:
IF-MIB[RFC2863]中定义了以下TC：
InterfaceIndex Integer32 (1..2147483647)
接口索引整数32（1..2147483647）
InterfaceIndexOrZero Integer32 (0..2147483647)
接口索引或零整数32（0..2147483647）
The following TCs are defined in ENTITY-MIB [RFC4133]:
以下TC在ENTITY-MIB[RFC4133]中定义：
PhysicalIndex Integer32 (1..2147483647) PhysicalIndexOrZero Integer32 (0..2147483647)
物理索引整数32（1..2147483647）物理索引或零整数32（0..2147483647）
The following TCs are defined in PerfHist-TC-MIB [RFC3593]:
性能历史TC MIB[RFC3593]中定义了以下TC：
PerfCurrentCount Gauge32 PerfIntervalCount Gauge32 PerfTotalCount Gauge32
PerfCurrentCount量表32 PerfIntervalCount量表32 PerfTotalCount量表32
The following TCs are defined in HC-PerfHist-TC-MIB [RFC3705]:
HC性能历史TC MIB[RFC3705]中定义了以下TC：
HCPerfValidIntervals Integer32 (0..96) HCPerfInvalidIntervals Integer32 (0..96) HCPerfTimeElapsed Integer32 (0..86399) HCPerfIntervalThreshold Unsigned32 (0..900) HCPerfCurrentCount Counter64 HCPerfIntervalCount Counter64 HCPerfTotalCount Counter64
HCPerfValidIntervals Integer32（0..96）HCPerfValidIntervals Integer32（0..96）HCPerfTimeAppeased Integer32（0..86399）HCPerfIntervalThreshold Unsigned32（0..900）HCPerfCurrentCount计数器64 HCPerfIntervalCount计数器64 HCPerfTotalCount计数器64
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（或XXX-TC-MIB，仅适用于带有TCs的模块），其中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.
- 与MODULE-IDENTITY调用相关联的描述符的格式应为xxxMIB、xxxMIB或xxxMibModule，其中xxx是xxx的混合大小写版本，以小写字母开头，不带任何连字符。例如，OPT-IF-MIB使用前缀optIf，并且与其MODULE-IDENTITY调用关联的描述符是optIfMibModule。
- Other descriptors within the MIB module should start with the same prefix xxx. OPT-IF-MIB uses the prefix optIf for all descriptors.
- MIB模块中的其他描述符应以相同的前缀xxx开头。OPT-IF-MIB对所有描述符使用前缀optIf。
- Names of TCs that are specific to the MIB module and names of SEQUENCE types that are used in conceptual table definitions should start with a prefix Xxx that is the same as xxx but with the initial letter changed to uppercase. OPT-IF-MIB uses the prefix OptIf on the names of TCs and SEQUENCE types.
- MIB模块特定的TC名称和概念表定义中使用的序列类型名称应以前缀Xxx开头，前缀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.
- 与概念表关联的描述符应为XXXZZTABLE形式；与相应概念行关联的描述符的形式应为xxxZzzEntry；关联序列类型的名称应为XxxZzzEntry格式；与从属列对象关联的描述符的形式应为xxxZzzSomeotherName。OPT-IF-MIB的一个例子是OTMn表。表对象的描述符是optiftmentable，行对象的描述符是optiftmentry，关联序列类型的名称是optiftmentry，列对象的描述符是optiftmnorder、optiftmnreduced、optiftmnbritates、optiftmninterfacetype、optiftmntcmmax和optiftmnopticalreach。
- When abbreviations are used, then they should be used consistently. Inconsistent usage such as
- 使用缩略语时，应始终如一地使用。不一致的用法，例如
xxxYyyDestAddr xxxZzzDstAddr
xxxYyyDestAddr XXXZZDSTADDR
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是如何在子树中分配的。一个备受青睐的分配方案——除非有特殊原因不使用它，否则建议使用它——是在模块标识值的正下方有三个单独的分支，分别用于通知定义、对象定义和一致性定义，并将合规性分支进一步细分为合规性声明和对象/通知组的独立分支。该结构如下图所示，命名约定遵循附录C中概述的命名约定。括号中的数字是分配给分支的子标识符。
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)
xxxMIB
|
+-- xxxNotifications(0)
+-- xxxObjects(1)
+-- xxxConformance(2)
|
+-- xxxCompliances(1)
+-- xxxGroups(2)
When using this scheme, notification definition values are assigned immediately below the xxxNotifications node. This ensures that each OID assigned to a notification definition has a next-to-last sub-identifier of zero, which is REQUIRED by Section 4.7 above. The other sub-branches may have additional sub-structure, but none beyond that specified in Section 4.6.5 above is actually required.
使用此方案时，通知定义值将分配到xxxNotifications节点的正下方。这确保分配给通知定义的每个OID都有一个上一个子标识符零，这是上面第4.7节所要求的。其他支行可能有额外的子结构，但实际上不需要超过上述第4.6.5节规定的子结构。
One example of a MIB module whose OID assignments follow this scheme is the POWER-ETHERNET-MIB [RFC3621].
其OID分配遵循此方案的MIB模块的一个示例是POWER-ETHERNET-MIB[RFC3621]。
Normative References
规范性引用文件
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，Schoenwaeld，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.，Schoenwaeld，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.，Schoenwaeld，J.，Case，J.，Rose，M.，和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年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，“接口组MIB”，RFC 28632000年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.Schoenwaeld，“互联网网络地址的文本约定”，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.，“使用SMIv2的远程网络监控管理信息库版本2”，RFC 20211997年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.Presohn，“附加高容量数据类型的文本约定”，RFC 28562000年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.，Presohn，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]Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.，和S.Waldbusser，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.，和S.Waldbusser，“简单网络管理协议（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，“实体MIB（版本3）”，RFC 41332005年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.Schoenwaeld，“运输地址的文本约定”，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，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215]Rose，M.，“定义用于SNMP的陷阱的约定”，RFC1215，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 34102002年12月。
[RFC2932] McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4 Multicast Routing MIB", RFC 2932, October 2000.
[RFC2932]McCloghrie，K.，Farinaci，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，“电力以太网MIB”，RFC 36212003年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.，Romascan，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 15951994年3月。
[RFC2558] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", RFC 2558, March 1999.
[RFC2558]Tesink，K.“SONET/SDH接口类型的受管对象定义”，RFC2558，1999年3月。
[RFC3591] Lam, H-K., Stewart, M., and A. Huynh, "Definitions of Managed Objects for the Optical Interface Type", RFC 3591, September 2003.
[RFC3591]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
美国加利福尼亚州帕萨迪纳市南麦迪逊大道158号，邮编：91101-2569
Phone: +1 626 795 5311
EMail: heard@pobox.com
Phone: +1 626 795 5311
EMail: heard@pobox.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。