RFC3410中文版

RFC:3410                              R.Mundy 网络联合实验室

废弃：2570                                  D.Partain 爱立信公司

类别：报告                                  B.Stewart 已退休

                                            2002年 12月

互联网标准管理框架介绍与应用

本备忘录状态

    此备忘录为因特网社区提供了一定信息。但它并不是定义了任何形式的Internet标准。另外，本备忘录的发布不受任何。

版权提示

    版权归The Internet Society所有（2002）。版权所有。

摘要

    这篇文档的写作目的是对互联网标准管理框架第三版本，也就是SNMP框架第三版（SNMPv3）进行一个概述说明。这个框架是由互联网标准管理标准第一版（SNMPv1）和第二版（SNMPv2）发展演变而来。

    该框架的体系设计成模块化的以使它可以随着时间的发展而不断进行演进。

    这篇文档对于为什么大家强烈建议使用SNMPv3取代v1和v2进行了解答。同时文档也建议废弃RFC1157、1441、1901、1909和1910，并将它们转入状态改为历史状态。本文档中就废弃了RFC2570。

目录

引言

本文档对互联网标准管理框架第三版即SNMPv3进行了介绍，同时还有另外的几个目的。

首先，它描述了SNMPv1和SNMPv2之间的关系以及针对SNMPv2的基于社区的管理框架。

其次，它为我们去获取大量的文档提供了指引，这些文档包含了相关的一些规范。

第三，文档对相关的规范文档进行了摘要讲解，这些简短的文字很利于读者阅读。

这篇文档的意图本来就是一个指导性质的，基于这个原因可能有时会感觉有点太单一了。在和那些更加注重讲解细节的文档的较量中，由于文档本身针对于指导作用，所以前者具有很明显的优势。

另外，为了更好的定义不同模块的接口，详细文档都试图保持模块之间的分离特性。这篇指引性的文档采取一种不同的方式并试图提供一种对不同模块综合的观点，目的是具有更好的可读性。

本文档是IETF组织的SNMPv3工作组的劳动成果。

文档中出现的关键字比如“MUST”，“MUST NOT”,    “REQUIRED”,”SHALL”,”SHALL NOT”,”SHOULD”,”SHOULD NOT”,”RECONMMENDED”,”MAY”,和”OPTIONAL”可以被看作像在RFC2119[1]的BCP 14中描述的一样。

1.互联网标准管理框架

互联网标准管理框架第三版（SNMPv3框架）是从最初的互联网标准管理框架第一版（SNMPv1框架）和互联网标准管理框架第二版（SNMPv2框架）发展、建立起来的。

    互联网标准管理SNMP框架的所有版本（SNMPv1 、SNMPv2和 SNMPv3）提供了同样的基本结构和组件。进一步而言，所有版本的互联网标准管理框架规范都遵循同样一个体系架构。

2．1 基本结构和组件

    企业部署的互联网标准管理框架包括以下四个基本组件：

✧一些（通常很多个）管理节点，每个节点上有一个可以远程访问管理设备（一般称为代理）的SNMP实体；

✧至少一个SNMP实体具有管理所用的应用程序（称为管理者）；

✧管理协议，用于在各个SNMP实体间进行网管的信息传递；

✧管理信息。

管理协议用于传递SNMP实体比如管理者和代理间的网管信息。

这个基本的结构对于任何版本的互联网标准管理框架（例如SNMPv1 、SNMPv2和 SNMPv3）来说都是很普遍的。

1.2互联网标准管理框架体系结构

互联网标准管理框架规范基于模块化的体系架构。这个框架不止是一个传输数据的协议，它还包括：

✧数据定义语言，

✧管理信息定义（管理信息库，或叫MIB），

✧协议定义，

✧安全和管理。

随着时间的推进，虽然框架已经由SNMPv1，然后SNMPv2过度到了SNMPv3，这些组件的定义都更为完善和清晰，但基础架构仍然保持原来状态不变。

