Network Working Group C. Elliott
Request for Comments: 3216 Cisco Systems
Category: Informational D. Harrington
Enterasys Networks
J. Jason
Intel Corporation
J. Schoenwaelder
F. Strauss
TU Braunschweig
W. Weiss
Ellacoya Networks
December 2001
Network Working Group C. Elliott
Request for Comments: 3216 Cisco Systems
Category: Informational D. Harrington
Enterasys Networks
J. Jason
Intel Corporation
J. Schoenwaelder
F. Strauss
TU Braunschweig
W. Weiss
Ellacoya Networks
December 2001
SMIng Objectives
射击目标
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.
本文档描述了一种新的数据定义语言的目标，该语言适用于网络管理结构的建模，可直接映射到SNMP和COPS-PR协议操作中。
The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives.
本文档的目的是作为一组目标，后续语言规范应尝试解决这些目标。它记录了工作组为就SMIng目标达成共识而进行的讨论的结果。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specific Objectives for SMIng . . . . . . . . . . . . . . 4
4.1 Accepted Objectives . . . . . . . . . . . . . . . . . . . 5
4.1.1 The Set of Specification Documents . . . . . . . . . . . . 6
4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 6
4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specific Objectives for SMIng . . . . . . . . . . . . . . 4
4.1 Accepted Objectives . . . . . . . . . . . . . . . . . . . 5
4.1.1 The Set of Specification Documents . . . . . . . . . . . . 6
4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 6
4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 6
4.1.4 Rigorously Defined Syntax . . . . . . . . . . . . . . . . 6
4.1.5 Accessibility . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6 Language Extensibility . . . . . . . . . . . . . . . . . . 7
4.1.7 Special Characters in Text . . . . . . . . . . . . . . . . 7
4.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.9 Namespace Control . . . . . . . . . . . . . . . . . . . . 8
4.1.10 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . . 9
4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . . 9
4.1.13 Protocol Independence . . . . . . . . . . . . . . . . . . 9
4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . 10
4.1.15 Translation to Other Data Definition Languages . . . . . . 10
4.1.16 Base Data Types . . . . . . . . . . . . . . . . . . . . . 10
4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . . 11
4.1.19 Instance Pointers . . . . . . . . . . . . . . . . . . . . 11
4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.21 Constraints on Pointers . . . . . . . . . . . . . . . . . 12
4.1.22 Base Type Set . . . . . . . . . . . . . . . . . . . . . . 12
4.1.23 Extended Data Types . . . . . . . . . . . . . . . . . . . 12
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.25 Table Existence Relationships . . . . . . . . . . . . . . 13
4.1.26 Table Existence Relationships (2) . . . . . . . . . . . . 14
4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . . 14
4.1.28 Containment . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.30 Reusable vs. Final Attribute Groups . . . . . . . . . . . 15
4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.32 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.35 Extension Rules . . . . . . . . . . . . . . . . . . . . . 17
4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 17
4.1.37 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.39 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . . 19
4.1.42 Instance Naming . . . . . . . . . . . . . . . . . . . . . 19
4.1.43 Length of Identifiers . . . . . . . . . . . . . . . . . . 19
4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . . 20
4.2 Nice-to-Have Objectives . . . . . . . . . . . . . . . . . 20
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Float Data Types . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.4 Rigorously Defined Syntax . . . . . . . . . . . . . . . . 6
4.1.5 Accessibility . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6 Language Extensibility . . . . . . . . . . . . . . . . . . 7
4.1.7 Special Characters in Text . . . . . . . . . . . . . . . . 7
4.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.9 Namespace Control . . . . . . . . . . . . . . . . . . . . 8
4.1.10 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . . 9
4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . . 9
4.1.13 Protocol Independence . . . . . . . . . . . . . . . . . . 9
4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . 10
4.1.15 Translation to Other Data Definition Languages . . . . . . 10
4.1.16 Base Data Types . . . . . . . . . . . . . . . . . . . . . 10
4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . . 11
4.1.19 Instance Pointers . . . . . . . . . . . . . . . . . . . . 11
4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.21 Constraints on Pointers . . . . . . . . . . . . . . . . . 12
4.1.22 Base Type Set . . . . . . . . . . . . . . . . . . . . . . 12
4.1.23 Extended Data Types . . . . . . . . . . . . . . . . . . . 12
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.25 Table Existence Relationships . . . . . . . . . . . . . . 13
4.1.26 Table Existence Relationships (2) . . . . . . . . . . . . 14
4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . . 14
4.1.28 Containment . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.30 Reusable vs. Final Attribute Groups . . . . . . . . . . . 15
4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.32 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.35 Extension Rules . . . . . . . . . . . . . . . . . . . . . 17
4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 17
4.1.37 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.39 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . . 19
4.1.42 Instance Naming . . . . . . . . . . . . . . . . . . . . . 19
4.1.43 Length of Identifiers . . . . . . . . . . . . . . . . . . 19
4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . . 20
4.2 Nice-to-Have Objectives . . . . . . . . . . . . . . . . . 20
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Float Data Types . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.5 Referencing Tagged Rows . . . . . . . . . . . . . . . . . 22
4.2.6 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7 Internationalization . . . . . . . . . . . . . . . . . . . 23
4.2.8 Separate Data Modelling from Management Protocol Mapping . 23
4.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24
4.3.1 Incomplete Translations . . . . . . . . . . . . . . . . . 24
4.3.2 Attribute Value Constraints . . . . . . . . . . . . . . . 24
4.3.3 Attribute Transaction Constraints . . . . . . . . . . . . 25
4.3.4 Method Constraints . . . . . . . . . . . . . . . . . . . . 25
4.3.5 Agent Capabilities . . . . . . . . . . . . . . . . . . . . 25
4.3.6 Relationships . . . . . . . . . . . . . . . . . . . . . . 26
4.3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.8 Associations . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.9 Association Cardinalities . . . . . . . . . . . . . . . . 27
4.3.10 Categories of Modules . . . . . . . . . . . . . . . . . . 27
4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . . 27
4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . 28
4.3.13 Place of Module Information . . . . . . . . . . . . . . . 28
4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . . 29
4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . 30
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 33
4.2.5 Referencing Tagged Rows . . . . . . . . . . . . . . . . . 22
4.2.6 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7 Internationalization . . . . . . . . . . . . . . . . . . . 23
4.2.8 Separate Data Modelling from Management Protocol Mapping . 23
4.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24
4.3.1 Incomplete Translations . . . . . . . . . . . . . . . . . 24
4.3.2 Attribute Value Constraints . . . . . . . . . . . . . . . 24
4.3.3 Attribute Transaction Constraints . . . . . . . . . . . . 25
4.3.4 Method Constraints . . . . . . . . . . . . . . . . . . . . 25
4.3.5 Agent Capabilities . . . . . . . . . . . . . . . . . . . . 25
4.3.6 Relationships . . . . . . . . . . . . . . . . . . . . . . 26
4.3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.8 Associations . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.9 Association Cardinalities . . . . . . . . . . . . . . . . 27
4.3.10 Categories of Modules . . . . . . . . . . . . . . . . . . 27
4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . . 27
4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . 28
4.3.13 Place of Module Information . . . . . . . . . . . . . . . 28
4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . . 29
4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . 30
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 33
This document describes the objectives for a new data definition language that can be mapped into SNMP [1], [2] and COPS-PR [3] protocol operations. It may also be translated into SMIv2 [4], [5], [6] MIBs and SPPI [7] PIBs. Concepts such as attributes, attribute groups, methods, conventions for organization into reusable data structures, and mechanisms for representing relationships are discussed.
本文档描述了可映射到SNMP[1]、[2]和COPS-PR[3]协议操作的新数据定义语言的目标。还可以将其翻译为SMIv2[4]、[5]、[6]MIB和SPPI[7]PIB。讨论了属性、属性组、方法、组织为可重用数据结构的约定以及表示关系的机制等概念。
As networking technology has evolved, a diverse set of technologies has been deployed to manage the resulting products. These vary from Web based products, to standard management protocols and text scripts. The underlying systems to be manipulated are represented in varying ways including implicitly in the system programming, via proprietary data descriptions, or with standardized descriptions using a range of technologies including MIBs, PIBs, or LDAP schemas. The result is that management interfaces for network protocols, services, and applications such as Differentiated Services may be represented in many different, inconsistent fashions.
随着网络技术的发展，已经部署了一组不同的技术来管理生成的产品。从基于Web的产品到标准管理协议和文本脚本，这些都有所不同。要操作的底层系统以不同的方式表示，包括通过专有数据描述隐式地在系统编程中表示，或使用包括MIB、PIB或LDAP模式在内的一系列技术的标准化描述。结果是，网络协议、服务和应用程序（如区分服务）的管理接口可能以许多不同的、不一致的方式表示。
The SMIng working group has been chartered to define a new data definition language that will eliminate the need for a separate SMIv2 and SPPI language. That is, the new language should address the needs for the current SMIv2 and SPPI languages so that over time we can all use the new language instead.
SMIng工作组被授权定义一种新的数据定义语言，它将消除对单独的SMIv2和SPPI语言的需要。也就是说，新语言应该满足当前SMIv2和SPPI语言的需求，以便随着时间的推移，我们都可以使用新语言。
Another motivation is to permit a more expressive and complete representation of the modeled information. Examples of additional expressiveness and completeness that are considered are the ability to formally define table existence relationships, the expression of instance creation/deletion capabilities, and the ability to define attribute groups using inheritance. These additional features are discussed in subsequent sections.
另一个动机是允许对建模信息进行更具表现力和完整的表示。需要考虑的其他表现力和完整性的示例包括正式定义表存在关系的能力、实例创建/删除能力的表达以及使用继承定义属性组的能力。这些附加功能将在后续章节中讨论。
It has been recognized that the two main goals of (a) merging SMIv2/SPPI and (b) enhancing the state of art in network management data modeling can lead to conflicts. In such cases, the SMIng working group's consensus is to focus on enhancing the state of art in network management data modeling.
人们已经认识到，（a）合并SMIv2/SPPI和（b）提高网络管理数据建模的技术水平这两个主要目标可能会导致冲突。在这种情况下，SMIng工作组的共识是将重点放在提高网络管理数据建模的技术水平上。
The Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) has researched the issues of creating a protocol-independent data definition language that could be used by multiple protocols. Because SMIv2 and SPPI are very similar, the NMRG focused on merging these two languages, but also researched ways to abstract the objectives to produce a language that could be used for other protocols, such as LDAP and Diameter. The NMRG has published the results of their work in a meanwhile expired Internet Draft, but has submitted their specification as one proposal to consider in the development of the SMIng language.
互联网研究任务组（IRTF）的网络管理研究小组（NMRG）研究了创建可由多个协议使用的协议独立数据定义语言的问题。由于SMIv2和SPPI非常相似，NMRG专注于合并这两种语言，但也研究了如何抽象目标，以生成一种可用于其他协议（如LDAP和Diameter）的语言。NMRG已经在一份期满的互联网草案中公布了他们的工作成果，但是提交了他们的规范作为SIMIN语言开发中的一个建议。
The SMIng Working Group has accepted their submission for consideration, and to use their proposal to better understand the objectives and possible obstacles to be overcome. Where useful, the NMRG proposal has been referenced in the details below.
SMIng工作组已接受其提交文件供审议，并将利用其提案更好地了解目标和可能需要克服的障碍。在有用的情况下，NMRG提案已在以下详细信息中引用。
The following sections define the objectives for the definition of a new data definition language. The objectives have been organized as follows: accepted objectives (Section 4.1), nice-to-have objectives (Section 4.2), and rejected objectives (Section 4.3). Each objective has the following information:
以下各节定义了新数据定义语言的定义目标。目标组织如下：接受的目标（第4.1节）、好客的目标（第4.2节）和拒绝的目标（第4.3节）。每个目标都有以下信息：
o Type: a field that identifies the type of objective, using one of the following values:
o 类型：使用以下值之一标识目标类型的字段：
* basic: considered a basic objective for SMIng and is contained in SMIv2 and/or SPPI.
* 基本：被认为是SMIng的基本目标，包含在SMIv2和/或SPPI中。
* align: supported in different ways in SMIv2 and SPPI and they must be aligned.
* 对齐：在SMIv2和SPPI中以不同的方式支持，它们必须对齐。
* fix: considered a fix for a known problem in SMIv2 and/or SPPI.
* 修复：考虑修复SMIv2和/或SPPI中的已知问题。
* new: considered a new feature.
* 新：被认为是一个新特性。
o From: a field that defines the origin of the objective and that contains one or more of the following values:
o From：定义目标原点并包含以下一个或多个值的字段：
* SMI: exists in SMIv2.
* SMI:存在于SMIv2中。
* SPPI: exists in SPPI.
* SPPI：存在于SPPI中。
* NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.
* NMRG：存在于NMRG方案中，但不存在于SMIv2或SPPI中。
* Charter: exists in working group charter.
* 章程：存在于工作组章程中。
* WG: proposed during working group discussions.
* 工作组：在工作组讨论期间提出。
o Description: a quick description of the objective.
o 描述：对目标的快速描述。
o Motivation: rationale for the objective.
o 动机：目标的基本原理。
o Notes: optional notes about an objective. For example, for nice-to-have or rejected this may contain reasoning why this objective is not required by the SMIng working group, but justification why it should be considered anyway. Notes may be the opinions of the participants in the discussion on objectives and as such should not be taken as consensus of the working group or the recommendation of the objectives editing team.
o 备注：关于目标的可选备注。例如，对于nice to have或REJECT而言，这可能包含SMIng工作组不要求该目标的理由，但也可能包含无论如何都应考虑该目标的理由。注释可能是关于目标讨论的参与者的意见，因此不应被视为工作组的共识或目标编辑小组的建议。
This section represents the list of objectives that have been accepted by the SMIng working group as worthwhile and therefore deserving of further consideration. Each of these objectives must be evaluated by the working group to determine if the benefit incurs an acceptable level of cost. An accepted objective may subsequently be rejected if the cost/benefit analysis determines that the benefit does not justify the cost or that the objective is in direct conflict with one or more other accepted objectives that are deemed more important.
本节列出了SMIng工作组认为值得进一步考虑的目标清单。工作组必须对这些目标中的每一个进行评估，以确定效益是否产生了可接受的成本水平。如果成本/效益分析确定效益不能证明成本合理，或该目标与一个或多个被认为更重要的其他公认目标直接冲突，则可拒绝接受的目标。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: SMIv2 is defined in three documents, based on an obsolete ITU ASN.1 specification. SPPI is defined in one document, based on SMIv2. The core of SMIng must be defined in one document and must be independent of external specifications.
描述：SMIv2在三个文档中定义，基于过时的ITU ASN.1规范。SPPI在一个基于SMIv2的文档中定义。SMIng的核心必须在一个文档中定义，并且必须独立于外部规范。
Motivation: Self-containment.
动机：自我遏制。
Type: basic
类型：基本型
From: SMI, SPPI, WG
发件人：SMI、SPPI、WG
Description: SMIng definitions must be represented in a textual format.
说明：SMIng定义必须以文本格式表示。
Motivation: General IETF consensus.
动机：IETF普遍共识。
Type: basic
类型：基本型
From: WG
发件人：WG
Description: The syntax must make it easy for humans to directly read and write SMIng modules. It must be possible for SMIng module authors to produce SMIng modules with text editing tools.
描述：语法必须使人们能够轻松地直接读取和写入SMIng模块。SMIng模块的作者必须能够使用文本编辑工具生成SMIng模块。
Motivation: The syntax must make it easy for humans to read and write SMIng modules.
动机：语法必须使人们能够轻松地读写SMIng模块。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: There must be a rigorously defined syntax for the SMIng language.
描述：SMIng语言必须有严格定义的语法。
Motivation: An unambiguous language promotes consistency across vendors so that different parsers produce the same results. It also provides authoritative rules to SMIng modules designers.
动机：明确的语言促进了供应商之间的一致性，以便不同的解析器产生相同的结果。它还为SMIng模块设计者提供了权威规则。
Type: align
类型：对齐
From: SMI, SPPI
发件人：SMI，SPPI
Description: Attribute definitions must indicate whether attributes can be read, written, created, deleted, and whether they are accessible for notifications, or are not accessible. Align PIB-ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
描述：属性定义必须指明属性是否可以读取、写入、创建、删除，以及它们是否可用于通知或不可访问。对齐PIB-ACCESS和MAX-ACCESS，以及PIB-MIN-ACCESS和MIN-ACCESS。
Motivation: Alignment of SMIv2 and SPPI.
动机：SMIv2和SPPI的对齐。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: The language must have characteristics, so that future modules can contain information of future syntax without breaking original SMIng parsers.
描述：该语言必须具有特性，以便将来的模块可以包含将来语法的信息，而不破坏原始的SMIng解析器。
E.g., when SMIv2 introduced REFERENCEs it would have been nice if it would not have broken SMIv1 parsers.
例如，当SMIv2引入引用时，如果它没有破坏SMIv1解析器，那就太好了。
Motivation: Achieve language extensibility without breaking core compatibility.
动机：在不破坏核心兼容性的情况下实现语言可扩展性。
Type: new
类型：新
From: WG
发件人：WG
Description: Allow an escaping mechanism to encode special characters, e.g. double quotes and new-line characters, in text such as DESCRIPTIONs or REFERENCEs.
描述：允许转义机制在描述或引用等文本中编码特殊字符，例如双引号和新行字符。
Motivation: ABNF can contain literal characters enclosed in double quotes; to provide the ABNF grammar, there must be the ability to escape special characters.
动机：ABNF可以包含用双引号括起来的文字字符；要提供ABNF语法，必须能够转义特殊字符。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide mechanisms to uniquely identify attributes, groups of attributes, and events. It is necessary to specify how name collisions are handled.
描述：SMIng必须提供唯一标识属性、属性组和事件的机制。有必要指定如何处理名称冲突。
Motivation: Already in SMIv2 and SPPI.
动机：已在SMIv2和SPPI中。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: There must be a hierarchical, centrally-controlled namespace for standard named items, and a distributed namespace must be supported to allow vendor-specific naming and to assure unique module names across vendors and organizations.
描述：标准命名项必须有一个分层的、集中控制的名称空间，并且必须支持分布式名称空间，以允许特定于供应商的命名，并确保跨供应商和组织的唯一模块名称。
Motivation: Need to unambiguously identify definitions of various kinds. Some SMI implementations have problems with different objects from multiple modules but with the same name. Furthermore, the probability of module name clashes rises over time (for example, different vendors defining their own SYSTEM-MIB).
动机：需要明确确定各种定义。一些SMI实现在使用来自多个模块但名称相同的不同对象时存在问题。此外，模块名称冲突的概率随着时间的推移而增加（例如，不同的供应商定义自己的SYSTEM-MIB）。
Notes: An example naming scheme is the one employed by the Java programming language with a central naming authority assigning the top-level names.
注：示例命名方案是Java编程语言使用的一种命名方案，中央命名机构分配顶级名称。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide a mechanism for uniquely identifying a module, and specifying the status, contact person, revision information, and the purpose of a module.
描述：SMIng必须提供一种机制来唯一标识模块，并指定模块的状态、联系人、修订信息和用途。
SMIng must provide mechanisms to group definitions into modules and it must provide rules for referencing definitions from other modules.
SMIng必须提供将定义分组到模块中的机制，并且必须提供引用其他模块定义的规则。
Motivation: Modularity and independent advancement of documents.
动机：文档的模块化和独立推进。
Notes: Text about module conformance has been moved to Section 4.1.11.
注：关于模块一致性的文本已移至第4.1.11节。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide mechanisms to detail the minimum requirements implementers must meet to claim conformance to a standard based on the module.
描述：SMIng必须提供机制，详细说明实现者必须满足的最低要求，以声明符合基于模块的标准。
Motivation: Ability to convey conformance requirements.
动机：传达合规性要求的能力。
Type: basic
类型：基本型
From: SMI
发件人：SMI
Description: SMI allows the use of OBJECT-IDENTITIES to define unambiguous identities without the need of a central registry. SMI uses OIDs to represent values that represent references to such identities. SMIng needs a similar mechanism (a statement to register identities, and a base type to represent values).
描述：SMI允许使用对象标识定义明确的标识，而无需中央注册表。SMI使用OID表示表示此类标识引用的值。SMIng需要类似的机制（一个用于注册标识的语句，以及一个表示值的基类型）。
Motivation: SMI Compatibility.
动机：SMI兼容性。
Notes: This is an obvious objective. Additionally, everything not on the wire, such as modules, will still be assigned OIDs.
注：这是一个明显的目标。此外，非在线的所有内容（如模块）仍将分配OID。
It is yet to be determined whether the assignment of the OID occurs within the core or within a protocol-specific mapping.
OID的分配是发生在核心内还是发生在特定于协议的映射内尚待确定。
Type: basic
类型：基本型
From: Charter
发件人：Charter
Description: SMIng must define data definitions in support of the SNMP and COPS-PR protocols. SMIng may define data definitions in support of other protocols.
说明：SMIng必须定义支持SNMP和COPS-PR协议的数据定义。SMIng可以定义数据定义以支持其他协议。
Motivation: So data definitions may be used with multiple protocols and multiple versions of those protocols.
动机：因此数据定义可以与多个协议以及这些协议的多个版本一起使用。
Type: basic
类型：基本型
From: Charter
发件人：Charter
Description: The SMIng working group, in accordance with the working group charter, will define mappings of protocol independent data definitions to protocols based upon installed implementations. The SMIng working group can define mappings to other protocols as long as this does not impede the progress on other objectives.
说明：根据工作组章程，SMIng工作组将根据已安装的实现定义协议独立数据定义到协议的映射。SMIng工作组可以定义到其他协议的映射，只要这不妨碍其他目标的进展。
Motivation: SMIng working group charter.
动机：斯明工作组章程。
Type: basic
类型：基本型
From: Charter
发件人：Charter
Description: SMIng language constructs must, wherever possible, be translatable to SMIv2 and SPPI. At the time of standardization of a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the standards track will not be required to be translated to the SMIng language. New MIBs/PIBs will be defined using the SMIng language.
描述：SMIng语言结构必须尽可能可翻译为SMIv2和SPPI。在标准化SMIng语言时，标准轨道上的现有SMIv2 MIB和SPPI PIB将不需要翻译为SMIng语言。将使用SMIng语言定义新的MIB/PIB。
Motivation: Provide best-effort backwards compatibility for existing tools while not placing an unnecessary burden on MIBs/PIBs that are already on the standards track.
动机：尽最大努力为现有工具提供向后兼容性，同时不会给已经进入标准轨道的MIB/PIB带来不必要的负担。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must support the base data types Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString, and OID.
说明：SMIng必须支持基本数据类型Integer32、Unsigned32、Integer64、Unsigned64、枚举、位、八位字符串和OID。
Motivation: Most are already common. Unsigned64 and Integer64 are in SPPI, must fix in SMI. Note that Counter and Gauge types can be regarded as derived types instead of base types.
动机：大多数已经很普遍了。Unsigned64和Integer64在SPPI中，必须在SMI中修复。请注意，计数器和仪表类型可以视为派生类型，而不是基本类型。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide support for enumerations. Enumerated values must be a part of the enumeration definition.
描述：SMIng必须提供对枚举的支持。枚举值必须是枚举定义的一部分。
Motivation: SMIv2 already has enumerated numbers.
动机：SMIv2已经有枚举数。
Notes: Enumerations have the implicit constraint that the attribute is constrained to the values for the enumeration.
注意：枚举具有隐式约束，即属性约束为枚举的值。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng must support discriminated unions.
描述：SMIng必须支持有区别的联合。
Motivation: Allows to group related attributes together, such as InetAddressType (discriminator) and InetAddress, InetAddressIPv4, InetAddressIPv6 (union). The lack of discriminated unions has also lead to relatively complex sparse table work-around in some DISMAN mid-level manager MIBs.
动机：允许将相关属性分组在一起，例如InetAddressType（鉴别器）和InetAddress、InetAddressIPv4、InetAddressIPv6（联合）。缺少歧视性的联合也导致了一些Deman中级管理器MIB中相对复杂的稀疏表工作。
Notes: Discriminated unions have the property that the union attribute type is constrained by the value of the discriminator attribute.
注意：区分的联合具有联合属性类型受鉴别器属性值约束的特性。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must allow specifying pointers to instances (i.e., a pointer to a particular attribute in a row).
描述：SMIng必须允许指定指向实例的指针（即指向行中特定属性的指针）。
Motivation: It is common practice in MIBs and PIBs to point to other instances.
动机：在MIB和PIB中，指向其他实例是常见的做法。
Type: align
类型：对齐
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must allow specifying pointers to rows.
描述：SMIng必须允许指定指向行的指针。
Motivation: It is common practice in MIBs and PIBs to point to other rows (see RowPointer, PIB-REFERENCES).
动机：在MIB和PIB中，指向其他行是常见的做法（请参阅RowPointer，PIB-REFERENCES）。
Type: align
类型：对齐
From: SPPI
发件人：SPPI
Description: SMIng must allow specifying the types of objects to which a pointer may point.
描述：SMIng必须允许指定指针可能指向的对象类型。
Motivation: Allows code generators to detect and reject illegal pointers automatically. Can also be used to automatically generate more reasonable implementation-specific data structures.
动机：允许代码生成器自动检测和拒绝非法指针。还可以用于自动生成更合理的特定于实现的数据结构。
Notes: Pointer constraints are a special case of attribute value constraints (Section 4.3.2) in which the prefix of the OID (row or instance pointer) value is limited to be only from a particular table.
注：指针约束是属性值约束的一种特殊情况（第4.3.2节），其中OID（行或实例指针）值的前缀仅限于来自特定表。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must support a fixed set of base types of fixed size and precision. The list of base types must not be extensible unless the SMI itself changes.
说明：SMIng必须支持一组固定大小和精度的基本类型。除非SMI本身发生更改，否则基类型列表不能扩展。
Motivation: Interoperability.
动机：互操作性。
Type: align
类型：对齐
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must support a mechanism to derive new types, which provide additional semantics (e.g., Counters, Gauges, Strings, etc.), from base types. It may be desirable to also allow the derivation of new types from derived types. New types must be as restrictive or more restrictive than the types that they are specializing.
描述：SMIng必须支持从基类型派生新类型的机制，该机制提供额外的语义（例如计数器、仪表、字符串等）。可能还需要允许从派生类型派生新类型。新类型的限制性必须与它们所专门化的类型相同或更严格。
Motivation: SMI uses application types and textual conventions. SPPI uses derived types.
动机：SMI使用应用程序类型和文本约定。SPPI使用派生类型。
4.1.24 Units, Formats, and Default Values of Defined Types and Attributes
4.1.24 已定义类型和属性的单位、格式和默认值
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS and DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs. In a similar fashion units and default values must be applicable to defined types and format information must be applicable to attributes.
描述：在SMIv2中，对象类型定义可能包含单位和定义子句，文本约定可能包含显示提示。同样，单位和默认值必须适用于定义的类型，格式信息必须适用于属性。
Motivation: Some MIBs introduce TCs such as KBytes and every usage of the TC then specifies the UNITS "KBytes". It would simplify things if the UNITS were attached to the type definition itself.
动机：一些MIB引入了TCs，比如KB，每次使用TCs都会指定单位“KB”。如果将单元附加到类型定义本身，则可以简化工作。
Notes: The SMIng WG must clarify the behavior if an attribute uses a defined type and both, the attribute and the defined type, have units/default/format information.
注意：如果属性使用定义的类型，并且属性和定义的类型都具有单位/默认值/格式信息，则SMIng工作组必须澄清该行为。
Type: align
类型：对齐
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the SNMP/COPS-PR protocol mappings.
描述：SMIng必须支持SNMP/COPS-PR协议映射中的索引、扩充和扩展。
Motivation: These three table existence relationships exist either in the SMIv2 or the SPPI.
动机：这三种表存在关系存在于SMIv2或SPPI中。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: SMIng must support EXPANDS and REORDERS relationships in the SNMP/COPS-PR protocol mappings.
说明：SMIng必须支持SNMP/COPS-PR协议映射中的扩展和重新排序关系。
Motivation: A REORDERS statement allows indexing orders to be swapped. An EXPANDS statement formally states that there is a 1:n existence relationship between table rows.
动机：REORDERS语句允许交换索引顺序。expanses语句正式声明表行之间存在1:n的存在关系。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: An attribute group is a named, reusable set of attributes that are meaningful together. It can be reused as the type of attributes in other attribute groups (see also Section 4.1.28). This is similar to `structs' in C.
描述：属性组是一组命名的、可重用的、有意义的属性集。它可以作为其他属性组中的属性类型重用（另请参见第4.1.28节）。这类似于C中的“structs”。
Motivation: Required to map the same grouping of attributes into SNMP and COPS-PR tables. Allows to do index reordering without having to redefine the attribute group. Allows to group related attributes together (e.g. InetAddressType, InetAddress).
动机：需要将相同的属性分组映射到SNMP和COPS-PR表中。允许执行索引重新排序，而无需重新定义属性组。允许将相关属性分组在一起（例如InetAddressType、InetAddress）。
The ability to group attributes provides an indication that the attributes are meaningful together.
对属性进行分组的能力表明这些属性在一起是有意义的。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: SMIng must provide support for the creation of new attribute groups from attributes of more basic types and potentially other attribute groups.
描述：SMIng必须支持从更基本类型的属性和潜在的其他属性组创建新的属性组。
Motivation: Simplifies the reuse of attribute groups such as InetAddressType and InetAddress pairs.
动机：简化属性组（如InetAddressType和InetAddress对）的重用。
Notes: Containment has the implicit existence constraint that if an instance of a contained attribute group exists, then the corresponding instance of the containing attribute group must also exist.
注意：包含具有隐式存在约束，即如果包含属性组的实例存在，则包含属性组的相应实例也必须存在。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: SMIng must provide support for mechanisms to extend attribute groups through single inheritance.
描述：SMIng必须支持通过单个继承扩展属性组的机制。
Motivation: Allows to extend attribute groups, like a generic DiffServ scheduler, with attributes for a specific scheduler, without cut&paste.
动机：允许使用特定调度器的属性扩展属性组，如通用DiffServ调度器，而无需剪切和粘贴。
Notes: Single inheritance with multiple levels (e.g., C derives from B, and B derives from A) must be allowed.
注意：必须允许具有多个级别的单一继承（例如，C派生自B，B派生自A）。
Inheritance has the implicit existence constraint that if an instance of a derived attribute group exists, then the corresponding instance of the base attribute group must also exist.
继承具有隐式存在约束，即如果派生属性组的实例存在，则基本属性组的相应实例也必须存在。
Inheritance could help to add attributes to an attribute group that are specific to a certain protocol mapping and do not appear in the protocol-neutral attribute group.
继承有助于向属性组添加特定于特定协议映射且不显示在协议无关属性组中的属性。
Type: new
类型：新
From: NMRG, WG
发件人：NMRG，WG
Description: SMIng must differentiate between "final" and reusable attribute groups, where the reuse of attribute groups covers inheritance and containment.
描述：SMIng必须区分“最终”属性组和可重用属性组，其中属性组的重用包括继承和包含。
Motivation: This information gives people more information how attribute groups can and should be used. It hinders them from misusing them.
动机：该信息为人们提供了更多关于属性组可以和应该如何使用的信息。它阻止他们滥用它们。
Notes: This objective attempts to convey the idea that some attribute groups are not meant to stand on their own and instead only make sense if contained within another attribute group.
注：此目标试图传达这样一种理念，即某些属性组并不意味着独立存在，而是只有包含在另一个属性组中时才有意义。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide mechanisms to define events which identify significant state changes.
描述：SMIng必须提供机制来定义识别重大状态更改的事件。
Motivation: These represent the protocol-independent events that lead to SMI notifications or SPPI reports.
动机：这些表示导致SMI通知或SPPI报告的协议无关事件。
Type: align
类型：对齐
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must support a mechanism to define creation/deletion operations for instances. Specific creation/deletion errors, such as INSTALL-ERRORS, must be supported.
说明：SMIng必须支持定义实例创建/删除操作的机制。必须支持特定的创建/删除错误，例如安装错误。
Motivation: Available for row creation in SMI, and available in SPPI.
动机：可用于SMI中的行创建，也可用于SPPI。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must allow specifying range and size constraints where applicable.
说明：SMIng必须允许在适用的情况下指定范围和大小约束。
Motivation: The SMI and SPPI both support range and size constraints.
动机：SMI和SPPI都支持范围和大小限制。
Type: basic
类型：基本型
From: SPPI
发件人：SPPI
Description: SMIng must allow the specification of uniqueness constraints on attributes. SMIng must allow the specification of multiple independent uniqueness constraints.
描述：SMIng必须允许对属性指定唯一性约束。SMIng必须允许指定多个独立的唯一性约束。
Motivation: Knowledge of the uniqueness constraints on attributes allows to verify protocol specific mappings (e.g. INDEX clauses). The knowledge can also be used by code generators to improve generated implementation-specific data structures.
动机：了解属性的唯一性约束允许验证特定于协议的映射（例如索引子句）。代码生成器也可以使用这些知识来改进生成的特定于实现的数据结构。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide clear rules how one can extend SMIng modules without causing interoperability problems "over the wire".
描述：SMIng必须提供明确的规则，说明如何在不造成互操作性问题的情况下扩展SMIng模块。
Motivation: SMIv2 and SPPI have extension rules.
动机：SMIv2和SPPI有扩展规则。
Type: fix
类型：fix
From: WG
发件人：WG
Description: The SMIng SNMP mapping must deprecate the use of the IMPLIED indexing schema.
描述：SMIng SNMP映射必须禁止使用隐含索引架构。
Motivation: IMPLIED is confusing and most people don't understand it. The solution (IMPLIED) is worse than the problem it is trying to solve and therefore for the sake of simplicity, the use of IMPLIED should be deprecated.
动机：暗示令人困惑，大多数人不理解。解决方案（隐含的）比它试图解决的问题更糟糕，因此为了简单起见，应该反对使用隐含的。
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: The SMIng language must avoid redundancy.
描述：SMIng语言必须避免冗余。
Motivation: Remove any textual redundancy for things like table entries and SEQUENCE definitions, which only increase specifications without providing any value.
动机：删除表项和序列定义等内容的任何文本冗余，它们只会增加规范而不提供任何值。
Type: basic
类型：基本型
From: SMI, SPPI
发件人：SMI，SPPI
Description: SMIng must provide a mechanism for compliance and conformance specifications for protocol-independent definitions as well as for protocol mappings.
描述：SMIng必须为协议独立定义以及协议映射提供合规性和合规性规范机制。
Motivation: This capability exists in SMIv2 and SPPI. The NMRG proposal has the ability to express much of this information at the protocol-dependent layer. Some compliance or conformance information may be protocol-independent, therefore there is also a need to be able to express this information protocol-independent part.
动机：此功能存在于SMIv2和SPPI中。NMRG方案能够在协议相关层表达大部分信息。某些合规性或合规性信息可能与协议无关，因此也需要能够表达此信息与协议无关的部分。
Type: fix
类型：fix
From: WG
发件人：WG
Description: SMIv2, RFC 2580, Section 3.1 says:
说明：SMIv2，RFC 2580，第3.1节规定：
The OBJECTS clause, which must be present, is used to specify each object contained in the conformance group. Each of the specified objects must be defined in the same information module as the OBJECT-GROUP macro appears, and must have a MAX-ACCESS clause value of "accessible-for-notify", "read-only", "read-write", or "read-create".
OBJECTS子句必须存在，用于指定一致性组中包含的每个对象。每个指定的对象必须在对象组宏出现时的同一信息模块中定义，并且必须具有MAX-ACCESS子句值“可用于通知”、“只读”、“读写”或“读创建”。
The last sentence forbids to put a not-accessible INDEX object
into an OBJECT-GROUP. Hence, you can not refine its syntax in a
compliance definition. For more details, see
http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
The last sentence forbids to put a not-accessible INDEX object
into an OBJECT-GROUP. Hence, you can not refine its syntax in a
compliance definition. For more details, see
http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
Motivation: This error should not be repeated in SMIng.
动机：这个错误不应该在SMIng中重复。
Type: basic
类型：基本型
From: SPPI
发件人：SPPI
Description: SMIng must provide a mechanism to group definitions into subject categories. Concrete instances may only exist in the scope of a given subject category or context.
描述：SMIng必须提供一种机制，将定义分组到主题类别中。具体实例可能仅存在于给定主题类别或上下文的范围内。
Motivation: To scope the categories to which a module applies. In SPPI this is used to allow a division of labor between multiple client types.
动机：确定模块适用的类别范围。在SPPI中，这用于允许在多个客户端类型之间进行分工。
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: In SMI and SPPI modules some language keywords (macros and a number of basetypes) have to be imported from different SMI language defining modules, e.g. OBJECT-TYPE, MODULE-IDENTITY, Integer32 must to be imported from SNMPv2-SMI and TEXTUAL-CONVENTION must be imported from SNMPv2-TC, if used. MIB authors are continuously confused about these import rules. In SMIng only defined identifiers must be imported. All SMIng language keywords must be implicitly known and there must not be a need to import them from any module.
说明：在SMI和SPPI模块中，必须从不同的SMI语言定义模块导入一些语言关键字（宏和许多基类型），例如，必须从SNMPv2 SMI导入对象类型、模块标识、整数32，如果使用，必须从SNMPv2 TC导入文本约定。MIB作者一直对这些导入规则感到困惑。在SMIng中，只能导入定义的标识符。所有SMIng语言关键字都必须是隐式的，并且不需要从任何模块导入它们。
Motivation: Reduce confusion. Clarify the set of language keywords.
动机：减少困惑。澄清语言关键字集。
Type: align
类型：对齐
From: SMI, SPPI
发件人：SMI，SPPI
Description: Instance naming in SMIv2 and SPPI is different. SMIng must align the instance naming (either in the protocol neutral model or the protocol mappings).
说明：SMIv2和SPPI中的实例命名不同。SMIng必须对齐实例命名（在协议中立模型或协议映射中）。
Motivation: COPS-PR and SNMP have different instance identification schemes that must be handled.
动机：COPS-PR和SNMP具有不同的必须处理的实例标识方案。
Notes: A solution requires to investigate how close the naming schemes dictated by the protocols are. Perhaps it is feasible to have a single instance naming scheme in both SNMP and COPS-PR, even though the current SPPI and SMIv2 are different.
注意：解决方案需要调查协议规定的命名方案的接近程度。即使当前的SPPI和SMIv2不同，但在SNMP和COPS-PR中使用单实例命名方案可能是可行的。
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: The allowed length of the various kinds of identifiers must be extended from the current `should not exceed 32' (maybe even from the `must not exceed 64') rule.
说明：各种标识符的允许长度必须从当前的“不得超过32”（甚至可能从“不得超过64”）规则扩展。
Motivation: Reflect current practice of definitions.
动机：反映定义的当前实践。
Notes: The 32-rule was added back in the days where compilers could not deal with long identifiers. This rule is continuously violated these days and it does not make sense to keep it.
注意：32规则是在编译器无法处理长标识符的年代添加的。这条规则最近不断被违反，遵守它是没有意义的。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: SMIng must not assign OIDs to reusable definition of attributes, attribute groups, events, etc. Instead, SNMP and COPS-PR mappings must assign OIDs to the mapped items.
描述：SMIng不得将OID分配给属性、属性组、事件等的可重用定义。相反，SNMP和COPS-PR映射必须将OID分配给映射项。
Motivation: Assignment of OIDs in protocol neutral definitions can complicate reuse. OIDs of synonymous attributes are not the same in SMI and SPPI definitions. MIBs and PIBs are already registered in different parts of the OID namespace.
动机：在协议无关的定义中分配OID会使重用变得复杂。同义属性的OID在SMI和SPPI定义中不同。MIB和PIB已在OID命名空间的不同部分中注册。
This section represents the list of recommended objectives that would be nice to have. However, these are not automatically thought of as accepted objectives as, for example, they may entail a non-trivial amount of work in underlying protocols to support or they may be regarded as less important than other contradicting objectives that are accepted.
本节列出了建议的目标清单，这些目标很好。然而，这些并不是自动被认为是可接受的目标，例如，它们可能需要在基础协议中进行大量的工作来支持，或者它们可能被认为不如其他可接受的相互矛盾的目标重要。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should support a mechanism to define method signatures (parameters, return values, exception) that are implemented on agents.
描述：SMIng应该支持一种机制来定义在代理上实现的方法签名（参数、返回值、异常）。
Motivation: Methods are needed to support the definition of operational interfaces such as found in [RFC2925] (ping, traceroute and lookup operations). Also, the ability to define constructor/destructor interfaces could address issues such as encountered with SNMP's RowStatus solution.
动机：需要方法来支持操作接口的定义，如[RFC2925]（ping、traceroute和lookup操作）中的定义。此外，定义构造函数/析构函数接口的能力可以解决SNMP的RowStatus解决方案遇到的问题。
Notes: Is it possible to do methods without changing the underlying protocol? There is agreement that methods are useful, but disagreement upon the impact - one end of the spectrum sees this as a documentation tool for existing SNMP capabilities, while the
注意：是否可以在不更改基础协议的情况下执行方法？人们一致认为这些方法是有用的，但对其影响存在分歧——一方认为这是现有SNMP功能的文档工具，另一方则认为
other end sees this as a protocol update, moving forward, to natively support methods. The proposal is to wait and see if this is practical to implement as a syntax that is useful and can map to the protocol.
另一端将此视为一个协议更新，向前推进，以本机支持方法。我们的建议是等待，看看这是否可以作为一种有用的语法实现，并且可以映射到协议。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should support a standard format for unions.
说明：SMIng应支持联合的标准格式。
Motivation: Allows an attribute to contain one of many types of values. The lack of unions has also lead to relatively complex sparse table work-around in some DISMAN mid-level managers. Despite from discriminated unions (see Section 4.1.18), this kind of union has no accompanied explicit discriminator attribute that selects the union's type of value.
动机：允许属性包含多种类型的值之一。工会的缺乏也导致了一些令人沮丧的中层管理者中相对复杂的稀疏表格工作。尽管存在歧视联合（见第4.1.18节），但这种联合没有选择联合值类型的显式歧视属性。
Notes: The thought is that SNMP and COPS-PR can already support unions because they do not care about what data type goes with a particular OID.
注意：我们的想法是SNMP和COPS-PR已经可以支持联合，因为它们不关心特定OID的数据类型。
Type: new
类型：新
From: WG, NMRG
发件人：WG，NMRG
Description: SMIng should support the base data types Float32, Float64, Float128.
描述：SMIng应该支持基本数据类型Float32、Float64、Float128。
Motivation: Missing base types can hurt later on, because they cannot be added without changing the language, even as an SMIng extension. Lesson learned from the SMIv1/v2 debate about Counter64/Integer64/...
动机：缺少基类型可能会对以后造成伤害，因为在不更改语言的情况下无法添加它们，即使是作为SMIng扩展。从SMIv1/v2关于Counter64/Integer64/…的辩论中吸取的教训。。。
Notes: There is no mention as to whether or not the underlying protocols will have to natively support float data types. This is left to the mapping. However, it seems imperative that the float data type needs to be added to the set of intrinsic types in the SMIng language at the creation of the language as it will be impossible to add them later without changing the language.
注意：没有提到底层协议是否必须本机支持浮点数据类型。这是留给映射的。但是，在创建SMIng语言时，似乎必须将float数据类型添加到SMIng语言的内部类型集合中，因为以后不更改语言就无法添加它们。
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: The syntax of comments should be well defined, unambiguous and intuitive to most people, e.g., the C++/Java `//' syntax.
说明：注释的语法应该是定义良好的，对大多数人来说是明确和直观的，例如C++/Java`/'语法。
Motivation: ASN.1 Comments (and thus SMI and SPPI comments) have been
a constant source of confusion. People use arbitrary lengthy
strings of dashes (`-----------') in the wrong assumption that
this is always treated as a comment. Some implementations try to
accept these syntactically wrong constructs which even raises
confusion. We should get rid of this problem.
Motivation: ASN.1 Comments (and thus SMI and SPPI comments) have been
a constant source of confusion. People use arbitrary lengthy
strings of dashes (`-----------') in the wrong assumption that
this is always treated as a comment. Some implementations try to
accept these syntactically wrong constructs which even raises
confusion. We should get rid of this problem.
Notes: If the SMIng working group adopts a C-like syntax, then the C++/Java single-line comment should be adopted as well.
注意：如果SMIng工作组采用类似C的语法，那么也应该采用C++/Java单行注释。
Type: align
类型：对齐
From: SPPI
发件人：SPPI
Description: PIB and MIB row attributes reference a group of entries in another table. SPPI formalizes this by introducing PIB-TAG and PIB-REFERENCES clauses. This functionality should be retained in SMIng.
描述：PIB和MIB行属性引用另一个表中的一组条目。SPPI通过引入PIB-TAG和PIB-REFERENCES子句将其形式化。此功能应保留在SMIng中。
Motivation: SPPI formalizes tag references. Some MIBs also use tag references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2 does not provide a formal notation.
动机：SPPI将标记引用形式化。一些MIB也使用标记引用（请参阅RFC2573中的SNMP-TARGET-MIB），即使SMIv2没有提供正式的表示法。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should allow the definition of a SEQUENCE OF attributes or attribute groups (Section 4.1.27).
说明：SMIng应允许定义一系列属性或属性组（第4.1.27节）。
Motivation: The desire for the ability to have variable-length, multi-valued objects.
动机：渴望拥有可变长度、多值对象的能力。
Notes: Some issues with arrays are still unclear. As long as there are no concepts to solve the problems with access semantics (how to achieve atomic access to arbitrary-sized arrays) and their mappings to SNMP and COPS-PR protocol operations, arrays cannot be more than a nice to have objective.
注意：阵列的某些问题尚不清楚。只要没有解决访问语义（如何实现对任意大小阵列的原子访问）及其到SNMP和COPS-PR协议操作的映射问题的概念，阵列就只能是一个很好的目标。
Type: new
类型：新
From: WG
发件人：WG
Description: Informational text (DESCRIPTION, REFERENCE, ...) should allow i18nized encoding, probably UTF-8.
说明：信息性文本（说明、参考等）应允许i18nized编码，可能是UTF-8。
Motivation: There has been some demand for i18n in the past. The BCP RFC 2277 demands for internationalization.
动机：过去对i18n有一些需求。BCP RFC 2277要求国际化。
Notes: Although English is the language of IETF documents, SMIng should allow other languages for private use.
注：尽管英语是IETF文档的语言，但SMIng应允许其他语言供个人使用。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: It should be possible to separate the domain specific data modelling work from the network management protocol specific work.
说明：应该可以将特定于域的数据建模工作与特定于网络管理协议的工作分开。
Motivation: Today, working groups designing new protocols are forced to care about the design of SNMP MIBs and maybe COPR-PR PIBs to manage the new protocol. This means that experts in a specific domain are faced with details of at least one foreign (network management) technology. This leads to hard work and long revision processes. It would be a win to separate the task of pure data modelling which can be done by the domain experts easily from the network management protocol specific mappings. The mapping to SNMP and/or COPS-PR can be done (a) later separately and (b) by network management experts. This required NM expertise no longer hinders the progress of the domain specific working groups.
动机：今天，设计新协议的工作组被迫关注SNMP MIB的设计，可能还有COPR-PR PIB来管理新协议。这意味着特定领域的专家至少要面对一种国外（网络管理）技术的细节。这将导致艰苦的工作和漫长的修订过程。将领域专家可以轻松完成的纯数据建模任务与网络管理协议特定映射分离开来将是一个胜利。到SNMP和/或COPS-PR的映射可以（a）稍后单独完成，（b）由网络管理专家完成。这一所需的NM专业知识不再阻碍特定领域工作组的进展。
This section represents the list of objectives that were rejected during the discussion on the objectives. Those objectives that have been rejected need not be addressed by SMIng. This does not imply that they must not be addressed.
本节列出了在讨论目标时被拒绝的目标列表。被拒绝的目标不需要通过SMIng解决。这并不意味着必须解决这些问题。
Type: basic
类型：基本型
From: WG
发件人：WG
Description: Reality sucks. All information expressed in SMIng may not be directly translatable to a MIB or PIB construct, but all information should be able to be conveyed in documentation or via other mechanisms.
描述：现实糟透了。SMIng中表达的所有信息可能无法直接转换为MIB或PIB结构，但所有信息都应该能够在文档中或通过其他机制进行传递。
Motivation: SMIng working group requires this to ease transition.
动机：Smiing工作组需要这一点来缓解过渡。
Notes: The SMIng language itself cannot require what compilers do that translate SMIng into something else. So this seems to fall out of the scope of the current working group charter.
注意：SMIng语言本身不需要编译器做什么才能将SMIng转换成其他语言。因此，这似乎不属于当前工作组章程的范围。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should provide mechanisms to formally specify constraints between values of multiple attributes.
描述：SMIng应该提供机制来正式指定多个属性值之间的约束。
Motivation: Constraints on attribute values occur where one or more attributes may affect the value or range of values for another attribute. One such relationship exists in IPsec, where the type of security algorithm determines the range of possible values for other attributes such as the corresponding key size.
动机：当一个或多个属性可能影响另一个属性的值或值范围时，会出现对属性值的约束。IPsec中存在这样一种关系，其中安全算法的类型决定了其他属性（如相应的密钥大小）的可能值范围。
Notes: This objective as is has been rejected as too general, and therefore virtually impossible to implement. However, constraints that are implicit with discriminated unions (Section 4.1.18), enumerated types (Section 4.1.17), pointer constraints (Section 4.1.21)), etc., are accepted and these implicit constraints are mentioned in the respective objectives.
注：这一目标因过于笼统而被拒绝，因此实际上不可能实现。但是，接受带有歧视联合的隐式约束（第4.1.18节）、枚举类型（第4.1.17节）、指针约束（第4.1.21节）等，这些隐式约束在各自的目标中提到。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should provide a mechanism to formally express that certain sets of attributes can only be modified in combination.
描述：SMIng应该提供一种机制来正式表示某些属性集只能组合修改。
Motivation: COPS-PR always does operations on table rows in a single transaction. There are SMIv2 attribute combinations that need to be modified together (such as InetAddressType, InetAddress).
动机：COPS-PR总是在单个事务中对表行执行操作。有一些SMIv2属性组合需要一起修改（例如InetAddressType、InetAddress）。
Notes: Alternative is to either use Methods (Section 4.2.1) or assume that all attributes in an attribute group (Section 4.1.27) are to be considered atomic.
注：替代方法是使用方法（第4.2.1节）或假设属性组（第4.1.27节）中的所有属性都被视为原子属性。
Type: new
类型：新
From: WG
发件人：WG
Description: Method definitions should provide constraints on parameters.
说明：方法定义应提供参数约束。
Motivation: None.
动机：没有。
Notes: Unless methods (Section 4.2.1) are done, there is no use for this. Furthermore, this objective has not been motivated by any proponent.
注：除非采用了方法（第4.2.1节），否则没有任何用处。此外，这一目标并未受到任何支持者的推动。
Type: basic
类型：基本型
From: SMI
发件人：SMI
Description: SMIng should provide mechanisms to describe agent implementations.
描述：SMIng应该提供描述代理实现的机制。
Motivation: To permit manager to determine variations from the standard for an implementation.
动机：允许经理确定实施标准的变化。
Notes: Agent capabilities should not be part of SMIng, but should instead be a separate capabilities table.
注意：代理功能不应该是SMIng的一部分，而应该是一个单独的功能表。
Type: new
类型：新
From: NMRG, WG
发件人：NMRG，WG
Description: Ability to formally depict existence dependency, value dependency, aggregation, containment, and other relationships between attributes or attribute groups.
描述：能够正式描述存在依赖、值依赖、聚合、包含以及属性或属性组之间的其他关系。
Motivation: Helps humans to understand the conceptual model of a module. Helps implementers of MIB compilers to generate more `intelligent' code.
动机：帮助人们理解模块的概念模型。帮助MIB编译器的实现者生成更“智能”的代码。
Notes: This objective was deemed too general to be useful and instead the individual types of relationship objectives (e.g., pointers, inheritance, containment, etc.) are evaluated on a case-by-case basis with the specific relationships deemed useful being included as accepted objectives.
注：该目标被视为过于笼统而没有用处，相反，单独类型的关系目标（例如指针、继承、包含等）是在个案基础上进行评估的，被视为有用的特定关系被视为可接受的目标。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should support a mechanism to formally define procedures that are used by managers when interacting with an agent.
描述：SMIng应该支持一种机制，正式定义管理者在与代理交互时使用的过程。
Motivation: None.
动机：没有。
Notes: This objective has not been motivated by any proponent.
注：此目标并非由任何支持者推动。
Type: new
类型：新
From: WG
发件人：WG
Description: SMIng should provide mechanisms to explicitly specify associations.
描述：SMIng应该提供明确指定关联的机制。
Motivation: None.
动机：没有。
Notes: This objective has not been motivated by any proponent.
注：此目标并非由任何支持者推动。
Type: new
类型：新
From: WG
发件人：WG
Description: Cardinalities between associations should be formally defined.
说明：应正式定义关联之间的基数。
Motivation: If you have an association between attribute groups A and B, the cardinality of A indicates how many instances of A may be associated with a single instance of B. Our discussions in Minneapolis indicated that we want to convey "how many" instances are associated in order to define the best mapping algorithm - whether a new table, a single pointer, etc. For example, do we use RowPointer or an integer index into another table? Do we map to a table that holds instances of the association/relationship itself?
动机：如果属性组A和B之间存在关联，则A的基数表示A的多少个实例可能与B的单个实例关联。我们在明尼阿波利斯的讨论表明，为了定义最佳映射算法，我们希望传达关联的“多少”实例-新表，单个指针等。例如，我们是使用RowPointer还是整数索引到另一个表中？我们是否映射到一个包含关联/关系本身实例的表？
Notes: Without associations (Section 4.3.8), this has no use.
注：如果没有关联（第4.3.8节），则没有任何用处。
Type: new
类型：新
From: WG
发件人：WG
Description: The SMIng documents should give clear guidance on which kind of information (with respect to generality, type/attribute group/extension/..) should be put in which kind of a module.
说明：SMIng文档应明确说明应将哪种信息（关于通用性、类型/属性组/扩展/）放入哪种类型的模块中。
E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL-MIB, but we also do not like to introduce a redundant definition.
例如，在SMIv2中，我们不喜欢从SYSAPPL-MIB导入Utf8String，但也不喜欢引入冗余定义。
A module review process should probably be described that ensures that generally useful definitions do not go into device or service specific modules.
可能应该描述一个模块评审过程，以确保一般有用的定义不会进入设备或服务特定的模块。
Motivation: Bad experience with SMIv2.
动机：SMIv2的糟糕体验。
Notes: It is not clear how this can be done with the language to be created by SMIng WG.
注意：不清楚如何使用SMIng WG创建的语言来实现这一点。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: There should be a clear statement how SMIng modules are mapped to files (1:1, n:1?) and how files should be named (by module name in case of 1:1 mapping?).
描述：应该有一个明确的声明，说明SMIng模块如何映射到文件（1:1，n:1？），以及文件应该如何命名（在1:1映射的情况下，通过模块名称？）。
Motivation: SMI implementations show up a variety of filename extensions (.txt, .smi, .my, none). Some expect all modules in a single file, others don't. This makes it more difficult to exchange modules.
动机：SMI实现显示了各种文件扩展名（.txt、.SMI、.my、none）。有些人希望所有模块都在一个文件中，有些人则不希望。这使得交换模块更加困难。
Notes: This is just an implementation detail and is best left to a BCP and not made a part of the language definition.
注意：这只是一个实现细节，最好留给BCP，而不是语言定义的一部分。
Type: new
类型：新
From: NMRG
发件人：NMRG
Description: The grammar of the language should be as simple as possible. It should be free of exception rules. A measurement of simplicity is shortness of the ABNF grammar.
说明：该语言的语法应尽可能简单。它应该没有例外规则。衡量简单性的一个标准是ABNF语法的短小。
Motivation: Ease of implementation. Ease of learning/understanding.
动机：易于实施。易于学习/理解。
Notes: This seems like an obvious objective, however shortness of the ABNF grammar is not necessarily a reflection of the simplicity of the grammar.
注：这似乎是一个明显的目标，但ABNF语法的简短不一定反映了语法的简单性。
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: Module specific information (organization, contact, description, revision information) should be bound to the module itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).
描述：模块特定信息（组织、联系人、描述、修订信息）应绑定到模块本身，而不是绑定到人工节点（如SMIv2 Module-IDENTITY）。
Motivation: Simplicity and design cleanup.
动机：简单和设计清理。
Notes: This does not seem to be a problem with the current SMI. Although simplification is a good thing, this detail is not considered an objective.
注意：这似乎不是当前SMI的问题。虽然简化是件好事，但这一细节并不被视为目标。
Type: new
类型：新
From: WG
发件人：WG
Description: Currently the namespace of modules is flat and there is no structure in module naming causing the potential risk of name clashes. Possible solutions:
描述：目前模块的名称空间是扁平的，模块命名中没有结构，导致名称冲突的潜在风险。可能的解决方案：
* Assume module names are globally unique (just as SMIv1/v2), just give some recommendations on module names.
* 假设模块名是全局唯一的（就像SMIv1/v2），只需给出一些关于模块名的建议。
* Force all organizations, WGs and vendors to apply a name prefix (e.g. CISCO-GAGA-MIB, IETF-DISMAN-SCRIPT-MIB?).
* 强制所有组织、工作组和供应商应用名称前缀（例如CISCO-GAGA-MIB、IETF-DISMAN-SCRIPT-MIB？）。
* Force enterprises to apply a prefix based on the enterprise number (e.g. ENT2021-SOME-MIB).
* 强制企业基于企业编号应用前缀（例如ENT2021-SOME-MIB）。
* Put module names in a hierarchical domain based namespace (e.g. DISMAN-SCRIPT-MIB.ietf.org).
* 将模块名称放在基于域的分层命名空间中（例如，DISMAN-SCRIPT-MIB.ietf.org）。
Motivation: Reduce risk of module name clashes.
动机：降低模块名称冲突的风险。
Notes: Some aspects of this objective overlap with other objectives (namespace control (Section 4.1.9)) and other aspects were thought best left to a BCP.
注：此目标的某些方面与其他目标重叠（命名空间控制（第4.1.9节）），其他方面最好留给BCP处理。
Type: fix
类型：fix
From: NMRG
发件人：NMRG
Description: There has been some confusion whether hyphens are allowed in SMIv2 identifiers: Module names are allowed to contain hyphens. Node identifiers usually are not. But for example `mib-2' is a frequently used identifier that contains a hyphen due to its SMIv1 origin, when hyphen were not disallowed. Similarly, a number of named numbers of enumeration types contain hyphens violating an SMIv2 rule.
描述：SMIv2标识符中是否允许连字符存在一些混淆：模块名称允许包含连字符。节点标识符通常不可用。但例如，“mib-2”是一个经常使用的标识符，由于其SMIv1来源，它包含连字符，而连字符并不是不允许的。类似地，许多命名的枚举类型包含违反SMIv2规则的连字符。
SMIng should simply allow hyphens in all kinds of identifiers. No exceptions.
SMIng应该只允许在所有类型的标识符中使用连字符。没有例外。
Motivation: Reduce confusion and exceptions. Requires, however, that implementation mappings properly quote hyphens where appropriate.
动机：减少混乱和例外。但是，要求实现映射在适当的地方正确引用连字符。
Notes: This nit-picking is not worth to be subject to the discussion on objectives. However, SMIng should care about the fact that compilers have to map SMIng to programming languages where a hyphen is a minus and thus not allowed in identifiers.
注：这种吹毛求疵的做法不值得在目标讨论中讨论。然而，SMIng应该关注这样一个事实：编译器必须将SMIng映射到编程语言，其中连字符是负号，因此在标识符中不允许使用。
This document defines objectives for a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
本文件定义了用于书写和阅读管理信息描述的语言的目标。这种语言本身对互联网没有安全影响。
Thanks to Dave Durham, whose work on the original NIM (Network Information Model) draft was used in generating this document.
感谢Dave Durham，他在原始NIM（网络信息模型）草案上的工作用于生成本文档。
Thanks to Andrea Westerinen for her contributions on the original NIM requirements and SMIng objectives drafts.
感谢Andrea Westerinen对原始NIM要求和SMIng目标草案的贡献。
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[1] Case，J.，Fedor，M.，Schoffstall，M.和J.Davin，“简单网络管理协议（SNMP）”，STD 15，RFC 1157，1990年5月。
[2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[2] McCloghrie，K.，Case，J.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[3] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[3] Chan，K.，Seligson，J.，Durham，D.，Gai，S.，McCloghrie，K.，Herzog，S.，Reichmeyer，F.，Yavatkar，R.和A.Smith，“政策制定的COPS使用（COPS-PR）”，RFC 3084，2001年3月。
[4] 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.
[4] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[5] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[6] McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[7] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001.
[7] McCloghrie，K.，Fine，M.，Seligson，J.，Chan，K.，Hahn，S.，Sahita，R.，Smith，A.和F.Reichmeyer，“策略供应信息的结构（SPPI）”，RFC 3159，2001年8月。
Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: chelliot@cisco.com
EMail: chelliot@cisco.com
David Harrington Enterasys Networks 35 Industrial Way P.O. Box 5005 Rochester, NH 03866-5005 USA
David Harrington Enterasys Networks美国新罕布什尔州罗切斯特市工业路35号邮政信箱5005 03866-5005
EMail: dbh@enterasys.com
EMail: dbh@enterasys.com
Jamie Jason Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR 97124 USA
杰米·杰森·英特尔公司，美国希尔斯伯勒东北25大道JF3-206 2111号，邮编：97124
EMail: jamie.jason@intel.com
EMail: jamie.jason@intel.com
Juergen Schoenwaelder TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
德国布伦瑞克大学。23 38106德国布伦瑞克
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Frank Strauss TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
弗兰克·施特劳斯·图布伦瑞克·穆埃伦普福尔德斯特。23 38106德国布伦瑞克
EMail: strauss@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
EMail: strauss@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH. 03054 USA
Walter Weiss Ellacoya Networks 7 Henry Clay Merrimack博士，NH。03054美国
EMail: wweiss@ellacoya.com
EMail: wweiss@ellacoya.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。