Network Working Group D. Black
Request for Comments: 4088 EMC Corporation
Category: Standards Track K. McCloghrie
Cisco Systems
J. Schoenwaelder
International University Bremen
June 2005
Network Working Group D. Black
Request for Comments: 4088 EMC Corporation
Category: Standards Track K. McCloghrie
Cisco Systems
J. Schoenwaelder
International University Bremen
June 2005
Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
简单网络管理协议（SNMP）的统一资源标识符（URI）方案
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The Simple Network Management Protocol (SNMP) and the Internet Standard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access (including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform Resource Identifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols.
简单网络管理协议（SNMP）和Internet标准管理框架广泛用于通信设备的管理，因此需要从非SNMP管理环境中指定SNMP访问（包括对SNMP MIB对象实例的访问）。例如，当通过单独的管理接口使用带外IP管理时（例如，对于不支持带内IP访问的设备），需要一种统一的方式来指示如何联系设备进行管理。统一资源标识符（URI）很好地满足了这一需求，因为它们允许单个文本字符串来指示各种基于IP的协议的管理访问通信端点。
This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances.
本文档定义了一个URI方案，以便可以将SNMP指定为用于管理的协议。该方案还允许URI指定一个或多个MIB对象实例。
Table of Contents
目录
1. Introduction.................................................. 2
2. Usage......................................................... 3
3. Syntax of an SNMP URI......................................... 4
3.1. Relative Reference Considerations........................ 5
4. Semantics and Operations...................................... 6
4.1. SNMP Service URIs........................................ 6
4.2. SNMP Object URIs......................................... 7
4.2.1. SNMP Object URI Data Access....................... 8
4.3. OID Groups in SNMP URIs.................................. 10
4.4. Interoperability Considerations.......................... 10
5. Examples...................................................... 11
6. Security Considerations....................................... 12
6.1. SNMP URI to SNMP Gateway Security Considerations......... 13
7. IANA Considerations........................................... 14
8. Normative References.......................................... 14
9. Informative References........................................ 15
10. Acknowledgements............................................. 16
Appendix A. Registration Template................................ 17
1. Introduction.................................................. 2
2. Usage......................................................... 3
3. Syntax of an SNMP URI......................................... 4
3.1. Relative Reference Considerations........................ 5
4. Semantics and Operations...................................... 6
4.1. SNMP Service URIs........................................ 6
4.2. SNMP Object URIs......................................... 7
4.2.1. SNMP Object URI Data Access....................... 8
4.3. OID Groups in SNMP URIs.................................. 10
4.4. Interoperability Considerations.......................... 10
5. Examples...................................................... 11
6. Security Considerations....................................... 12
6.1. SNMP URI to SNMP Gateway Security Considerations......... 13
7. IANA Considerations........................................... 14
8. Normative References.......................................... 14
9. Informative References........................................ 15
10. Acknowledgements............................................. 16
Appendix A. Registration Template................................ 17
SNMP and the Internet-Standard Management Framework were originally devised to manage IP devices via in-band means, in which management access is primarily via the same interface(s) used to send and receive IP traffic. SNMP's wide adoption has resulted in its use for managing communication devices that do not support in-band IP access (e.g., Fibre Channel devices); a separate out-of-band IP interface is often used for management. URIs provide a convenient way to locate that interface and specify the protocol to be used for management; one possible scenario is for an in-band query to return a URI that indicates how the device is managed. This document specifies a URI scheme to permit SNMP (including a specific SNMP context) to be designated as the management protocol by such a URI. This scheme also allows a URI to refer to specific object instances within an SNMP MIB.
SNMP和Internet标准管理框架最初设计用于通过带内方式管理IP设备，其中管理访问主要通过用于发送和接收IP流量的相同接口。SNMP的广泛采用导致其用于管理不支持带内IP访问的通信设备（例如，光纤通道设备）；通常使用单独的带外IP接口进行管理。URI提供了一种方便的方法来定位该接口并指定用于管理的协议；一种可能的情况是，带内查询返回一个URI，该URI指示如何管理设备。本文档指定了一个URI方案，以允许通过这样的URI将SNMP（包括特定的SNMP上下文）指定为管理协议。此方案还允许URI引用SNMP MIB中的特定对象实例。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅[RFC3410]第7节。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
There are two major classes of SNMP URI usage: configuration and gateways between SNMP and other protocols that use SNMP URIs.
SNMP URI的使用主要有两类：配置和SNMP与使用SNMP URI的其他协议之间的网关。
An SNMP URI used for configuration indicates the location of management information as part of the configuration of an application containing an SNMP manager. The URI can be obtained from a configuration file or may be provided by a managed device (see Section 1 for an example). Management information is exchanged between the SNMP manager and agent, but it does not flow beyond the manager, as shown in the following diagram:
用于配置的SNMP URI指示管理信息的位置，作为包含SNMP管理器的应用程序配置的一部分。URI可以从配置文件获得，也可以由受管设备提供（示例见第1节）。管理信息在SNMP管理器和代理之间交换，但不会超出管理器，如下图所示：
*********** SNMP-Request *********
* *================>* *
URI ---------->* Manager * * Agent *
* *<================* *
*********** SNMP-Response *********
^
|
Other Config Info ------------+
*********** SNMP-Request *********
* *================>* *
URI ---------->* Manager * * Agent *
* *<================* *
*********** SNMP-Response *********
^
|
Other Config Info ------------+
Additional configuration information (e.g., a security secret or key) may be provided via an interface other than that used for the URI. For example, when a managed device provides an SNMP URI in an unprotected fashion, that device should not provide a secret or key required to use the URI. The secret or key should instead be pre-configured in or pre-authorized to the manager; see Section 6.
附加配置信息（例如，安全秘密或密钥）可通过用于URI的接口以外的接口提供。例如，当受管设备以不受保护的方式提供SNMP URI时，该设备不应提供使用该URI所需的机密或密钥。相反，应在管理者中预先配置或预先授权该秘密或密钥；见第6节。
For gateway usage, clients employ SNMP URIs to request management information via an SNMP URI to SNMP gateway (also called an SNMP gateway in this document). The SNMP manager within the SNMP gateway accesses the management information and returns it to the requesting client, as shown in the following diagram:
对于网关使用，客户端使用SNMP URI通过SNMP URI向SNMP网关（在本文档中也称为SNMP网关）请求管理信息。SNMP网关中的SNMP管理器访问管理信息并将其返回给请求客户端，如下图所示：
SNMP gateway
********** URI *********** SNMP-Request *********
* *===========>* *================>* *
* Client * * Manager * * Agent *
* *<===========* *<================* *
********** Info *********** SNMP-Response *********
^
|
Other Config Info ------------+
SNMP gateway
********** URI *********** SNMP-Request *********
* *===========>* *================>* *
* Client * * Manager * * Agent *
* *<===========* *<================* *
********** Info *********** SNMP-Response *********
^
|
Other Config Info ------------+
Additional configuration information (e.g., security secrets or keys) may be provided via an interface other than that used for the URI. For example, some types of security information, including secrets
附加配置信息（例如，安全秘密或密钥）可通过用于URI的接口以外的接口提供。例如，某些类型的安全信息，包括机密
and keys, should be pre-configured in or pre-authorized to the manager rather than be provided by the client; see Section 6.
和密钥，应在经理处预先配置或预先授权给经理，而不是由客户提供；见第6节。
An SNMP URI has the following ABNF [RFC2234] syntax, based on the ABNF syntax rules for userinfo, host, port, and (path) segment in [RFC3986] and the ABNF syntax rule for HEXDIG in [RFC2234]:
基于[RFC3986]中用户信息、主机、端口和（路径）段的ABNF语法规则和[RFC2234]中HEXDIG的ABNF语法规则，SNMP URI具有以下ABNF[RFC2234]语法：
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
snmp-uri = "snmp://" snmp-authority [ context [ oids ]]
snmp-authority = [ securityName "@" ] host [ ":" port ]
securityName = userinfo ; SNMP securityName
snmp-authority = [ securityName "@" ] host [ ":" port ]
securityName = userinfo ; SNMP securityName
context = "/" contextName [ ";" contextEngineID ]
contextName = segment ; SNMP contextName
contextEngineID = 1*(HEXDIG HEXDIG) ; SNMP contextEngineID
context = "/" contextName [ ";" contextEngineID ]
contextName = segment ; SNMP contextName
contextEngineID = 1*(HEXDIG HEXDIG) ; SNMP contextEngineID
oids = "/" ( oid / oid-group ) [ suffix ]
oid-group = "(" oid *( "," oid ) ")"
oid = < as specified by [RFC 3061] >
suffix = "+" / ".*"
oids = "/" ( oid / oid-group ) [ suffix ]
oid-group = "(" oid *( "," oid ) ")"
oid = < as specified by [RFC 3061] >
suffix = "+" / ".*"
The userinfo and (path) segment ABNF rules are reused for syntax only. In contrast, host and port have both the syntax and semantics specified in [RFC3986]. See [RFC3411] for the semantics of securityName, contextEngineID, and contextName.
userinfo和（path）段ABNF规则仅用于语法。相反，主机和端口具有[RFC3986]中指定的语法和语义。有关securityName、contextEngineID和contextName的语义，请参见[RFC3411]。
The snmp-authority syntax matches the URI authority syntax in Section 3.2 of [RFC3986], with the additional restriction that the userinfo component of an authority (when present) MUST be an SNMP securityName. If the securityName is empty or not given, the entity making use of an SNMP URI is expected to know what SNMP securityName to use if one is required. Inclusion of authentication information (e.g., passwords) in URIs has been deprecated (see Section 3.2.1 of [RFC3986]), so any secret or key required for SNMP access must be provided via other means that may be out-of-band with respect to communication of the URI. If the port is empty or not given, port 161 is assumed.
snmp授权语法与[RFC3986]第3.2节中的URI授权语法相匹配，并附加限制，即授权的userinfo组件（如果存在）必须是snmp securityName。如果securityName为空或未给定，则使用SNMP URI的实体应知道在需要时要使用哪个SNMP securityName。不赞成在URI中包含身份验证信息（如密码）（见[RFC3986]第3.2.1节），因此必须通过其他方式提供SNMP访问所需的任何机密或密钥，这些方式可能与URI的通信无关。如果端口为空或未给定，则假定端口161。
If the contextName is empty or not given, the zero-length string ("") is assumed, as it is the default SNMP context. An SNMP contextEngineID is a variable-format binary element that is usually discovered by an SNMP manager. An SNMP URI encodes a contextEngineID as hexadecimal digits corresponding to a sequence of bytes. If the contextEngineID is empty or not given, the context engine is to be discovered by querying the SNMP agent at the specified host and port; see Section 4.1 below. The contextEngineID component of the URI
如果contextName为空或未给定，则假定长度为零的字符串（“”），因为它是默认的SNMP上下文。SNMP contextEngineID是一种可变格式的二进制元素，通常由SNMP管理器发现。SNMP URI将contextEngineID编码为对应于字节序列的十六进制数字。如果contextEngineID为空或未给定，则通过查询指定主机和端口上的SNMP代理来发现上下文引擎；见下文第4.1节。URI的contextEngineID组件
SHOULD be present if more than one context engine at the designated host and port supports the designated context.
如果指定主机和端口上有多个上下文引擎支持指定的上下文，则应存在。
An SNMP URI that designates the default SNMP context ("") MAY end with the "/" character that introduces the contextName component. An SNMP URI MUST NOT end with the "/" character that introduces an oid or oid-group component, as the empty string is not a valid OID for SNMP.
指定默认SNMP上下文（“”）的SNMP URI可能以引入contextName组件的“/”字符结尾。SNMP URI不得以引入oid或oid组组件的“/”字符结尾，因为空字符串不是SNMP的有效oid。
The encoding rules specified in [RFC3986] MUST be used for SNMP URIs, including the use of percent encoding ("%" followed by two hex digits) as needed to represent characters defined as reserved in [RFC3986] and any characters not allowed in a URI. SNMP permits any UTF-8 character to be used in a securityName or contextName; all multi-byte UTF-8 characters in an SNMP URI MUST be percent encoded as specified in Sections 2.1 and 2.5 of [RFC3986]. These requirements are a consequence of reusing the ABNF syntax rules for userinfo and segment from [RFC3986].
[RFC3986]中指定的编码规则必须用于SNMP URI，包括根据需要使用百分比编码（“%”后跟两个十六进制数字），以表示在[RFC3986]中定义为保留的字符以及URI中不允许的任何字符。SNMP允许在securityName或contextName中使用任何UTF-8字符；SNMP URI中的所有多字节UTF-8字符必须按照[RFC3986]第2.1节和第2.5节的规定进行百分比编码。这些要求是重用[RFC3986]中userinfo和段的ABNF语法规则的结果。
SNMP URIs will generally be short enough to avoid implementation string-length limits (e.g., that may occur at 255 characters). Such limits may be a concern for large OID groups; relative references to URIs (see Section 4.2 of [RFC3986]) may provide an alternative in some circumstances.
SNMP URI通常足够短，以避免实现字符串长度限制（例如，可能出现在255个字符处）。此类限制可能是大型OID群体关注的问题；在某些情况下，对URI的相对引用（见[RFC3986]第4.2节）可提供替代方案。
Use of IP addresses in SNMP URIs is acceptable in situations where dependence on availability of DNS service is undesirable or must be avoided; otherwise, IP addresses should not be used (see [RFC1900] for further explanation).
在不希望或必须避免依赖DNS服务可用性的情况下，可以在SNMP URI中使用IP地址；否则，不应使用IP地址（有关详细说明，请参阅[RFC1900]）。
Use of the SNMP default context (zero-length string) within an SNMP URI can result in a second instance of "//" in the URI, such as the following:
在SNMP URI中使用SNMP默认上下文（零长度字符串）会导致URI中出现第二个“/”实例，例如：
snmp://<host>//<oid>
snmp://<host>//<oid>
This is allowed by [RFC3986] syntax; if a URI parser does not handle the second "//" correctly, the parser is broken and needs to be fixed. This example is important because use of the SNMP default context in SNMP URIs is expected to be common.
[RFC3986]语法允许这样做；如果URI解析器没有正确处理第二个“/”，则该解析器已损坏，需要修复。这个例子很重要，因为在SNMP URI中使用SNMP默认上下文是很常见的。
On the other hand, the second occurrence of "//" in an absolute SNMP URI affects usage of relative references to that URI (see Section 4.2 of [RFC3986]) because a "//" at the start of a relative reference always introduces a URI authority component (host plus optional userinfo and/or port; see [RFC3986]). Specifically, a relative
另一方面，绝对SNMP URI中第二次出现“/”会影响对该URI的相对引用的使用（请参见[RFC3986]第4.2节），因为相对引用开头的“/”总是引入URI授权组件（主机加上可选的用户信息和/或端口；请参见[RFC3986]）。特别是一个亲戚
reference of the form //<oid2> will not work, because the "//" will cause <oid2> to be parsed as a URI authority, resulting in a syntax error when the parser fails to find a host in <oid2> . To avoid this problem, relative references that start with "//" but do not contain a URI authority component MUST NOT be used. Functionality equivalent to any such forbidden relative reference can be obtained by prefixing "." or ".." to the forbidden relative reference (e.g., ..//<oid2>). The prefix to use depends on the base URI.
表单/<oid2>的引用将不起作用，因为“/”将导致<oid2>被解析为URI授权，当解析器在<oid2>中找不到主机时，将导致语法错误。为避免此问题，不得使用以“/”开头但不包含URI授权组件的相对引用。通过在禁止相对引用前加“.”或“.”可获得与任何此类禁止相对引用等效的功能（例如，../<oid2>）。要使用的前缀取决于基本URI。
An SNMP URI that does not include any OIDs is called an SNMP service URI because it designates a communication endpoint for access to SNMP management service. An SNMP URI that includes one or more OIDs is called an SNMP object URI because it designates one or more object instances in an SNMP MIB. The expected means of using an SNMP URI is to employ an SNMP manager to access the SNMP context designated by the URI via the SNMP agent at the host and port designated by the URI.
不包含任何OID的SNMP URI称为SNMP服务URI，因为它指定了访问SNMP管理服务的通信端点。包含一个或多个OID的SNMP URI称为SNMP对象URI，因为它在SNMP MIB中指定一个或多个对象实例。使用SNMP URI的预期方法是使用SNMP管理器通过URI指定的主机和端口上的SNMP代理访问URI指定的SNMP上下文。
An SNMP service URI does not designate a data object, but rather an SNMP context to be accessed by a service; the telnet URI scheme [RFC1738] is another example of URIs that designate service access. If the contextName in the URI is empty or not given, "" (the zero-length string) is assumed, as it is the default SNMP context.
SNMP服务URI不指定数据对象，而是指定服务要访问的SNMP上下文；telnet URI方案[RFC1738]是指定服务访问的URI的另一个示例。如果URI中的contextName为空或未给定“”（长度为零的字符串），因为它是默认的SNMP上下文。
If a contextEngineID is given in an SNMP service URI, the context engine that it designates is to be used. If the contextEngineID is empty or not given in the URI, the context engine is to be discovered; the context engine to be used is the one that supports the context designated by the URI. The contextEngineID component of the URI SHOULD be present if more than one context engine at the designated host and port supports the designated context.
如果在SNMP服务URI中提供了contextEngineID，则将使用它指定的上下文引擎。如果contextEngineID为空或未在URI中给出，则将发现上下文引擎；要使用的上下文引擎是支持URI指定的上下文的引擎。如果指定主机和端口上有多个上下文引擎支持指定的上下文，则应该存在URI的contextEngineID组件。
Many common uses of SNMP URIs are expected to omit (i.e., default) the contextEngineID because they do not involve SNMP proxy agents, which are the most common reason for multiple SNMP context engines to exist at a single host and port. Specifically, when an SNMP agent is local to the network interface that it manages, the agent will usually have only one context engine, in which case it is safe to omit the contextEngineID component of an SNMP URI. In addition, many SNMP agents that are local to a network interface support only the default SNMP context (zero-length string).
SNMP URI的许多常见用途预计会省略（即默认）contextEngineID，因为它们不涉及SNMP代理，这是多个SNMP上下文引擎在单个主机和端口上存在的最常见原因。具体地说，当SNMP代理位于其管理的网络接口的本地时，该代理通常只有一个上下文引擎，在这种情况下，省略SNMP URI的contextEngineID组件是安全的。此外，许多网络接口本地的SNMP代理仅支持默认的SNMP上下文（零长度字符串）。
An SNMP object URI contains one or more OIDs. The URI is used by first separating the OID or OID group (including its preceding slash plus any parentheses and suffix) and then processing the resulting SNMP service URI as specified in Section 4.1 (above) to determine the SNMP context to be accessed. The OID or OID group is then used to generate SNMP operations directed to that SNMP context.
SNMP对象URI包含一个或多个OID。URI的使用方法是首先分离OID或OID组（包括其前面的斜杠加上任何括号和后缀），然后按照第4.1节（上文）的规定处理生成的SNMP服务URI，以确定要访问的SNMP上下文。然后使用OID或OID组生成指向该SNMP上下文的SNMP操作。
The semantics of an SNMP object URI depend on whether the OID or OID group has a suffix and what that suffix is. There are three possible formats; in each case, the MIB object instances are designated within the SNMP context specified by the service URI portion of the SNMP object URI. The semantics of an SNMP object URI that contains a single OID are as follows:
SNMP对象URI的语义取决于OID或OID组是否具有后缀以及该后缀是什么。有三种可能的格式；在每种情况下，MIB对象实例都在SNMP对象URI的服务URI部分指定的SNMP上下文中指定。包含单个OID的SNMP对象URI的语义如下所示：
(1) An OID without a suffix designates the MIB object instance named by the OID.
(1) 没有后缀的OID指定由OID命名的MIB对象实例。
(2) An OID with a "+" suffix designates the lexically next MIB object instance following the OID.
(2) 带有“+”后缀的OID指定OID后面的下一个MIB对象实例。
(3) An OID with a ".*" suffix designates the set of MIB object instances for which the OID is a strict lexical prefix; this does not include the MIB object instance named by the OID.
(3) 带有“*”后缀的OID指定一组MIB对象实例，OID是严格的词法前缀；这不包括OID命名的MIB对象实例。
An OID group in an SNMP URI consists of a set of OIDs in parentheses. In each case, the OID group semantics are the extension of the single OID semantics to each OID in the group (e.g., a URI with a "+" suffix designates the set of MIB object instances consisting of the lexically next instance for each OID in the OID group).
SNMP URI中的OID组由括号中的一组OID组成。在每种情况下，OID组语义都是单个OID语义对组中每个OID的扩展（例如，带有“+”后缀的URI指定由OID组中每个OID的词汇下一个实例组成的MIB对象实例集）。
When there is a choice among URI formats to designate the same MIB object instance or instances, the above list is in order of preference (no suffix is most preferable), as it runs from most precise to least precise. This is because an OID without a suffix precisely designates an object instance, whereas a "+" suffix designates the next object instance, which may change, and the ".*" suffix could designate multiple object instances. Multiple syntactically distinct SNMP URIs SHOULD NOT be used to designate the same MIB object instance or set of instances, as this may cause unexpected results in URI-based systems that use string comparison to test URIs for equality.
当在URI格式中选择指定同一个或多个MIB对象实例时，上面的列表按优先顺序排列（最好没有后缀），因为它从最精确到最不精确。这是因为没有后缀的OID精确地指定了一个对象实例，而“+”后缀指定了下一个对象实例，这可能会改变，“*”后缀可以指定多个对象实例。不应使用多个语法不同的SNMP URI来指定同一MIB对象实例或实例集，因为这可能会在使用字符串比较测试URI是否相等的基于URI的系统中导致意外结果。
SNMP object URIs designate the data to be accessed, as opposed to the specific SNMP operations to be used for access; Section 4.2.1 provides examples of how SNMP operations can be used to access data for SNMP object URIs. Nonetheless, any applicable SNMP operation,
SNMP对象URI指定要访问的数据，而不是用于访问的特定SNMP操作；第4.2.1节提供了如何使用SNMP操作访问SNMP对象URI数据的示例。尽管如此，任何适用的SNMP操作，
including GetBulk, MAY be used to access data for all or part of one or more SNMP object URIs (e.g., via use of multiple variable bindings in a single operation); it is not necessary to use the specific operations described in Section 4.2.1 as long as the results (returned variable bindings or error) could have been obtained by following Section 4.2.1's descriptions. The use of relative references that do not change the contextName (i.e., ./<oid>) should be viewed as a hint that optimization of SNMP access across multiple SNMP URIs may be possible.
包括GetBulk，可用于访问一个或多个SNMP对象URI的全部或部分数据（例如，通过在单个操作中使用多个变量绑定）；无需使用第4.2.1节中描述的特定操作，只要结果（返回的变量绑定或错误）可以通过遵循第4.2.1节的描述获得。使用不改变contextName的相对引用（即，./<oid>）应被视为一种提示，即可以跨多个SNMP URI优化SNMP访问。
An SNMP object URI MAY also be used to specify a MIB object instance or instances to be written; this causes generation of an SNMP Set operation instead of a Get. The "+" and ".*" suffixes MUST NOT be used in this case; any attempt to do so is an error that MUST NOT generate any SNMP Set operations. Values to be written to the MIB object instance or instances are not specified within an SNMP object URI.
SNMP对象URI还可用于指定要写入的一个或多个MIB对象实例；这会导致生成SNMP集操作而不是Get。在这种情况下，不得使用“+”和“.*”后缀；任何这样做的尝试都是一个错误，不能生成任何SNMP集操作。在SNMP对象URI中未指定要写入MIB对象实例的值。
SNMP object URIs designate data in SNMP MIBs and hence do not provide the means to generate all possible SNMP protocol operations. For example, data access for an SNMP object URI cannot directly generate either Snmpv2-Trap or InformRequest notifications, although side effects of data access could cause such notifications (depending on the MIB). In addition, whether and how GetBulk is used for an SNMP object URI with a ".*" suffix is implementation specific.
SNMP对象URI指定SNMP MIB中的数据，因此不提供生成所有可能的SNMP协议操作的方法。例如，对SNMP对象URI的数据访问不能直接生成Snmpv2陷阱或InformRequest通知，尽管数据访问的副作用可能会导致此类通知（取决于MIB）。此外，GetBulk是否以及如何用于带有“.*”后缀的SNMP对象URI取决于具体实现。
Data access based on an SNMP object URI returns an SNMP variable binding for each MIB object instance designated by the URI, or an SNMP error if the operation fails. An SNMP variable binding binds a variable name (OID) to a value or an SNMP exception (see [RFC3416]). The SNMP operation or operations needed to access data designated by an SNMP object URI depend on the OID or OID group suffix or absence thereof. The following descriptions are not the only method of performing data access for an SNMP object URI; any suitable SNMP operations may be used as long as the results (returned variable bindings or error) are functionally equivalent.
基于SNMP对象URI的数据访问为URI指定的每个MIB对象实例返回SNMP变量绑定，如果操作失败，则返回SNMP错误。SNMP变量绑定将变量名（OID）绑定到值或SNMP异常（请参阅[RFC3416]）。访问由SNMP对象URI指定的数据所需的一个或多个SNMP操作取决于OID或OID组后缀是否存在。以下描述不是对SNMP对象URI执行数据访问的唯一方法；只要结果（返回的变量绑定或错误）在功能上是等效的，就可以使用任何合适的SNMP操作。
(1) For an OID or OID group without a suffix, an SNMP Get operation is generated using each OID as a variable binding name. If an SNMP error occurs, that error is the result of URI data access; otherwise, the returned variable binding or bindings are the result of URI data access. Note that any returned variable binding may contain an SNMP "noSuchObject" or "noSuchInstance" exception.
(1) 对于没有后缀的OID或OID组，将使用每个OID作为变量绑定名称生成SNMP Get操作。如果发生SNMP错误，则该错误是URI数据访问的结果；否则，返回的变量绑定是URI数据访问的结果。请注意，任何返回的变量绑定都可能包含SNMP“noSuchObject”或“noSuchInstance”异常。
(2) For an OID or OID group with a "+" suffix, an SNMP GetNext operation is generated using each OID as a variable binding name. If an SNMP error occurs, that error is the result of URI data access; otherwise, the returned variable binding or bindings are the result of URI data access. Note that any returned variable binding may contain an SNMP "endOfMibView" exception.
(2) 对于带有“+”后缀的OID或OID组，将使用每个OID作为变量绑定名称生成SNMP GetNext操作。如果发生SNMP错误，则该错误是URI数据访问的结果；否则，返回的变量绑定是URI数据访问的结果。请注意，任何返回的变量绑定都可能包含SNMP“endOfMibView”异常。
(3) For an OID or OID group with a ".*" suffix, an SNMP GetNext operation is initially generated using each OID as a variable binding name. If the result is an SNMP error, that error is the result of URI data access. If all returned variable bindings contain either a) an OID for which the corresponding URI OID is not a lexical prefix or b) an SNMP "endOfMibView" exception, then the returned variable bindings are the result of URI data access.
(3) 对于带有“*”后缀的OID或OID组，最初会使用每个OID作为变量绑定名称生成SNMP GetNext操作。如果结果是SNMP错误，则该错误是URI数据访问的结果。如果所有返回的变量绑定都包含a）对应URI OID不是词法前缀的OID或b）SNMP“endOfMibView”异常，则返回的变量绑定是URI数据访问的结果。
Otherwise, the results of the GetNext operation are saved, and another SNMP GetNext operation is generated using the newly returned OIDs as variable binding names. This is repeated (save the results and generate a GetNext with newly returned OIDs as variable binding names) until all the returned variable bindings from a GetNext contain either a) an OID for which the corresponding URI OID is not a lexical prefix or b) an SNMP "endOfMibView" exception. The results from all of the GetNext operations are combined to become the overall result of URI data access; this may include variable bindings whose OID is not a lexical extension of the corresponding URI OID. If the OID subtrees (set of OIDs for which a specific URI OID is a lexical prefix) are not the same size for all OIDs in the OID group, the largest subtree determines when this iteration ends. SNMP GetBulk operations MAY be used to optimize this iterated access.
否则，将保存GetNext操作的结果，并使用新返回的OID作为变量绑定名称生成另一个SNMP GetNext操作。重复此操作（保存结果并使用新返回的OID作为变量绑定名称生成GetNext），直到GetNext返回的所有变量绑定包含a）对应URI OID不是词法前缀的OID或b）SNMP“endOfMibView”异常。所有GetNext操作的结果被组合成URI数据访问的整体结果；这可能包括其OID不是相应URI OID的词法扩展的变量绑定。如果OID子树（一组OID，其中特定URI OID是词法前缀）对于OID组中的所有OID大小不同，则最大的子树将确定此迭代何时结束。SNMP GetBulk操作可用于优化此迭代访问。
Whenever a returned variable binding contains an OID for which the corresponding URI OID is not a lexical prefix or an SNMP "endOfMibView" exception, iteration of that element of the OID group MAY cease, reducing the number of variable bindings used in subsequent GetNext operations. In this case, the results of URI data access for the SNMP URI will not consist entirely of OID-group-sized sets of variable bindings. Even if this does not occur, the last variable binding returned for each member of the OID group will generally contain an SNMP "endOfMibView" exception or an OID for which the corresponding URI OID is not a lexical prefix.
每当返回的变量绑定包含对应URI OID不是词法前缀的OID或SNMP“endOfMibView”异常时，OID组元素的迭代可能会停止，从而减少后续GetNext操作中使用的变量绑定数量。在这种情况下，SNMP URI的URI数据访问结果将不完全由OID组大小的变量绑定集组成。即使没有出现这种情况，为OID组的每个成员返回的最后一个变量绑定通常也将包含SNMP“endOfMibView”异常或对应URI OID不是词法前缀的OID。
Parenthesized OID groups in SNMP URIs are intended to support MIB object instances for which access via a single SNMP operation is required to ensure consistent results. Therefore, the OIDs within an OID group in an SNMP URI SHOULD be accessed by a single SNMP operation containing a variable binding corresponding to each OID in the group. A specific example involves the InetAddress and InetAddressType textual conventions defined in [RFC4001], for which the format of an InetAddress instance is specified by an associated InetAddressType instance. If two such associated instances are read via separate SNMP operations, the resulting values could be inconsistent (e.g., due to an intervening Set), causing the InetAddress value to be interpreted incorrectly.
SNMP URI中带括号的OID组旨在支持MIB对象实例，需要通过单个SNMP操作进行访问才能确保一致的结果。因此，SNMP URI中OID组内的OID应通过包含与组中每个OID对应的变量绑定的单个SNMP操作进行访问。具体示例涉及[RFC4001]中定义的InetAddress和InetAddressType文本约定，其中InetAddress实例的格式由关联的InetAddressType实例指定。如果通过单独的SNMP操作读取两个这样的关联实例，则结果值可能不一致（例如，由于中间的集合），从而导致InetAddress值被错误解释。
This single operation requirement ("SHOULD") also applies to each OID group resulting from iterated access for an SNMP URI with a ".*" suffix. When members of an SNMP URI OID group differ in the number of OIDs for which each is a lexical prefix, this iteration may overrun by returning numerous variable bindings for which the corresponding OID in the OID group is not a lexical prefix. Such overrun can be avoided by using relative references within the same context (i.e., ./<oid>.* ) when it is not important to access multiple MIB object instances in a single SNMP operation.
此单一操作要求（“应”）也适用于对带有“*”后缀的SNMP URI进行迭代访问而产生的每个OID组。当SNMP URI OID组的成员在OID的数量上存在差异（每个OID都是词法前缀）时，此迭代可能会通过返回多个变量绑定（OID组中相应的OID不是词法前缀）而溢出。当在单个SNMP操作中访问多个MIB对象实例并不重要时，可以通过在同一上下文（即./<oid>*）中使用相对引用来避免这种溢出。
This document defines a transport-independent "snmp" scheme that is intended to accommodate SNMP transports other than UDP. UDP is the default transport for access to information specified by an SNMP URI for backward compatibility with existing usage, but other transports MAY be used. If more than one transport can be used (e.g., SNMP over TCP [RFC3430] in addition to SNMP over UDP), the information or SNMP service access designated by an SNMP URI SHOULD NOT depend on which transport is used (for SNMP over TCP, this is implied by Section 2 of [RFC3430]).
本文档定义了一个独立于传输的“snmp”方案，该方案旨在容纳UDP以外的snmp传输。UDP是默认传输，用于访问SNMP URI指定的信息，以便与现有用法向后兼容，但也可以使用其他传输。如果可以使用多个传输（例如，除了UDP上的SNMP之外，TCP上的SNMP[RFC3430]），则由SNMP URI指定的信息或SNMP服务访问不应取决于使用的传输（对于TCP上的SNMP，[RFC3430]的第2节暗示了这一点）。
An SNMP URI designates use of SNMPv3 as specified by [RFC3416], [RFC3417], and related documents, but older versions of SNMP MAY be used in accordance with [RFC3584] when usage of such older versions is unavoidable. For SNMPv1 and SNMPv2c, the securityName, contextName, and contextEngineID elements of an SNMP URI are mapped to/from the community name, as described in [RFC3584]. When the community name is kept secret as a weak form of authentication, this mapping should be configured so that these three elements do not reveal information about the community name. If this is not done, then any SNMP URI component that would disclose significant information about a secret community name SHOULD be omitted. Note
SNMP URI指定使用[RFC3416]、[RFC3417]和相关文档指定的SNMPv3，但当不可避免地使用旧版本的SNMP时，可以根据[RFC3584]使用旧版本的SNMP。对于SNMPv1和SNMPv2c，SNMP URI的securityName、contextName和contextEngineID元素映射到社区名称，如[RFC3584]中所述。当社区名称作为弱身份验证形式保密时，应配置此映射，以使这三个元素不会泄露有关社区名称的信息。如果不这样做，则应忽略任何会泄露有关秘密社区名称的重要信息的SNMP URI组件。笔记
that some community names contain reserved characters (e.g., "@") that require percent encoding when they are used in an SNMP URI. SNMP versions (e.g., v3) have been omitted from the SNMP URI scheme to permit use of older versions of SNMP, as well as any possible future successor to SNMPv3.
某些团体名称包含保留字符（例如“@”），在SNMP URI中使用这些保留字符时需要百分比编码。SNMP URI方案中省略了SNMP版本（如v3），以允许使用旧版本的SNMP，以及SNMPv3的任何可能的后续版本。
snmp://example.com
snmp://example.com
This example designates the default SNMP context at the SNMP agent at port 161 of host example.com .
此示例在host example.com的端口161处的SNMP代理指定默认SNMP上下文。
snmp://tester5@example.com:8161
snmp://tester5@example.com:8161
This example designates the default SNMP context at the SNMP agent at port 8161 of host example.com and indicates that the SNMP securityName "tester5" is to be used to access that agent. A possible reason to use a non-standard port is for testing a new version of SNMP agent code.
此示例在host example.com的端口8161指定SNMP代理的默认SNMP上下文，并指示将使用SNMP安全名称“tester5”访问该代理。使用非标准端口的一个可能原因是用于测试新版本的SNMP代理代码。
snmp://example.com/bridge1
snmp://example.com/bridge1
This example designates the "bridge1" SNMP context at example.com. Because the contextEngineID component of the URI is omitted, there SHOULD be at most one SNMP context engine at example.com that supports the "bridge1" context.
此示例指定example.com上的“bridge1”SNMP上下文。由于省略了URI的contextEngineID组件，因此example.com上最多应有一个支持“bridge1”上下文的SNMP上下文引擎。
snmp://example.com/bridge1;800002b804616263
snmp://example.com/bridge1;800002b804616263
This example designates the "bridge1" context at snmp.example.com via the SNMP context engine 800002b804616263 (string representation of a hexadecimal value). This avoids ambiguity if any other context engine supports a "bridge1" context. The above two examples are based on the figure in Section 3.3 of [RFC3411].
本例通过snmp上下文引擎800002b804616263（十六进制值的字符串表示）在snmp.example.com上指定“bridge1”上下文。如果任何其他上下文引擎支持“bridge1”上下文，这将避免歧义。上述两个示例基于[RFC3411]第3.3节中的图。
snmp://example.com//1.3.6.1.2.1.1.3.0
snmp://example.com//1.3.6.1.2.1.1.3+
snmp://example.com//1.3.6.1.2.1.1.3.*
snmp://example.com//1.3.6.1.2.1.1.3.0
snmp://example.com//1.3.6.1.2.1.1.3+
snmp://example.com//1.3.6.1.2.1.1.3.*
These three examples all designate the sysUpTime.0 object instance in the SNMPv2-MIB or RFC1213-MIB for the default SNMP context ("") at example.com as sysUpTime.0 is:
这三个示例都将example.com上默认SNMP上下文（“”）的SNMPv2 MIB或RFC1213-MIB中的sysUpTime.0对象实例指定为sysUpTime。0是：
a) designated directly by OID 1.3.6.1.2.1.1.3.0,
a) 由OID 1.3.6.1.2.1.1.3.0直接指定，
b) the lexically next MIB object instance after the OID 1.3.6.1.2.1.1.3, and
b) OID 1.3.6.1.2.1.1.3之后词汇上的下一个MIB对象实例，以及
c) the only MIB object instance whose OID has 1.3.6.1.2.1.1.3 as a lexical prefix.
c) 唯一一个其OID以1.3.6.1.2.1.1.3作为词法前缀的MIB对象实例。
These three examples are provided for illustrative purposes only, as multiple syntactically distinct URIs SHOULD NOT be used to designate the same MIB object instance, in order to avoid unexpected results in URI-based systems that use string comparison to test URIs for equality.
这三个示例仅用于说明目的，因为不应使用多个语法不同的URI来指定同一MIB对象实例，以避免在基于URI的系统中出现意外结果，这些系统使用字符串比较来测试URI是否相等。
snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*
snmp://example.com/bridge1/1.3.6.1.2.1.2.2.1.8.*
This example designates the ifOperStatus column of the IF-MIB in the bridge1 SNMP context at example.com.
此示例在example.com上的bridge1 SNMP上下文中指定IF-MIB的ifOperStatus列。
snmp://example.com//(1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8).*
snmp://example.com//(1.3.6.1.2.1.2.2.1.7,1.3.6.1.2.1.2.2.1.8).*
This example designates all (ifAdminStatus, ifOperStatus) pairs in the IF-MIB in the default SNMP context at example.com.
此示例在example.com的默认SNMP上下文中指定IF-MIB中的所有（ifAdminStatus、ifOperStatus）对。
An intended use of this URI scheme is designation of the location of management access to communication devices. Such location information may be considered sensitive in some environments, making it important to control access to this information and possibly even to encrypt it when it is sent over the network. All uses of this URI scheme should provide security mechanisms appropriate to the environments in which such uses are likely to be deployed.
该URI方案的预期用途是指定对通信设备的管理访问的位置。在某些环境中，此类位置信息可能被视为敏感信息，因此控制对该信息的访问非常重要，甚至可能在通过网络发送时对其进行加密。此URI方案的所有使用都应提供适合于可能部署此类使用的环境的安全机制。
The SNMP architecture includes control of access to management information (see Section 4.3 of [RFC3411]). An SNMP URI does not contain sufficient security information to obtain access in all situations, as the SNMP URI syntax is incapable of encoding SNMP securityModels, SNMP securityLevels, and credential or keying information for SNMP securityNames. Other means are necessary to provide such information; one possibility is out-of-band pre-configuration of the SNMP manager, as shown in the diagrams in Section 2.
SNMP体系结构包括对管理信息访问的控制（见[RFC3411]第4.3节）。SNMP URI不包含在所有情况下都可以访问的足够安全信息，因为SNMP URI语法无法编码SNMP安全模型、SNMP安全级别以及SNMP安全名称的凭据或密钥信息。提供此类信息所需的其他方式；一种可能性是SNMP管理器的带外预配置，如第2节中的图表所示。
By itself, the presence of a securityName in an SNMP URI does not authorize use of that securityName to access management information. Instead, the SNMP manager SHOULD match the securityName in the URI to an SNMP securityName and associated security information that have been pre-configured for use by the manager. If an SNMP URI contains a securityName that the SNMP manager is not provisioned to use, SNMP operations for that URI SHOULD NOT be generated.
就其本身而言，SNMP URI中存在securityName并不授权使用该securityName访问管理信息。相反，SNMP管理器应将URI中的securityName与SNMP securityName和相关安全信息相匹配，这些信息已预先配置好供管理器使用。如果SNMP URI包含SNMP管理器未设置为使用的securityName，则不应生成该URI的SNMP操作。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example, via use of IPsec), there is no control over who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in MIB modules. It is RECOMMENDED that implementers consider the security features provided by the SNMPv3 framework (see [RFC3410], Section 8, for an overview), including full support for SNMPv3 cryptographic mechanisms (for authentication and privacy). This is of additional importance for MIB elements considered sensitive or vulnerable because GETs have side effects.
SNMPv3之前的SNMP版本未包含足够的安全性。即使网络本身是安全的（例如，通过使用IPsec），也无法控制安全网络上允许谁访问和获取/设置（读取/更改/创建/删除）MIB模块中的对象。建议实施者考虑SNMPv3框架提供的安全特性（参见[RCFC310]，第8节，概述），包括对SNMPv3加密机制的完全支持（用于身份验证和隐私）。这对于被视为敏感或易受攻击的MIB元素来说尤为重要，因为GET具有副作用。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to a MIB module instance is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (read/change/create/delete) them.
此外，不建议部署SNMPv3之前的SNMP版本。相反，建议部署SNMPv3并启用加密安全性。然后，客户/运营商有责任确保对访问MIB模块实例的SNMP实体进行了正确配置，以便仅向那些拥有确实获取或设置（读取/更改/创建/删除）对象的合法权限的主体（用户）授予对对象的访问权。
Additional security considerations apply to SNMP gateways that generate SNMP operations for SNMP URIs and return the results to clients (see Section 2) because management information is communicated beyond the SNMP framework. In general, an SNMP gateway should have some knowledge of the structure and function of the management information that it accesses via SNMP. Among other benefits, this allows an SNMP gateway to avoid SNMP access control failures because the gateway can reject an SNMP URI that will cause such failures before generating any SNMP operations.
其他安全注意事项适用于为SNMP URI生成SNMP操作并将结果返回给客户端的SNMP网关（请参见第2节），因为管理信息在SNMP框架之外进行通信。通常，SNMP网关应该了解通过SNMP访问的管理信息的结构和功能。除其他好处外，这允许SNMP网关避免SNMP访问控制故障，因为网关可以在生成任何SNMP操作之前拒绝将导致此类故障的SNMP URI。
SNMP gateways SHOULD impose authorization or access-control checks on all clients. If an SNMP gateway does not impose authorization or access controls, the gateway MUST NOT automatically obtain or use SNMP authentication material for arbitrary securityNames, as doing so would defeat SNMP's access controls. Instead, all SNMP gateways SHOULD authenticate each client and check the client's authorization to use a securityName in an SNMP URI before using the securityName on behalf of that client.
SNMP网关应在所有客户端上实施授权或访问控制检查。如果SNMP网关未实施授权或访问控制，网关不得自动获取或使用任意安全名称的SNMP身份验证材料，因为这样做会破坏SNMP的访问控制。相反，所有SNMP网关都应该对每个客户端进行身份验证，并在代表该客户端使用securityName之前检查该客户端在SNMP URI中使用securityName的授权。
An SNMP gateway is also responsible for ensuring that all of its communication is appropriately secured. Specifically, an SNMP gateway SHOULD ensure that communication of management information with any client is protected to at least the SNMP securityLevel used for the corresponding SNMP access (see Section 3.4.3 of [RFC3411] for more information on securityLevel). If the client provides SNMP security information, the SNMP gateway SHOULD authenticate the client and SHOULD ensure that an authenticated cryptographic integrity check
SNMP网关还负责确保其所有通信都得到适当的保护。具体而言，SNMP网关应确保与任何客户端的管理信息通信至少受到用于相应SNMP访问的SNMP安全级别的保护（有关安全级别的更多信息，请参阅[RFC3411]第3.4.3节）。如果客户机提供SNMP安全信息，SNMP网关应验证客户机，并应确保已验证的加密完整性检查
is used for that communication to prevent modification of the security information. In addition, if a client provides any key or secret, the SNMP gateway SHOULD ensure that encryption is used in addition to the integrity check for that communication to prevent disclosure of keys or secrets.
用于该通信以防止修改安全信息。此外，如果客户端提供任何密钥或机密，SNMP网关应确保在对该通信进行完整性检查的同时使用加密，以防止密钥或机密泄露。
There are management objects defined in SNMP MIBs whose MAX-ACCESS is read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. SNMP gateway support for SNMP SET operations in a non-secure environment without proper protection can have a negative effect on network operations. The individual MIB module specifications, and especially their security considerations, should be consulted for further information.
SNMP MIB中定义了一些管理对象，其最大访问权限为读写和/或读创建。在某些网络环境中，此类对象可能被视为敏感或易受攻击。在没有适当保护的非安全环境中，对SNMP集操作的SNMP网关支持可能会对网络操作产生负面影响。应参考各个MIB模块规范，尤其是其安全注意事项，以获取更多信息。
Some readable objects in some MIB modules (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET access to these objects via an SNMP gateway and possibly to even encrypt the values of these objects when they are sent over the network. The individual MIB module specifications, and especially their security considerations, should be consulted for further information. This consideration also applies to objects for which read operations have side effects.
在某些网络环境中，某些MIB模块中的某些可读对象（即具有MAX-ACCESS而非not ACCESS的对象）可能被视为敏感或易受攻击。因此，控制甚至通过SNMP网关访问这些对象非常重要，甚至可能在通过网络发送这些对象时加密这些对象的值。应参考各个MIB模块规范，尤其是其安全注意事项，以获取更多信息。这种考虑也适用于读取操作有副作用的对象。
The IANA has registered the URL registration template found in Appendix A in accordance with [RFC2717].
IANA已根据[RFC2717]注册了附录A中的URL注册模板。
[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月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
[RFC3061]Mealling，M.，“对象标识符的URN名称空间”，RFC 3061，2001年2月。
[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月。
[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月。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417]Presohn，R.，“简单网络管理协议（SNMP）的传输映射”，STD 62，RFC 34172002年12月。
[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", BCP 74, RFC 3584, August 2003.
[RFC3584]Frye，R.，Levi，D.，Routhier，S.，和B.Wijnen，“互联网标准网络管理框架版本1，版本2和版本3之间的共存”，BCP 74，RFC 3584，2003年8月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter，L.，和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RFC1900]Carpenter，B.和Y.Rekhter，“重新编号需要工作”，RFC 1900，1996年2月。
[RFC2717] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC2717]Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年11月。
[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月。
[RFC3430] Schoenwaelder, J., "Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping", RFC 3430, December 2002.
[RFC3430]Schoenwaeld，J.，“传输控制协议传输映射上的简单网络管理协议”，RFC 3430，2002年12月。
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP)", RFC 3617, October 2003.
[RFC3617]李尔，E.“普通文件传输协议（TFTP）的统一资源标识符（URI）方案和适用性声明”，RFC3617，2003年10月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001]Daniele，M.，Haberman，B.，Routhier，S.，和J.Schoenwaeld，“互联网网络地址的文本约定”，RFC 4001，2005年2月。
Portions of this document were adapted from Eliot Lear's TFTP URI scheme specification [RFC3617]. Portions of the security considerations were adapted from the widely used security considerations "boilerplate" for MIB modules. Comments from Ted Hardie, Michael Mealing, Larry Masinter, Frank Strauss, Bert Wijnen, Steve Bellovin, the mreview@ops.ietf.org mailing list and the uri@w3c.org mailing list on earlier versions of this document have resulted in significant improvements and are gratefully acknowledged.
本文档的部分内容改编自Eliot Lear的TFTP URI方案规范[RFC3617]。部分安全注意事项改编自MIB模块广泛使用的安全注意事项“样板”。来自泰德·哈迪、迈克尔·米林、拉里·马斯泰特、弗兰克·施特劳斯、伯特·维恩、史蒂夫·贝洛文以及mreview@ops.ietf.org邮件列表和uri@w3c.org本文件早期版本的邮件列表已取得重大改进，特此致谢。
URL scheme name: snmp URL scheme syntax: Section 3 Character encoding considerations: Section 3 Intended usage: Sections 1 and 2 Applications and/or protocols which use this scheme: SNMP, all versions, see [RFC3410] and [RFC3584]. Also SNMP over TCP, see [RFC3430]. Interoperability considerations: Section 4.4 Security considerations: Section 6 Relevant publications: See [RFC3410] for list. Also [RFC3430] and [RFC3584]. Contact: David L. Black, see below Author/Change Controller: IESG
URL方案名称：snmp URL方案语法：第3节字符编码注意事项：第3节预期用途：第1节和第2节使用此方案的应用程序和/或协议：snmp，所有版本，请参阅[RFC3410]和[RFC3584]。另外，TCP上的SNMP，请参阅[RFC3430]。互操作性注意事项：第4.4节安全注意事项：第6节相关出版物：列表见[RFC3410]。也包括[RFC3430]和[RFC3584]。联系人：David L.Black，见下文作者/变更负责人：IESG
Authors' Addresses
作者地址
David L. Black EMC Corporation 176 South Street Hopkinton, MA 01748
David L.Black EMC Corporation马萨诸塞州霍普金顿南街176号01748
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Phone: +1 (508) 293-7953
EMail: black_david@emc.com
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA 95134
Keith McCloghrie Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: +1 (408) 526-5260
EMail: kzm@cisco.com
Phone: +1 (408) 526-5260
EMail: kzm@cisco.com
Juergen Schoenwaelder International University Bremen P.O. Box 750 561 28725 Bremen Germany
德国不来梅Juergen Schoenwaeld国际大学邮政信箱750 561 28725不来梅
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。