这个模块的首要促进因素就是框架的持续演进，就像RFC1052[2]里面说的。最初的设想就是用以使基于SNMP的互联网管理协议能平滑过渡到基于OSI协议簇的管理。最后这个框架采用协议无关的定义语言和管理信息库，还采用了MIB无关的协议。这种区分是不需要管理信息重新定义或解释。历史已经证明采用这种架构的正确性—这个架构实现了从SNMPv1到SNMPv2，SNMPv3的平滑过渡，而不是使这种过度原理了基于SNMP的管理方式。

    SNMPv3框架建立并扩展了很多架构原理，通过采取：

✧基于四个基本架构组件，有时把它们从SNMPv2框架中引用吸收进来；

✧通过使用同样的分层理念定义整个体系在安全和管理方面的能力；

对于那些熟悉SNMPv1和SNMPv2网络框架的的人来说，他们会发现在SNMPv3架构中存在很多相似的理念。不过，有些情况下可能所使用的术语有点差异。

2.SNMPv1管理框架

最初的互联网标准网络管理框架（SNMPv1）定义由以下文档给出：

✧STD 16,RFC 1155[3]，它定义了管理信息结构（SMI），为便于管理所使用的描述、命名对象机制。

✧STD 16, RFC 1212[4]，它定义了一种更加简明的描述命名管理信息对象机制，但这种机制是和SMI一致的。

✧STD 15, RFC 1157[5]，它定义了简单网络管理协议（SNMP），这个协议用于通过网络访问被管对象和事件通知。注意这个文档也定义了一个最初的事件通知集。

另外，下面两个文档被一致认为和前面提到的三个文档协同的：

✧STD 17, RFC 1213[6],它包括对管理信息的基础集定义；

✧RFC 1215 [7]，它定义了一个简明定义事件通知的机制，即在SNMPv1中叫做捕获。它也详述了在RFC1157简明标注的类捕获。

这些文档描述了SNMP框架第一版的四个部分。

3.1 SNMPv1数据定义语言

    最开始的两篇和最后那篇文档（i.e.RFC1155,1212 and 1215）描述了SNMPv1数据定义语言，有时在被提及的时候常常被冠以SMIv1的名字。注意由于最初SMI是协议无关的，所以刚开始的两个SMI文档没有提供对事件通知（捕获）的定义。相反，SNMP协议文档定义了标准的事件通知（类捕获）并提供了一个对新增加事件通知的定义方法。最后提及的那篇文档详述了一个利用SNMPv1协议定义事件通知的直接方式。在文档写作的那个时期，在互联网标准管理框架使用捕获颇具争议。本身RFC1215是以报告的形式被推荐的，它根本不会更新，因为大家认为第二版的SNMP框架会取代第一版本。

3．2 管理信息

    之前两个文档描述的数据定义语言起初用于定义现已成为历史的RFC 1066[8]中的MIB-I，后来被用来定义RFC 1213中提到的MIB-II。

    随后MIB-II的发布，一种不同的管理信息定义手段被使用，打破了以前只是有单一一个天才组成社区通过一个文档的方式定义互联网标准MIB。在一定程度上，许多小MIB文档以并行或分布式的方式产生，然后由各个分管不同互联网标准MIB的小组产生出规范。这些小组由相关领域的不同人员组成，其中就包括从事网络管理，系统管理和应用管理的人员。

    3.3 协议操作

    第三个文档,STD 15[5],描述了SNMPv1协议操作，以协议数据单元（PDUs）呈现，也描述了SNMPv1的消息格式。操作符定义为：get,get-next,get-response,set-request,and trap。在非面向连接传输服务上的SNMP的典型分层也予以了定义。

