Network Working Group J. Schoenwaelder
Request for Comments: 5343 Jacobs University Bremen
Updates: 3411 September 2008
Category: Standards Track
Network Working Group J. Schoenwaelder
Request for Comments: 5343 Jacobs University Bremen
Updates: 3411 September 2008
Category: Standards Track
Simple Network Management Protocol (SNMP) Context EngineID Discovery
简单网络管理协议（SNMP）上下文引擎ID发现
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
简单网络管理协议（SNMP）第三版（SNMPv3）要求应用程序知道远程SNMP协议引擎的标识符（snmpEngineID），以便检索或操作远程SNMP实体上维护的对象。
This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
本文档介绍了一个著名的localEngineID和一种发现机制，可用于学习远程SNMP协议引擎的snmpEngineID。建议的机制独立于SNMP安全模型提供的功能，也可由提供对托管对象访问的其他协议接口使用。
This document updates RFC 3411.
本文档更新了RFC 3411。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4
3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Local EngineID . . . . . . . . . . . . . . . . . . . . . . 4
3.2. EngineID Discovery . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
To retrieve or manipulate management information using the third version of the Simple Network Management Protocol (SNMPv3) [RFC3410], it is necessary to know the identifier of the remote SNMP protocol engine, the so-called snmpEngineID [RFC3411]. While an appropriate snmpEngineID can in principle be configured on each management application for each SNMP agent, it is often desirable to discover the snmpEngineID automatically.
要使用简单网络管理协议（SNMPv3）[RFC3410]的第三版本检索或操作管理信息，需要知道远程SNMP协议引擎的标识符，即所谓的snmpEngineID[RFC3411]。虽然原则上可以为每个SNMP代理在每个管理应用程序上配置适当的snmpEngineID，但通常需要自动发现snmpEngineID。
This document introduces a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models. The mechanism has been designed to coexist with discovery mechanisms that may exist in SNMP security models, such as the authoritative engine identifier discovery of the User-based Security Model (USM) of SNMP [RFC3414].
本文档介绍了一种发现机制，可用于了解远程SNMP协议引擎的snmpEngineID。该机制独立于SNMP安全模型提供的功能。该机制被设计为与SNMP安全模型中可能存在的发现机制共存，例如SNMP基于用户的安全模型（USM）的权威引擎标识符发现[RFC3414]。
This document updates RFC 3411 [RFC3411] by clarifying the IANA rules for the maintenance of the SnmpEngineID format registry.
本文档通过澄清维护SnmpEngineID格式注册表的IANA规则来更新RFC 3411[RFC3411]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Within an administrative domain, an SNMP engine is uniquely identified by an snmpEngineID value [RFC3411]. An SNMP entity, which consists of an SNMP engine and several SNMP applications, may provide access to multiple contexts.
在管理域中，SNMP引擎由snmpEngineID值[RFC3411]唯一标识。由一个SNMP引擎和几个SNMP应用程序组成的SNMP实体可以提供对多个上下文的访问。
An SNMP context is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context and an SNMP entity potentially has access to many contexts [RFC3411]. A context is identified by the snmpEngineID value of the entity hosting the management information (also called a contextEngineID) and a context name that identifies the specific context (also called a contextName).
SNMP上下文是可由SNMP实体访问的管理信息的集合。一项管理信息可能存在于多个上下文中，SNMP实体可能可以访问多个上下文[RFC3411]。上下文由托管管理信息的实体的snmpEngineID值（也称为contextEngineID）和标识特定上下文的上下文名称（也称为contextName）标识。
To identify an individual item of management information within an administrative domain, a four tuple is used consisting of
要标识管理域中的单个管理信息项，使用四元组，包括
1. a contextEngineID,
1. 一个contextEngineID，
2. a contextName,
2. 上下文名称，
3. an object type, and
3. 对象类型，以及
4. its instance identification.
4. 它的实例识别。
The last two elements are encoded in an object identifier (OID) value. The contextName is a character string (following the SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB [RFC3411]) while the contextEngineID is an octet string constructed according to the rules defined as part of the SnmpEngineID textual convention of the SNMP-FRAMEWORK-MIB [RFC3411].
最后两个元素编码为对象标识符（OID）值。contextName是一个字符串（遵循SNMP-FRAMEWORK-MIB[RFC3411]的SNMPAdminInstalling文本约定），而contextEngineID是根据SNMP-FRAMEWORK-MIB[RFC3411]的SnmpEngineID文本约定中定义的规则构造的八位字符串。
The SNMP protocol operations and the protocol data units (PDUs) operate on OIDs and thus deal with object types and instances [RFC3416]. The SNMP architecture [RFC3411] introduces the concept of a scopedPDU as a data structure containing a contextEngineID, a contextName, and a PDU. The SNMP version 3 (SNMPv3) message format uses ScopedPDUs to exchange management information [RFC3412].
SNMP协议操作和协议数据单元（PDU）在OID上运行，因此处理对象类型和实例[RFC3416]。SNMP体系结构[RFC3411]引入了scopedPDU的概念，作为包含contextEngineID、contextName和PDU的数据结构。SNMP版本3（SNMPv3）消息格式使用ScopedPDU交换管理信息[RFC3412]。
Within the SNMP framework, contextEngineIDs serve as end-to-end identifiers. This becomes important in situations where SNMP proxies are deployed to translate between protocol versions or to cross middleboxes such as network address translators. In addition, snmpEngineIDs separate the identification of an SNMP engine from the transport addresses used to communicate with an SNMP engine. This property can be used to correlate management information easily, even in situations where multiple different transports were used to retrieve the information or where transport addresses can change dynamically.
在SNMP框架内，ContextEngineID充当端到端标识符。在部署SNMP代理以在协议版本之间进行转换或跨网络地址转换器等中间盒的情况下，这一点变得非常重要。此外，snmpengineid将SNMP引擎的标识与用于与SNMP引擎通信的传输地址分开。此属性可用于轻松关联管理信息，即使在使用多个不同的传输来检索信息或传输地址可以动态更改的情况下也是如此。
To retrieve data from an SNMPv3 agent, it is necessary to know the appropriate contextEngineID. The User-based Security Model (USM) of SNMPv3 provides a mechanism to discover the snmpEngineID of the remote SNMP engine, since this is needed for security processing reasons. The discovered snmpEngineID can subsequently be used as a contextEngineID in a ScopedPDU to access management information local to the remote SNMP engine. Other security models, such as the Transport Security Model (TSM) [TSM], lack such a procedure and may use the discovery mechanism defined in this memo.
要从SNMPv3代理检索数据，需要知道适当的contextEngineID。SNMPv3的基于用户的安全模型（USM）提供了一种机制来发现远程SNMP引擎的snmpEngineID，因为出于安全处理的原因需要这样做。发现的snmpEngineID随后可以用作ScopedPDU中的contextEngineID，以访问远程SNMP引擎的本地管理信息。其他安全模型，如传输安全模型（TSM）[TSM]，缺少这样的过程，可能会使用本备忘录中定义的发现机制。
The proposed discovery mechanism consists of two parts, namely (i) the definition of a special well-known snmpEngineID value, called the localEngineID, which always refers to a local default context, and (ii) the definition of a procedure to acquire the snmpEngineID scalar of the SNMP-FRAMEWORK-MIB [RFC3411] using the special well-known local localEngineID value.
建议的发现机制由两部分组成，即（i）一个称为localEngineID的特殊已知snmpEngineID值的定义，该值始终引用本地默认上下文，以及（ii）一个用于获取SNMP-FRAMEWORK-MIB[RFC3411]的snmpEngineID标量的过程的定义使用特殊的已知本地localEngineID值。
An SNMP command responder implementing this specification MUST register their pduTypes using the localEngineID snmpEngineID value (defined below) by invoking the registerContextEngineID() Abstract Service Interface (ASI) defined in RFC 3412 [RFC3412]. This registration is done in addition to the normal registration under the SNMP engine's snmpEngineID. This is consistent with the SNMPv3 specifications since they explicitly allow registration of multiple engineIDs and multiple pduTypes [RFC3412].
实现此规范的SNMP命令响应程序必须通过调用RFC 3412[RFC3412]中定义的registerContextEngineID（）抽象服务接口（ASI），使用localEngineID snmpEngineID值（定义如下）注册其PDUType。此注册是在SNMP引擎的snmpEngineID下的正常注册之外完成的。这与SNMPv3规范一致，因为它们明确允许注册多个EngineID和多个PDUType[RFC3412]。
The SnmpEngineID textual convention [RFC3411] defines that an snmpEngineID value MUST be between 5 and 32 octets long. This specification proposes to use the variable length format 3) of the SnmpEngineID textual convention and to allocate the reserved, unused format value 6, using the enterprise ID 0 for the localEngineID. An ASN.1 definition for localEngineID would look like this:
SnmpEngineID文本约定[RFC3411]定义SnmpEngineID值的长度必须在5到32个八位字节之间。本规范建议使用SnmpEngineID文本约定的可变长度格式（3），并使用企业ID 0为localEngineID分配保留的、未使用的格式值6。localEngineID的ASN.1定义如下所示：
localEngineID OCTET STRING ::= '8000000006'H
localEngineID OCTET STRING ::= '8000000006'H
The localEngineID value always provides access to the default context of an SNMP engine. Note that the localEngineID value is intended to be used as a special value for the contextEngineID field in the ScopedPDU. It MUST NOT be used as a value to identify an SNMP engine; that is, this value MUST NOT be used in the snmpEngineID.0 scalar [RFC3418] or in the msgAuthoritativeEngineID field in the securityParameters of the User-based Security Model (USM) [RFC3414].
localEngineID值始终提供对SNMP引擎的默认上下文的访问。请注意，localEngineID值旨在用作ScopedPDU中contextEngineID字段的特殊值。不得将其用作标识SNMP引擎的值；也就是说，此值不得用于snmpEngineID.0标量[RFC3418]或基于用户的安全模型（USM）[RFC3414]的securityParameters中的MsgAuthoritativeEngineinId字段。
Discovery of the snmpEngineID is done by sending a Read Class protocol operation (see Section 2.8 of [RFC3411]) to retrieve the snmpEngineID scalar using the localEngineID defined above as a contextEngineID value. Implementations SHOULD only perform this discovery step when it is needed. In particular, if security models are used that already discover the remote snmpEngineID (such as USM), then no further discovery is necessary. The same is true in situations where the application already knows a suitable snmpEngineID value.
snmpEngineID的发现是通过发送读取类协议操作（参见[RFC3411]的第2.8节）来完成的，以使用上面定义为contextEngineID值的localEngineID检索snmpEngineID标量。实现应仅在需要时执行此发现步骤。特别是，如果使用的安全模型已经发现了远程snmpEngineID（如USM），则无需进一步发现。在应用程序已经知道合适的snmpEngineID值的情况下也是如此。
The procedure to discover the snmpEngineID of a remote SNMP engine can be described as follows:
查找远程SNMP引擎的snmpEngineID的过程可以描述如下：
1. Check whether a suitable contextEngineID value is already known. If yes, use the provided contextEngineID value and stop the discovery procedure.
1. 检查是否已经知道合适的contextEngineID值。如果是，请使用提供的contextEngineID值并停止查找过程。
2. Check whether the selected security model supports discovery of the remote snmpEngineID (e.g., USM with its discovery mechanism). If yes, let the security model perform the discovery. If the remote snmpEngineID value has been successfully determined, assign it to the contextEngineID and stop the discovery procedure.
2. 检查所选安全模型是否支持发现远程snmpEngineID（例如，USM及其发现机制）。如果是，让安全模型执行发现。如果已成功确定远程snmpEngineID值，请将其分配给contextEngineID并停止发现过程。
3. Send a Read Class operation to the remote SNMP engine using the localEngineID value as the contextEngineID in order to retrieve the scalar snmpEngineID.0 of the SNMP-FRAMEWORK-MIB [RFC3411]. If successful, set the contextEngineID to the retrieved value and stop the discovery procedure.
3. 使用localEngineID值作为contextEngineID向远程SNMP引擎发送读取类操作，以检索SNMP-FRAMEWORK-MIB[RFC3411]的标量snmpEngineID.0。如果成功，请将contextEngineID设置为检索到的值并停止发现过程。
4. Return an error indication that a suitable contextEngineID could not be discovered.
4. 返回一个错误指示，表明无法找到合适的contextEngineID。
The procedure outlined above is an example and can be modified to retrieve more variables in step 3, such as the sysObjectID.0 scalar or the snmpSetSerialNo.0 scalar of the SNMPv2-MIB [RFC3418].
上面概述的过程是一个示例，可以修改以在步骤3中检索更多变量，例如SNMPv2 MIB[RFC3418]的sysObjectID.0标量或snmpSetSerialNo.0标量。
RFC 3411 requested that IANA create a registry for SnmpEngineID formats. However, RFC 3411 did not ask IANA to record the initial assignments made by RFC 3411 nor did RFC 3411 spell out the precise allocation rules. To address this issue, the following rules are hereby established.
RFC 3411要求IANA为SnmpEngineID格式创建一个注册表。然而，RFC 3411没有要求IANA记录RFC 3411的初始分配，也没有说明精确的分配规则。为解决此问题，特此制定以下规则。
IANA maintains a registry for SnmpEngineID formats. The first four octets of an SnmpEngineID carry an enterprise number, while the fifth octet in a variable length SnmpEngineID value, called the format octet, indicates how the following octets are formed. The following format values were allocated in [RFC3411]:
IANA维护SnmpEngineID格式的注册表。SnmpEngineID的前四个八位字节携带一个企业编号，而可变长度SnmpEngineID值中的第五个八位字节（称为格式八位字节）指示以下八位字节的形成方式。[RFC3411]中分配了以下格式值：
Format Description References
------- ----------- ----------
0 reserved, unused [RFC3411]
1 IPv4 address [RFC3411]
2 IPv6 address [RFC3411]
3 MAC address [RFC3411]
4 administratively assigned text [RFC3411]
5 administratively assigned octets [RFC3411]
6-127 reserved, unused [RFC3411]
128-255 enterprise specific [RFC3411]
Format Description References
------- ----------- ----------
0 reserved, unused [RFC3411]
1 IPv4 address [RFC3411]
2 IPv6 address [RFC3411]
3 MAC address [RFC3411]
4 administratively assigned text [RFC3411]
5 administratively assigned octets [RFC3411]
6-127 reserved, unused [RFC3411]
128-255 enterprise specific [RFC3411]
IANA can assign new format values out of the originally assigned and reserved number space 1-127. For new assignments in this number
IANA可以从最初分配和保留的数字空间1-127中分配新的格式值。对于此号码的新作业
space, a specification is required as per [RFC5226]. The number space 128-255 is enterprise specific and is not controlled by IANA.
空间，需要符合[RFC5226]的规范。数字空间128-255是特定于企业的，不受IANA控制。
Per this document, IANA has made the following assignment:
根据本文件，IANA已完成以下任务：
Format Description References
------- ----------- ----------
6 local engine [RFC5343]
Format Description References
------- ----------- ----------
6 local engine [RFC5343]
SNMP version 3 (SNMPv3) provides cryptographic security to protect devices from unauthorized access. This specification recommends use of the security services provided by SNMPv3. In particular, it is RECOMMENDED to protect the discovery exchange.
SNMP版本3（SNMPv3）提供加密安全性，以保护设备免受未经授权的访问。本规范建议使用SNMPv3提供的安全服务。特别是，建议保护discovery exchange。
An snmpEngineID can contain information such as a device's MAC address, IPv4 address, IPv6 address, or administratively assigned text. An attacker located behind a router / firewall / network address translator may not be able to obtain this information directly, and he therefore might discover snmpEngineID values in order to obtain this kind of device information.
snmpEngineID可以包含设备的MAC地址、IPv4地址、IPv6地址或管理分配的文本等信息。位于路由器/防火墙/网络地址转换器后面的攻击者可能无法直接获取此信息，因此他可能会发现snmpEngineID值以获取此类设备信息。
In many environments, making snmpEngineID values accessible via a security level of noAuthNoPriv will benefit legitimate tools that try to algorithmically determine some basic information about a device. For this reason, the default View-based Access Control Model (VACM) configuration in Appendix A of RFC 3415 [RFC3415] gives noAuthNoPriv read access to the snmpEngineID. Furthermore, the USM discovery mechanism defined in RFC 3414 [RFC3414] uses unprotected messages and reveals snmpEngineID values.
在许多环境中，通过noAuthNoPriv的安全级别访问snmpEngineID值将有助于合法的工具，这些工具试图通过算法确定设备的一些基本信息。因此，RFC 3415[RFC3415]附录A中的默认基于视图的访问控制模型（VACM）配置为snmpEngineID提供了noAuthNoPriv读取访问权限。此外，RFC 3414[RFC3414]中定义的USM发现机制使用未受保护的消息并显示snmpEngineID值。
In highly secure environments, snmpEngineID values can be protected by using the discovery mechanism described in this document together with a security model that does not exchange cleartext SNMP messages, such as the Transport Security Model (TSM) [TSM].
在高度安全的环境中，可以通过使用本文档中描述的发现机制以及不交换明文SNMP消息的安全模型（如传输安全模型（TSM）[TSM]）来保护snmpEngineID值。
The isAccessAllowed() abstract service primitive of the SNMP access control subsystem does not take the contextEngineID into account when checking access rights [RFC3411]. As a consequence, it is not possible to define a special view for context engineID discovery. A request with a localEngineID is thus treated like a request with the correct snmpEngineID by the access control subsystem. This is inline with the SNMPv3 design where the authenticated identity is the securityName (together with the securityModel and securityLevel information), and transport addresses or knowledge of contextEngineID values do not impact the access-control decision.
SNMP访问控制子系统的isAccessAllowed（）抽象服务原语在检查访问权限[RFC3411]时不考虑contextEngineID。因此，不可能为context engineID发现定义特殊视图。因此，访问控制子系统将具有localEngineID的请求视为具有正确snmpEngineID的请求。这与SNMPv3设计是一致的，其中经过身份验证的标识是securityName（以及securityModel和securityLevel信息），传输地址或contextEngineID值的知识不会影响访问控制决策。
Dave Perkins suggested the introduction of a "local" contextEngineID during the interim meeting of the ISMS (Integrated Security Model for SNMP) working group in Boston, 2006. Joe Fernandez, David Harrington, Dan Romascanu, and Bert Wijnen provided helpful review and feedback, which helped to improve this document.
Dave Perkins在2006年于波士顿召开的ISMS（SNMP集成安全模型）工作组临时会议上建议引入“本地”contextEngineID。Joe Fernandez、David Harrington、Dan Romascanu和Bert Wijnen提供了有用的回顾和反馈，这有助于改进本文档。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412]Case，J.，Harrington，D.，Presohn，R.，和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，STD 62，RFC 3412，2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）版本3的基于用户的安全模型（USM）”，STD 62，RFC 3414，2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，“简单网络管理协议（SNMP）协议操作的第2版”，STD 62，RFC 3416，2002年12月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418]Presohn，R.，“简单网络管理协议（SNMP）的管理信息库（MIB）”，STD 62，RFC 3418，2002年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[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月。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415]Wijnen，B.，Presuhn，R.，和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[TSM] Harrington, D., "Transport Security Model for SNMP", Work in Progress, July 2008.
[TSM]Harrington，D.，“SNMP的传输安全模型”，正在进行的工作，2008年7月。
Author's Address
作者地址
Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany
德国不来梅大学校园环128725
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Phone: +49 421 200-3587
EMail: j.schoenwaelder@jacobs-university.de
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.