3.4 SNMPv1 安全和管理

    STD 15[5]也定义了安全和管理策略。许多这些观念特别是安全方面被SNMPv3框架继承并扩展。

    SNMPv1框架描述了SNMPv1 的SNMP实体之间传递的SNMP消息的PDUs分装，区分协议实体和应用实体。在SNMPv3中，这些重命名的各个应用和引擎。

    SNMPv1框架介绍了支持一至多个验证计划的验证服务。除验证外，SNMPv3定义了额外的被称作私密的安全能力。（注意：一些安全社区的作品里面可能将SNMPv3描述成提供数据完整性，源可靠性，以及机密性的安全能力）。SNMPv3框架模块化的特点允许它对安全能力进行改变和增加。

    最后，SNMPv1框架介绍基于SNMP MIB视角的访问控制。SNMPv3框架定义了一个很基础相似的理念叫做基于视角的访问控制。SNMPv3靠这个能力能提供对管理设备上的信息访问控制。

    然而，由于SNMPv1框架本来打算定义多重鉴权方案，最后却只是简单定义了基于共享字符串的鉴权方案。这对SNMPv1来说是一个不争的缺陷，但那时针对商业级安全来说已经足够，而且很难证明安全意味着不同的事务对应不同的人。后来，因为一些用户不需要很强的鉴权机制，SNMPv1将鉴权服务作为一个单独块对待，称作“后续”。SNMPv3框架利用那个块提供了一个架构，并且在子系统中也予以了定义。

3.SNMPv2管理框架

SNMPv2管理框架在[8-13]中有描述，它与SNMPv1共存以及过度，还有就是本身的描述在[15]中可以找到。

SNMPv2提供了一些优于SNMPv1的特性，包括：

✧扩展数据类型（比如位计数器）

✧性能效率提高（批量获取操作）

✧增强事件提醒（告知操作）

✧更强的出错处理（错误和异常）

✧加强的集合，特别是行创建于删除

✧数据定义语言的更好调整

但是SNMPv2框架，正如在那些文档中描述的一样，它是未完善的，因为它没有达到该项目最初的设计目标。这些包括没有提供安全规定，以及在管理时传输涉及的叫做商业级的安全，如：

✧鉴权：最初识别，信息完整性，重放保护的相关方面；

✧隐私：机密性；

✧授权和访问控制；

✧合适的远程配置和管理能力。

SNMPv3管理框架，正如本文和相关文档描述的那样，力图阐述这些不足。

4.SNMPv3工作小组

本文和其他相关文档都是由IETF的SNMPv3工作组产生的。SNMPv3工作小组是为下一代SNMP准备建议而准许增设的。工作组任务就是提供一批文档集以便于建立下一代核心SNMP功能的标准。下一代最关键的需求是定义基于SNMP的管理事务安全性，这对于使用SNMPv3管理网络、系统的用户来说是十分有用的。在这些网络、系统中不仅有安装在上面的系统软件，还包括管理者-代理，代理-管理者，管理者-管理者事务。

在工作组成立的前几年，已经有一些安全和改进针对SNMP的。包括：

✧SNMP安全 大约1991-1992（RFC 1351 –RFC 1353）

✧SNMP 大约1992-1993

✧基于群组的SNMPv2（那时叫做SNMPv2p）大约1993-1995（RFC 1441- RFC 1452）。

这些努力包括适应商业级和工业安全如鉴权，隐私，授权，基于视图的访问控制，如远程配置的管理。

    这些努力促进了SNMPv2管理框架的发展，如RFC1902-1908所述。但是，在这些文档中没有提供基于标准的安全和管理框架；在某种程度上，它是与多重安全和管理框架相关，包括：

✧基于社区的SNMPv2（SNMPv2c）RFC1901[16],

✧SNMPv2 RFCs 1909 和1910，

✧SNMPv2*.

SNMPv2c得到了IETF大力支持但却缺乏安全和管理，而在SNMPv2*和SNMPv2*有安全考虑但是却没有得到IETF一致性认可。

    SNMPv3工作组负责产生一系列针对下一代SNMP的规范，基于SNMPv2u和SNMPv2*概念和技术元素的集合，正如一个咨询组它们提供了一个单一针对SNMP解决方案。

    鉴于此，工作组定义了一系列要素：

✧针对不同管理需求提供大广度的操作环境；

✧减轻从之前的多协议向SNMPv3的过渡需求；

✧方便安装和维护活动；

在SNMPv3工作组的最初工作中，他们将重心放在安全和管理方面，包括：

✧鉴权和隐私；

✧授权和基于视图的访问控制

✧针对以上点的标准远程配置。

SNMPv3工作组没有重复造车轮，而是复用了SNMPv2草案标准文档，比如RFCs1902到1908，因为这部分不是关注点需要去做的。

在一定程度上，SNMPv3工作组的最初贡献者以及工作组不遗余力地阐释安全和管理的缺陷，也为管理艺术的状态做出了杰出贡献。

他们提出了一种基于模块化、强调层次性的演进能力架构。因此，SNMPv3可以被看作SNMPv2拥有附加安全和管理能力后的情况。

这样做之后，工作组达到了IETF的而且拥有安全和管理，统一规范。

6.SNMPv3框架模块规范

SNMPv3管理框架规范由几个模块化潮流的文档定义了。工作组这样做的目的时为了使得任何个人可以更新、替代已有文档，如果需要的话。这样做就可以使得新的思路新的技术引用进来。

不管怎样，SNMPv3的文档集最初都是通过引入SNMPv2管理框架已经定义了的一些框架，直接参考进来的。

SNMPv3认为这些规范和SNMPv3的安全和管理有很大关系。

定义了SNMPv3管理框架的文档遵循了之前的版本结构，能够以四类组织起来：

数据定义语言；

管理信息库（MIB）模块；

协议操作；

安全和管理。

最初的三个文档从SNMPv2中并入了进来。第四个文档对SNMPv3来说是新的，但是正如之前描述的一样，是建立在之前卓有成效的相关工作上的。

6.1数据定义语言

数据定义语言的规范包含STD 58、RFC 2578、“管理信息版本结构第二版”以及相关文档。这些文档时RFCs1902-1904【9-11】的更新版。

管理信息结构定义基本数据类型，对象模型和书写、重现MIB模块的规则。相关的规范包括STD58，RFCs2579，2580。

STD58,RFC2579,”SMIv2文本规约”定义了一个最初的类型，这些对人们理解、书写带来了方便。

STD58,RFC2580,”SMIv2确认语句” 定义为遵守这些都是用报表的形式描述要求代理的实现和能力的声明可用于记录特定的特点实现。

术语“SMIv2”似乎有点混淆的，因为术语使用者试图认为它有两层意思至少。有时这个术语用在指STD58整个数据定义语言。第一在RFCs2578-2580有时又仅仅定义在RFC2578数据定义语言部分。这种混淆时不幸的但在实践中出问题的几率不是很大。

6.2MIB模块

MIB模块常常包含对象定义，可能包含事件提醒定义，有时还包含预声明定义，按照适当的对象和事件提醒组。本身，MIB模块定义了管理信息，包含在管理节点上，它由管理代理远程访问的，通过管理协议传送的，通过管理程序操纵的。

MIB模块通过定义在数据定义语言的规范文档，更或者时SMI相关的文档来定义来定义自身。

有许多大的增长着的标准MIB模块，被定义在周期些更新的“互联网官方协议标准”列表里面。在写这个的期间，已经由100个标准MIB模块发展到10000个了。另外，还有更大的迅速增长的企业规范的MIB模块，这些由很多不同公司，研究机构，银行等等，由此产生了许多不知名的、或许无法计算数目的定义对象。

总之，定义在任何MIB模块中的管理信息，不管使用的是什么版本的数据定义语言，可以和不同版本的协议使用。例如，按照SNMPv1的SMI（SMIv1）定义的MIB模块时可以和SNMPv3管理框架匹配的，同时可以被相应定义的协议传输。还有，MIB模块可以和SNMPv1定义的协议操作匹配。尽管如此，也存在值得我们注意的例外：位数据类型可以定义在以SNMIv2格式定义的MIB模块中，但是不能被SNMPv1协议引擎转换。它可以被SNMPv2或者SNMPv3类型的协议引擎转换，但是不能被专门支持SNMPv1的引擎转换。

6．3协议操作和传送映射

针对SNMPv3框架的协议操作和传送映射规范通过参照两个持续更新的SNMPv2框架文档整合的。

针对协议操纵的规范可以在STD62，RFC3416，“简单网络管理协议协议第二版”[21]中找到。

SNMPv3框架设计成允许架构的不同部分演进。例如，对一个新的协议操作规范可以附加另外的协议操作，这是可能的。

传送映射规范可以在STD62，RFC3417，“针对SNMP的传送映射”[22]中找到。

6.4SNMPv3安全和管理

由SNMPv3工作组定义的关于SNMPv3安全和管理文档系列包括以下7个文档，目前：

✧RFC3410，“互联网标准管理框架介绍和应用阐释”，就是该文档

✧STD62，RFC3411，“描述简单网络管理协议框架的架构”，描述了针对安全和管理的整个架构

✧STD62，RFC3412，“针对SNMP的基于视图访问控制模型”，描述了访问控制怎么适用在基于命令响应和提醒的应用程序中

✧RFC2576，“SNMPv3共存与过渡”[28],描述了SNMPv3管理框架和SNMPv2和SNMPv1管理框架之间的共存，并且由Work in Progress在负责更新中

✧

7.文档总结

    以下部分对之前提到的文档进行一个比之前稍微细致点的说明和分析。

7.1管理信息结构

管理信息被看成一系列被管对象的集合，位于一个虚拟的信息存储被叫做MIB里面。相关对象集定义在MIB模块里面。这些模块写在一个从一个OSI ASN.1适当子集发展而来的SNMP数据定义语言中。STD58，RFCs2578，2579，2580共同定义了数据定义语言，规范了针对对象的基本数据类型，定义了数据类型短期规范，叫做文本规约，定义了对象标示值管理分配。

SMI分成了三部分：模块定义，对象定义和提醒定义。

（1）模块定义用于在描述信息模块的时候。ASN.1宏，MODULE-IDENTITY被用来简明转换信息模块语义。

（2）对象定义用于当描述管理对象的时候。ASN.1宏，OBJECT-TYPE用于简要转换管理信息语法和语义。

（3）提醒帝国一用于当描述一个管理信息的主动传送。ASN.1宏，NOTIFICATION-TYPE用于简明转换一个提醒的语法和语义。

7.1.1基本SMI规范

STD58，RFC2578规范了针对数据定义语言的基本数据类型，包括：32位整型，枚举整型，无符号32位，Gauge32，Counter32，Counter，TimeTicks，整型，十进制字符串，对象标识，IP地址，Opaque和BITS。它也分配了不同对象标识不同的值。STD58，RFC2578更进一步定义了数据定义语言的以下构件：

✧IMPORTS允许被用在一个MIB模块中但定义在另一个MIB模块中的项目规范

✧MODULE-IDENTITY针对MIB模块定义了管理、描述信息例如联系和修改历史

✧OBJECT-TYPE定义数据类型，数据和管理对象语义

✧SWQUENCE分配表中一行元素

✧NOTIFICATION-TYPE定义事件通知

✧

7.1.2文本规约

当设计一个MIB模块的时候，暂时定义一个有相同行为的对象集语义时很有用的。这通过使用在SMI中已有基本数据类型定义新的数据类型达到要求。每个新类型有不同的名字，定义一个有更多性语义的基本类型。这些新定义的类型叫做文本规约，用于人读MIB模块和更智能的管理软件方便使用。STD58，RFC2579，SMIv2[18]文本规约，就是为了使用新定义的TEXTUAL-CONVENTION定义文本规约对所有MIB模块方便使用。

7.1.3一致性声明

定义一个可接受的窄幅度的实现，顺应正式级别实现是很有用的。STD58，RFC2580，SMIv2[19]一致性声明，定义了这种目的的定义语义。有两个大的贡献：

（1）一致性声明用于当描述代理需要和对象做出反应和事件提醒定义时。MODULE-COMPLIANCE用于简明转换那个需求。

（2）能力声明用于代理对对象响应时的能力和事件通知定义。AGENT-CAPABILITIES用于简明转换这种能力。

最后，相关对象集和相关事件通知定义集组合在一起形成一致性。OBJECT-GROUP用于简明转换对象和对象组语义。NOTIFICATION-GROUP用于简明转换事件提醒和事件组语义。

7．2协议操作

管理协议提供了代理和管理站之间传输的管理信息交换。这些信息形式是一个“wrapper”被封装在协议数据单元中。

7.3传送映射

SNMP小学可能用于不同协议族中。STD62，RFC3417,”简单网络管理协议传送映射”[22]，定义了了SNMP消息怎么映射到一个初始传输域中。其他映射可能在将来会有定义。

尽管一些映射定义了，在UDP上的映射是参考的映射。本身，为了提供最大限度的互操作性，部署其他映射也应当提供代理服务到UDP映射。

7.4协议指南

STD62,RFC3418,”SNMP管理信息库”[30],定义了描述SNMP实体不同部分行为的管理对象。

7.5架构/安全与管理

STD62,RFC3411,”描述SNMP管理框架架构”定义了规范管理框架的架构。尽管阐明了大致的架构事宜，它更多的是关注安全和管理方面。它定义血多用于SNMPv3管理框架的术语，为了澄清一下，列出来

✧引擎和程序

✧实体（服务提供者如代理和管理中的引擎）

✧标示（服务使用者）

✧管理信息，包括复杂逻辑上下文环境的支持

7.6信息处理和发送（MPD）

STD62，RFC3412，“简单网络管理协议信息处理和发送”[24],描述了SNMP架构的SNMP消息传送与处理。它定义可能不同潜在的SNMP消息处理和发送模型，为的是发送PDUs给SNMP程序。这篇文档同样描述了个信息处理模型—SNMPv3消息处理模型。

SNMPv3协议引擎必须支持至少一个消息处理模型。一个SNMPv3协议引擎可能支持多于一个，例如在一个多语言系统中提供了同时对SNMPv3、SNMPv1和SNMPv2c的支持。例如，那样一个三种语言的系统提供了三种对应的消息处理模型。

7.7SNMP应用

STD62，RFC3413,”简单网络管理协议应用”[25],描述了五种不同的应用，可以与SNMP引擎协同工作。它们是：命令生成器，命令响应器，提醒组织者，提醒接受者，代理转发器。

这篇文档也定义MIB模块，针对管理规范，提醒滤除，代理转发。

7.8基于用户的安全模型（USM）

STD62，RFC3414，“基于用户安全模型（USM）的SNMPv3”，描述了基于用户的安全模型。它定义了提供SNMP消息级别的安全处理元素。

文档定义了两个基本的和两个次级的威胁，这些时与USM对立的。它们是：信息修改，冒充，信息流修改和泄密。

USM利用MD5[31]和安全哈希算法[32]作为关键哈希算法，为的是提供简要计算数据集成：

✧直接保护数据修改攻击，

✧间接保护原授权，

✧维护冒充攻击

USM利用轻度同步单调增加的时间指示器保护信息免受篡改攻击。基于协议的自动时钟同步机制定义没有依赖第三方时间源，不需要随之而来的伴随安全考虑。

USM利用数据加密标准DES按照CBC，如果需要泄密保护的支持的话。USM中对DES的支持是可选的，主要是因为在很多国家导出和使用的使得很难使用包含加密技术的导出和使用产品。

这篇文档也包括一个MIB适合远程监视和管理USM的配置参数，包括key分发和管理。

一个实体提供多种安全模型的支持，还有多种鉴权和私有协议。所有这些协议在USM使用时都是基于预先放置keys的，例如私有key机制。SNMPv3构架允许同步和非同步的机制和协议，但是在写这篇文档期间，在IETF上关于SNMPv3安全模型使用共有key加密的没有存在。

工作还在继续，定义AES用于基于用户的安全模型中。这可能会是一个单独的文档。

7.9基于视图的访问控制（VACM）

STD62，RFC3415，“基于视图访问控制的SNMP”[27],描述了基于视图的访问控制模型用于SNMP架构中。VACM可以同时在一个拥有多种消息处理模型和多种安全模型的单独引擎实现协同。

在架构上同时拥有多种不同的访问控制模型单独的引擎实现时可能的，但是这是在实践中很少存在的，很不常见的多消息处理模型和安全模型。

7.10SNMPv3共存和过渡

RFC2576,”三种SNMP版本共存”，描述了SNMPv3管理框架和SNMPv1管理框架和SNMPv2管理框架的共存，特别地，这篇文档描述了四个方面的共存：

✧从SMIv1到SMIv2格式的MIB文档的转换

✧提醒参数映射

✧支持多版本SNMP协议，多语言网络多操作实现代理实现行为的支持共存

✧SNMPv1消息处理模型和基于社区的安全模型，提供适应SNMPv1和SNMPv2c到基于视图的访问控制模型

8.标准化状况

读者应当咨询一下最新的“互联网官方协议标准” 版本名单，以决定任何文档的标准化状态。

8.1 SMIv1状况

SMIv1，在STD16，RFCs1155和1212中有阐述，提名作为标准化状态在1999年，一直保持到SNMIv2作为标准化。在许多情况下，一个标准如果被替代就会标明为“历史的”。

在使用层次上，自从1993年对于用户来说使用数据定义语言使用SMIv2代替所有工作因为市场环境下要求使用对SMIv1和SMIv2格式数据定义支持。虽然有低廉甚至免费的产品可以用于转换SMIv1定义到SMIv2定义，但是建立自动的转换时不实用的。所以，如果一个人按SMIv2工作，提供数据定义在两种格式下的花费是没有意义的。相反，如果她时工作在SMIv1格式下的，提供数据定义是很明显开销大的。目前市场对于提供以SMIv1格式数据定义需求是逐渐减少的。

8.2 SNMPv1和SNMPv2标准化状况

通过SNMPv1和SNMPv2封装器的协议操作仅仅支持基于普通文本字符串的鉴权，因而时不安全的。当SNMPv3规范提供了安全和管理规范后，作为曾经的标准SNMPv1，以前时STD15，以及实验性SNMPv2c规范在RFC1901中已被声明为历史版本，由于缺乏足够的安全性保障。

从实用的角度来说，我们希望有很多厂家继续生产，用户继续部署和使用多语言环境实现，它同时支持三个版本的SNMP。值得注意的是，IETF不会去干涉厂家或用户继续选择提升、部署历史协议。尽管如此，这是不值得推广的。

确实，正如上面所说，针对SNMPv3的安全和管理规范，RFC2576，将会和其它版本共存。

当然，用户部署带有不安全协议的多语言系统，可以通过以SNMPv1和SNMPv2访问的配置达到，保持组织的安全策略。

8.3工作组建议

基于上面的解释，SNMPv3工作组推荐RFC1157，1901和1910归类到历史文档。

9.安全考虑

由于这篇文档只是一个向导性文档，它没有介绍新的安全考虑。读者可以参考每个参考文献的安全相应部分来获取信息。

10.参考文献

【过多，所以省略】