Network Working Group Editor of this version:
Request for Comments: 3417 R. Presuhn
STD: 62 BMC Software, Inc.
Obsoletes: 1906 Authors of previous version:
Category: Standards Track J. Case
SNMP Research, Inc.
K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
December 2002
Network Working Group Editor of this version:
Request for Comments: 3417 R. Presuhn
STD: 62 BMC Software, Inc.
Obsoletes: 1906 Authors of previous version:
Category: Standards Track J. Case
SNMP Research, Inc.
K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
December 2002
Transport Mappings for the Simple Network Management Protocol (SNMP)
简单网络管理协议（SNMP）的传输映射
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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines the transport of Simple Network Management Protocol (SNMP) messages over various protocols. This document obsoletes RFC 1906.
本文档定义了通过各种协议传输简单网络管理协议（SNMP）消息。本文件废除了RFC 1906。
Table of Contents
目录
1. Introduction ................................................ 2
2. Definitions ................................................. 3
3. SNMP over UDP over IPv4 ..................................... 7
3.1. Serialization ............................................. 7
3.2. Well-known Values ......................................... 7
4. SNMP over OSI ............................................... 7
4.1. Serialization ............................................. 7
4.2. Well-known Values ......................................... 8
5. SNMP over DDP ............................................... 8
5.1. Serialization ............................................. 8
5.2. Well-known Values ......................................... 8
5.3. Discussion of AppleTalk Addressing ........................ 9
5.3.1. How to Acquire NBP names ................................ 9
5.3.2. When to Turn NBP names into DDP addresses ............... 10
5.3.3. How to Turn NBP names into DDP addresses ................ 10
5.3.4. What if NBP is broken ................................... 10
6. SNMP over IPX ............................................... 11
6.1. Serialization ............................................. 11
6.2. Well-known Values ......................................... 11
7. Proxy to SNMPv1 ............................................. 12
8. Serialization using the Basic Encoding Rules ................ 12
8.1. Usage Example ............................................. 13
9. Notice on Intellectual Property ............................. 14
10. Acknowledgments ............................................ 14
11. IANA Considerations ........................................ 15
12. Security Considerations .................................... 16
13. References ................................................. 16
13.1. Normative References ..................................... 16
13.2. Informative References ................................... 17
14. Changes from RFC 1906 ...................................... 18
15. Editor's Address ........................................... 18
16. Full Copyright Statement ................................... 19
1. Introduction ................................................ 2
2. Definitions ................................................. 3
3. SNMP over UDP over IPv4 ..................................... 7
3.1. Serialization ............................................. 7
3.2. Well-known Values ......................................... 7
4. SNMP over OSI ............................................... 7
4.1. Serialization ............................................. 7
4.2. Well-known Values ......................................... 8
5. SNMP over DDP ............................................... 8
5.1. Serialization ............................................. 8
5.2. Well-known Values ......................................... 8
5.3. Discussion of AppleTalk Addressing ........................ 9
5.3.1. How to Acquire NBP names ................................ 9
5.3.2. When to Turn NBP names into DDP addresses ............... 10
5.3.3. How to Turn NBP names into DDP addresses ................ 10
5.3.4. What if NBP is broken ................................... 10
6. SNMP over IPX ............................................... 11
6.1. Serialization ............................................. 11
6.2. Well-known Values ......................................... 11
7. Proxy to SNMPv1 ............................................. 12
8. Serialization using the Basic Encoding Rules ................ 12
8.1. Usage Example ............................................. 13
9. Notice on Intellectual Property ............................. 14
10. Acknowledgments ............................................ 14
11. IANA Considerations ........................................ 15
12. Security Considerations .................................... 16
13. References ................................................. 16
13.1. Normative References ..................................... 16
13.2. Informative References ................................... 17
14. Changes from RFC 1906 ...................................... 18
15. Editor's Address ........................................... 18
16. Full Copyright Statement ................................... 19
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅RFC 3410[RFC3410]第7节。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB对象通常通过简单网络管理协议（SNMP）进行访问。MIB中的对象是使用管理信息结构（SMI）中定义的机制定义的。此备忘录指定了一个MIB
module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
符合SMIv2的模块，如STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和STD 58、RFC 2580[RFC2580]所述。
This document, Transport Mappings for the Simple Network Management Protocol, defines how the management protocol [RFC3416] may be carried over a variety of protocol suites. It is the purpose of this document to define how the SNMP maps onto an initial set of transport domains. At the time of this writing, work was in progress to define an IPv6 mapping, described in [RFC3419]. Other mappings may be defined in the future.
本文件《简单网络管理协议的传输映射》定义了管理协议[RFC3416]如何通过各种协议套件传输。本文档旨在定义SNMP如何映射到初始传输域集。在撰写本文时，定义IPv6映射的工作正在进行中，如[RFC3419]所述。将来可能会定义其他映射。
Although several mappings are defined, the mapping onto UDP over IPv4 is the preferred mapping for systems supporting IPv4. Systems implementing IPv4 MUST implement the mapping onto UDP over IPv4. To maximize interoperability, systems supporting other mappings SHOULD also provide for access via the UDP over IPv4 mapping.
虽然定义了多个映射，但对于支持IPv4的系统，到IPv4上的UDP映射是首选映射。实现IPv4的系统必须通过IPv4实现到UDP的映射。为了最大限度地提高互操作性，支持其他映射的系统还应提供通过UDP over IPv4映射的访问。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
SNMPv2-TM DEFINITIONS ::= BEGIN
SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules, snmpDomains, snmpProxys FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC;
从SNMPv2导入模块标识、对象标识、snmpModules、snmpDomains、snmpProxys，从SNMPv2 TC导入SMI文本约定；
snmpv2tm MODULE-IDENTITY LAST-UPDATED "200210160000Z" ORGANIZATION "IETF SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com Subscribe: snmpv3-request@lists.tislabs.com
snmpv2tm模块标识最后更新的“200210160000Z”组织“IETF SNMPv3工作组”联系方式工作组电子邮件：snmpv3@lists.tislabs.com订阅：snmpv3-request@lists.tislabs.com
Co-Chair: Russ Mundy Network Associates Laboratories postal: 15204 Omega Drive, Suite 300 Rockville, MD 20850-4601 USA EMail: mundy@tislabs.com phone: +1 301 947-7107
联席主席：Russ Mundy Network Associates Laboratories邮政编码：15204美国马里兰州罗克维尔欧米茄大道300号套房20850-4601电子邮件：mundy@tislabs.com电话：+1 301 947-7107
Co-Chair: David Harrington Enterasys Networks postal: 35 Industrial Way P. O. Box 5005 Rochester, NH 03866-5005 USA EMail: dbh@enterasys.com phone: +1 603 337-2614
联席主席：David Harrington Enterasys Networks邮政：美国新罕布什尔州罗切斯特市工业路35号邮政信箱5005 03866-5005电子邮件：dbh@enterasys.com电话：+1 603 337-2614
Editor: Randy Presuhn BMC Software, Inc. postal: 2141 North First Street San Jose, CA 95131 USA EMail: randy_presuhn@bmc.com phone: +1 408 546-1006" DESCRIPTION "The MIB module for SNMP transport mappings.
编辑：Randy Presohn BMC Software，Inc.邮政编码：2141 North First Street San Jose，CA 95131美国电子邮件：Randy_presuhn@bmc.com电话：+1 408 546-1006“说明”SNMP传输映射的MIB模块。
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3417;
see the RFC itself for full legal notices.
"
REVISION "200210160000Z"
DESCRIPTION
"Clarifications, published as RFC 3417."
REVISION "199601010000Z"
DESCRIPTION
"Clarifications, published as RFC 1906."
REVISION "199304010000Z"
DESCRIPTION
"The initial version, published as RFC 1449."
::= { snmpModules 19 }
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3417;
see the RFC itself for full legal notices.
"
REVISION "200210160000Z"
DESCRIPTION
"Clarifications, published as RFC 3417."
REVISION "199601010000Z"
DESCRIPTION
"Clarifications, published as RFC 1906."
REVISION "199304010000Z"
DESCRIPTION
"The initial version, published as RFC 1449."
::= { snmpModules 19 }
-- SNMP over UDP over IPv4
--基于IPv4的UDP上的SNMP
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over UDP over IPv4 transport domain.
The corresponding transport address is of type
SnmpUDPAddress."
::= { snmpDomains 1 }
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over UDP over IPv4 transport domain.
The corresponding transport address is of type
SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP over IPv4 address:
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP over IPv4 address:
octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6))
八位字节内容编码1-4 IP地址网络字节顺序5-6 UDP端口网络字节顺序“语法八位字节字符串（大小（6））
-- SNMP over OSI
--基于OSI的SNMP
snmpCLNSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over CLNS transport domain.
The corresponding transport address is of type
SnmpOSIAddress."
::= { snmpDomains 2 }
snmpCLNSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over CLNS transport domain.
The corresponding transport address is of type
SnmpOSIAddress."
::= { snmpDomains 2 }
snmpCONSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over CONS transport domain.
The corresponding transport address is of type
SnmpOSIAddress."
::= { snmpDomains 3 }
snmpCONSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over CONS transport domain.
The corresponding transport address is of type
SnmpOSIAddress."
::= { snmpDomains 3 }
SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
"Represents an OSI transport-address:
SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
"Represents an OSI transport-address:
octets contents encoding 1 length of NSAP 'n' as an unsigned-integer (either 0 or from 3 to 20) 2..(n+1) NSAP concrete binary representation (n+2)..m TSEL string of (up to 64) octets " SYNTAX OCTET STRING (SIZE (1 | 4..85))
八位字节内容将NSAP'n'的1个长度编码为无符号整数（0或从3到20）2..（n+1）NSAP具体二进制表示法（n+2）…m TSEL字符串（最多64个）八位字节的语法八位字节字符串（大小（1 | 4..85））
-- SNMP over DDP
--基于DDP的SNMP协议
snmpDDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over DDP transport domain. The corresponding
transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 }
snmpDDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over DDP transport domain. The corresponding
transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 }
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an NBP name:
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an NBP name:
octets contents encoding
1 length of object 'n' as an unsigned integer
2..(n+1) object string of (up to 32) octets
n+2 length of type 'p' as an unsigned integer
(n+3)..(n+2+p) type string of (up to 32) octets
n+3+p length of zone 'q' as an unsigned integer
(n+4+p)..(n+3+p+q) zone string of (up to 32) octets
octets contents encoding
1 length of object 'n' as an unsigned integer
2..(n+1) object string of (up to 32) octets
n+2 length of type 'p' as an unsigned integer
(n+3)..(n+2+p) type string of (up to 32) octets
n+3+p length of zone 'q' as an unsigned integer
(n+4+p)..(n+3+p+q) zone string of (up to 32) octets
For comparison purposes, strings are case-insensitive. All strings may contain any octet other than 255 (hex ff)." SYNTAX OCTET STRING (SIZE (3..99))
出于比较目的，字符串不区分大小写。所有字符串可以包含255（十六进制ff）以外的任何八位字节。“语法八位字节字符串（大小（3..99））
-- SNMP over IPX
--IPX上的SNMP
snmpIPXDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over IPX transport domain. The corresponding
transport address is of type SnmpIPXAddress."
::= { snmpDomains 5 }
snmpIPXDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over IPX transport domain. The corresponding
transport address is of type SnmpIPXAddress."
::= { snmpDomains 5 }
SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
"Represents an IPX address:
SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
"Represents an IPX address:
octets contents encoding 1-4 network-number network-byte order 5-10 physical-address network-byte order 11-12 socket-number network-byte order " SYNTAX OCTET STRING (SIZE (12))
八位字节内容编码1-4网络号网络字节顺序5-10物理地址网络字节顺序11-12套接字号网络字节顺序“语法八位字节字符串（大小（12））
-- for proxy to SNMPv1 (RFC 1157)
--对于SNMPv1（RFC 1157）的代理
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY
STATUS deprecated
DESCRIPTION
"The transport domain for SNMPv1 over UDP over IPv4.
The corresponding transport address is of type
SnmpUDPAddress."
::= { rfc1157Proxy 1 }
rfc1157Domain OBJECT-IDENTITY
STATUS deprecated
DESCRIPTION
"The transport domain for SNMPv1 over UDP over IPv4.
The corresponding transport address is of type
SnmpUDPAddress."
::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete
-- ::= { rfc1157Proxy 2 } this OID is obsolete
END
终止
This is the preferred transport mapping.
这是首选的传输映射。
Each instance of a message is serialized (i.e., encoded according to the convention of [BER]) onto a single UDP [RFC768] over IPv4 [RFC791] datagram, using the algorithm specified in Section 8.
使用第8节中指定的算法，将消息的每个实例序列化（即，根据[BER]约定进行编码）到IPv4[RFC791]数据报上的单个UDP[RFC768]上。
It is suggested that administrators configure their SNMP entities supporting command responder applications to listen on UDP port 161. Further, it is suggested that SNMP entities supporting notification receiver applications be configured to listen on UDP port 162.
建议管理员将其支持命令响应程序应用程序的SNMP实体配置为侦听UDP端口161。此外，建议将支持通知接收器应用程序的SNMP实体配置为侦听UDP端口162。
When an SNMP entity uses this transport mapping, it must be capable of accepting messages up to and including 484 octets in size. It is recommended that implementations be capable of accepting messages of up to 1472 octets in size. Implementation of larger values is encouraged whenever possible.
当SNMP实体使用此传输映射时，它必须能够接受大小不超过484个八位字节的消息。建议实现能够接受多达1472个八位字节大小的消息。尽可能鼓励实施更大的价值观。
This is an optional transport mapping.
这是一个可选的传输映射。
Each instance of a message is serialized onto a single TSDU [IS8072] [IS8072A] for the OSI Connectionless-mode Transport Service (CLTS), using the algorithm specified in Section 8.
使用第8节中指定的算法，将消息的每个实例序列化到OSI无连接模式传输服务（CLTS）的单个TSDU[IS8072][IS8072A]。
It is suggested that administrators configure their SNMP entities supporting command responder applications to listen on transport selector "snmp-l" (which consists of six ASCII characters), when using a CL-mode network service to realize the CLTS. Further, it is suggested that SNMP entities supporting notification receiver applications be configured to listen on transport selector "snmpt-l" (which consists of seven ASCII characters, six letters and a hyphen) when using a CL-mode network service to realize the CLTS. Similarly, when using a CO-mode network service to realize the CLTS, the suggested transport selectors are "snmp-o" and "snmpt-o", for command responders and notification receivers, respectively.
建议管理员在使用CL模式网络服务实现CLT时，将其支持命令响应程序应用程序的SNMP实体配置为侦听传输选择器“SNMP-l”（由六个ASCII字符组成）。此外，建议将支持通知接收器应用程序的SNMP实体配置为在使用CL模式网络服务实现clt时侦听传输选择器“snmpt-l”（由七个ASCII字符、六个字母和一个连字符组成）。类似地，当使用共同模式网络服务来实现clt时，建议的传输选择器分别是“snmp-o”和“snmpt-o”，用于命令响应者和通知接收器。
When an SNMP entity uses this transport mapping, it must be capable of accepting messages that are at least 484 octets in size. Implementation of larger values is encouraged whenever possible.
当SNMP实体使用此传输映射时，它必须能够接受大小至少为484个八位字节的消息。尽可能鼓励实施更大的价值观。
This is an optional transport mapping.
这是一个可选的传输映射。
Each instance of a message is serialized onto a single DDP datagram [APPLETALK], using the algorithm specified in Section 8.
使用第8节中指定的算法，将消息的每个实例序列化到单个DDP数据报[APPLETALK]。
SNMP messages are sent using DDP protocol type 8. SNMP entities supporting command responder applications listen on DDP socket number 8, while SNMP entities supporting notification receiver applications listen on DDP socket number 9.
SNMP消息使用DDP协议类型8发送。支持命令响应程序应用程序的SNMP实体侦听8号DDP套接字，而支持通知接收器应用程序的SNMP实体侦听9号DDP套接字。
Administrators must configure their SNMP entities supporting command responder applications to use NBP type "SNMP Agent" (which consists of ten ASCII characters) while those supporting notification receiver applications must be configured to use NBP type "SNMP Trap Handler" (which consists of seventeen ASCII characters).
管理员必须将其支持命令响应程序应用程序的SNMP实体配置为使用NBP类型的“SNMP代理”（由十个ASCII字符组成），而支持通知接收器应用程序的SNMP实体必须配置为使用NBP类型的“SNMP陷阱处理程序”（由十七个ASCII字符组成）。
The NBP name for SNMP entities supporting command responders and notification receivers should be stable - NBP names should not change any more often than the IP address of a typical TCP/IP node. It is suggested that the NBP name be stored in some form of stable storage.
支持命令响应程序和通知接收器的SNMP实体的NBP名称应稳定-NBP名称的更改频率不应超过典型TCP/IP节点的IP地址。建议NBP名称以某种稳定的存储形式存储。
When an SNMP entity uses this transport mapping, it must be capable of accepting messages that are at least 484 octets in size. Implementation of larger values is encouraged whenever possible.
当SNMP实体使用此传输映射时，它必须能够接受大小至少为484个八位字节的消息。尽可能鼓励实施更大的价值观。
The AppleTalk protocol suite has certain features not manifest in the TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of address assignment can cause problems for SNMP entities that wish to manage AppleTalk networks. TCP/IP nodes have an associated IP address which distinguishes each from the other. In contrast, AppleTalk nodes generally have no such characteristic. The network-level address, while often relatively stable, can change at every reboot (or more frequently).
AppleTalk协议套件具有TCP/IP套件中未体现的某些功能。AppleTalk的命名策略和地址分配的动态特性可能会给希望管理AppleTalk网络的SNMP实体带来问题。TCP/IP节点有一个相关联的IP地址，使它们彼此区别开来。相反，AppleTalk节点一般没有这种特性。网络级地址虽然通常相对稳定，但在每次重新启动时（或更频繁地）都会发生更改。
Thus, when SNMP is mapped over DDP, nodes are identified by a "name", rather than by an "address". Hence, all AppleTalk nodes that implement this mapping are required to respond to NBP lookups and confirms (e.g., implement the NBP protocol stub), which guarantees that a mapping from NBP name to DDP address will be possible.
因此，当SNMP映射到DDP上时，节点由“名称”标识，而不是由“地址”标识。因此，实现此映射的所有AppleTalk节点都需要响应NBP查找和确认（例如，实现NBP协议存根），这保证了从NBP名称到DDP地址的映射是可能的。
In determining the SNMP identity to register for an SNMP entity, it is suggested that the SNMP identity be a name which is associated with other network services offered by the machine.
在确定要注册SNMP实体的SNMP标识时，建议SNMP标识是与机器提供的其他网络服务关联的名称。
NBP lookups, which are used to map NBP names into DDP addresses, can cause large amounts of network traffic as well as consume CPU resources. It is also the case that the ability to perform an NBP lookup is sensitive to certain network disruptions (such as zone table inconsistencies) which would not prevent direct AppleTalk communications between two SNMP entities.
NBP查找用于将NBP名称映射到DDP地址，它会导致大量网络流量并消耗CPU资源。此外，执行NBP查找的能力对某些网络中断（如区域表不一致）很敏感，这不会阻止两个SNMP实体之间的直接AppleTalk通信。
Thus, it is recommended that NBP lookups be used infrequently, primarily to create a cache of name-to-address mappings. These cached mappings should then be used for any further SNMP traffic. It is recommended that SNMP entities supporting command generator applications should maintain this cache between reboots. This caching can help minimize network traffic, reduce CPU load on the network, and allow for (some amount of) network trouble shooting when the basic name-to-address translation mechanism is broken.
因此，建议不经常使用NBP查找，主要用于创建名称到地址映射的缓存。然后，这些缓存映射应用于任何进一步的SNMP通信。建议支持命令生成器应用程序的SNMP实体在重新启动之间维护此缓存。这种缓存可以帮助最小化网络流量，减少网络上的CPU负载，并在基本的名称到地址转换机制中断时允许（一定数量的）网络故障排除。
An SNMP entity supporting command generator applications may have a pre-configured list of names of "known" SNMP entities supporting command responder applications. Similarly, an SNMP entity supporting command generator or notification receiver applications might interact with an operator. Finally, an SNMP entity supporting command generator or notification receiver applications might communicate with all SNMP entities supporting command responder or notification originator applications in a set of zones or networks.
支持命令生成器应用程序的SNMP实体可能具有支持命令响应程序应用程序的“已知”SNMP实体名称的预配置列表。类似地，支持命令生成器或通知接收器应用程序的SNMP实体可能与操作员交互。最后，支持命令生成器或通知接收器应用程序的SNMP实体可以与一组区域或网络中支持命令响应者或通知发起人应用程序的所有SNMP实体通信。
When an SNMP entity uses a cache entry to address an SNMP packet, it should attempt to confirm the validity mapping, if the mapping hasn't been confirmed within the last T1 seconds. This cache entry lifetime, T1, has a minimum, default value of 60 seconds, and should be configurable.
当SNMP实体使用缓存条目来寻址SNMP数据包时，如果在最后T1秒内未确认映射，则应尝试确认有效性映射。此缓存项生存期T1的最小默认值为60秒，应该是可配置的。
An SNMP entity supporting a command generator application may decide to prime its cache of names prior to actually communicating with another SNMP entity. In general, it is expected that such an entity may want to keep certain mappings "more current" than other mappings, e.g., those nodes which represent the network infrastructure (e.g., routers) may be deemed "more important".
支持命令生成器应用程序的SNMP实体可能会在与另一个SNMP实体进行实际通信之前决定初始化其名称缓存。一般而言，预期这样的实体可能希望保持某些映射比其他映射“更为最新”，例如，代表网络基础设施的那些节点（例如路由器）可能被认为“更重要”。
Note that an SNMP entity supporting command generator applications should not prime its entire cache upon initialization - rather, it should attempt resolutions over an extended period of time (perhaps in some pre-determined or configured priority order). Each of these resolutions might, in fact, be a wildcard lookup in a given zone.
请注意，支持命令生成器应用程序的SNMP实体不应在初始化时初始化其整个缓存，而应在较长的时间内（可能以某种预先确定或配置的优先级顺序）尝试解析。事实上，这些分辨率中的每一个都可能是给定区域中的通配符查找。
An SNMP entity supporting command responder applications must never prime its cache. When generating a response, such an entity does not need to confirm a cache entry. An SNMP entity supporting notification originator applications should do NBP lookups (or confirms) only when it needs to send an SNMP trap or inform.
支持命令响应程序应用程序的SNMP实体决不能初始化其缓存。生成响应时，这样的实体不需要确认缓存条目。支持通知发起人应用程序的SNMP实体应仅在需要发送SNMP陷阱或通知时进行NBP查找（或确认）。
If the only piece of information available is the NBP name, then an NBP lookup should be performed to turn that name into a DDP address. However, if there is a piece of stale information, it can be used as a hint to perform an NBP confirm (which sends a unicast to the network address which is presumed to be the target of the name lookup) to see if the stale information is, in fact, still valid.
如果唯一可用的信息是NBP名称，则应执行NBP查找以将该名称转换为DDP地址。但是，如果存在一段陈旧信息，则可以将其用作执行NBP确认（向假定为名称查找目标的网络地址发送单播）的提示，以查看陈旧信息实际上是否仍然有效。
An NBP name to DDP address mapping can also be confirmed implicitly using only SNMP transactions. For example, an SNMP entity supporting command generator applications issuing a retrieval operation could also retrieve the relevant objects from the NBP group [RFC1742] for the SNMP entity supporting the command responder application. This information can then be correlated with the source DDP address of the response.
也可以仅使用SNMP事务隐式确认NBP名称到DDP地址的映射。例如，支持命令生成器应用程序的SNMP实体发出检索操作，也可以从支持命令响应程序应用程序的SNMP实体的NBP组[RFC1742]检索相关对象。然后，该信息可以与响应的源DDP地址相关联。
Under some circumstances, there may be connectivity between two SNMP entities, but the NBP mapping machinery may be broken, e.g.,
在某些情况下，两个SNMP实体之间可能存在连接，但NBP映射机制可能会中断，例如。，
o the NBP FwdReq (forward NBP lookup onto local attached network) mechanism might be broken at a router on the other entity's network; or,
o NBP FwdReq（本地连接网络上的前向NBP查找）机制可能在另一实体网络上的路由器上被破坏；或
o the NBP BrRq (NBP broadcast request) mechanism might be broken at a router on the entity's own network; or,
o NBP BrRq（NBP广播请求）机制可能在实体自身网络上的路由器上被破坏；或
o NBP might be broken on the other entity's node.
o NBP可能在其他实体的节点上被破坏。
An SNMP entity supporting command generator applications which is dedicated to AppleTalk management might choose to alleviate some of these failures by directly implementing the router portion of NBP. For example, such an entity might already know all the zones on the AppleTalk internet and the networks on which each zone appears. Given an NBP lookup which fails, the entity could send an NBP FwdReq to the network in which the SNMP entity supporting the command responder or notification originator application was last located. If that failed, the station could then send an NBP LkUp (NBP lookup packet) as a directed (DDP) multicast to each network number on that network. Of the above (single) failures, this combined approach will solve the case where either the local router's BrRq-to-FwdReq mechanism is broken or the remote router's FwdReq-to-LkUp mechanism is broken.
支持命令生成器应用程序（专用于AppleTalk管理）的SNMP实体可以选择通过直接实现NBP的路由器部分来缓解其中一些故障。例如，这样的实体可能已经知道AppleTalk internet上的所有区域以及每个区域出现的网络。如果NBP查找失败，实体可以向支持命令响应程序或通知发起人应用程序的SNMP实体最后所在的网络发送NBP FwdReq。如果失败，站点可以将NBP LkUp（NBP查找包）作为定向（DDP）多播发送到该网络上的每个网络号码。在上述（单一）故障中，这种组合方法将解决本地路由器的BrRq到FwdReq机制中断或远程路由器的FwdReq到LkUp机制中断的情况。
This is an optional transport mapping.
这是一个可选的传输映射。
Each instance of a message is serialized onto a single IPX datagram [NOVELL], using the algorithm specified in Section 8.
使用第8节中指定的算法，将消息的每个实例序列化到单个IPX数据报[NOVELL]。
SNMP messages are sent using IPX packet type 4 (i.e., Packet Exchange Protocol).
SNMP消息使用IPX数据包类型4（即数据包交换协议）发送。
It is suggested that administrators configure their SNMP entities supporting command responder applications to listen on IPX socket 36879 (900f hexadecimal). Further, it is suggested that those supporting notification receiver applications be configured to listen on IPX socket 36880 (9010 hexadecimal).
建议管理员将其支持命令响应程序应用程序的SNMP实体配置为在IPX套接字36879（900f十六进制）上侦听。此外，建议将那些支持通知接收器应用程序的应用程序配置为在IPX套接字36880（9010十六进制）上侦听。
When an SNMP entity uses this transport mapping, it must be capable of accepting messages that are at least 546 octets in size. Implementation of larger values is encouraged whenever possible.
当SNMP实体使用此传输映射时，它必须能够接受大小至少为546个八位字节的消息。尽可能鼓励实施更大的价值观。
Historically, in order to support proxy to SNMPv1, as defined in [RFC2576], it was deemed useful to define a transport domain, rfc1157Domain, which indicates the transport mapping for SNMP messages as defined in [RFC1157].
过去，为了支持[RFC2576]中定义的SNMPv1的代理，定义传输域rfc1157Domain被认为是有用的，该域指示[RFC1157]中定义的SNMP消息的传输映射。
When the Basic Encoding Rules [BER] are used for serialization:
当基本编码规则[BER]用于序列化时：
(1) When encoding the length field, only the definite form is used; use of the indefinite form encoding is prohibited. Note that when using the definite-long form, it is permissible to use more than the minimum number of length octets necessary to encode the length field.
(1) 当编码长度字段时，仅使用确定形式；禁止使用不定格式编码。注意，当使用定长形式时，允许使用超过编码长度字段所需的最小长度八位字节数。
(2) When encoding the value field, the primitive form shall be used for all simple types, i.e., INTEGER, OCTET STRING, and OBJECT IDENTIFIER (either IMPLICIT or explicit). The constructed form of encoding shall be used only for structured types, i.e., a SEQUENCE or an IMPLICIT SEQUENCE.
(2) 编码值字段时，应将原语形式用于所有简单类型，即整数、八位字符串和对象标识符（隐式或显式）。构造的编码形式只能用于结构化类型，即序列或隐式序列。
(3) When encoding an object whose syntax is described using the BITS construct, the value is encoded as an OCTET STRING, in which all the named bits in (the definition of) the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 (high order bit) to 1 (low order bit) of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored on receipt.
(3) 当使用BITS结构对语法描述的对象进行编码时，该值被编码为八位组字符串，其中从第一位开始到最后一位的位字符串（定义）中的所有命名位都被置于第一个八位组的位8（高阶位）到1（低阶位）中，然后依次是每个后续八位字节的位8到1，然后是最终后续八位字节所需的位数，从位8开始。最后八位字节的剩余位（如果有）在生成时设置为零，在接收时忽略。
These restrictions apply to all aspects of ASN.1 encoding, including the message wrappers, protocol data units, and the data objects they contain.
这些限制适用于ASN.1编码的所有方面，包括消息包装器、协议数据单元及其包含的数据对象。
As an example of applying the Basic Encoding Rules, suppose one wanted to encode an instance of the GetBulkRequest-PDU [RFC3416]:
作为应用基本编码规则的示例，假设有人想要编码GetBulkRequest PDU[RFC3416]的一个实例：
[5] IMPLICIT SEQUENCE {
request-id 1414684022,
non-repeaters 1,
max-repetitions 2,
variable-bindings {
{ name sysUpTime,
value { unSpecified NULL } },
{ name ipNetToMediaPhysAddress,
value { unSpecified NULL } },
{ name ipNetToMediaType,
value { unSpecified NULL } }
}
}
[5] IMPLICIT SEQUENCE {
request-id 1414684022,
non-repeaters 1,
max-repetitions 2,
variable-bindings {
{ name sysUpTime,
value { unSpecified NULL } },
{ name ipNetToMediaPhysAddress,
value { unSpecified NULL } },
{ name ipNetToMediaType,
value { unSpecified NULL } }
}
}
Applying the BER, this may be encoded (in hexadecimal) as:
应用BER，可将其编码为（十六进制）：
[5] IMPLICIT SEQUENCE a5 82 00 39 INTEGER 02 04 54 52 5d 76 INTEGER 02 01 01 INTEGER 02 01 02 SEQUENCE (OF) 30 2b SEQUENCE 30 0b OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03 NULL 05 00 SEQUENCE 30 0d OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02 NULL 05 00 SEQUENCE 30 0d OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 NULL 05 00
[5] 隐式序列a5 82 00 39整数02 04 54 52 5d 76整数02 01整数02 01 02序列（OF）30 2b序列30 0b对象标识符06 07 2b 06 01 01 01 03 NULL 05 00序列30 0d对象标识符06 09 2b 06 01 01 01 04 16 01 02 NULL 05 00序列30 0d对象标识符06 09 2b 06 01 01 01 01 04 NULL 05 00
Note that the initial SEQUENCE in this example was not encoded using the minimum number of length octets. (The first octet of the length, 82, indicates that the length of the content is encoded in the next two octets.)
请注意，本例中的初始序列未使用最小长度八位字节数进行编码。（长度的第一个八位字节82表示内容的长度在接下来的两个八位字节中编码。）
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
This document is the product of the SNMPv3 Working Group. Some special thanks are in order to the following Working Group members:
本文件是SNMPv3工作组的产品。特别感谢以下工作组成员：
Randy Bush Jeffrey D. Case Mike Daniele Rob Frye Lauren Heintz Keith McCloghrie Russ Mundy David T. Perkins Randy Presuhn Aleksey Romanov Juergen Schoenwaelder Bert Wijnen
Randy Bush Jeffrey D.Case Mike Daniele Rob Frye Lauren Heintz Keith McCloghrie Russ Mundy David T.Perkins Randy Presuhn Aleksey Romanov Juergen Schoenwaelder Bert Wijnen
This version of the document, edited by Randy Presuhn, was initially based on the work of a design team whose members were:
该版本的文件由Randy Presohn编辑，最初基于一个设计团队的工作，其成员为：
Jeffrey D. Case Keith McCloghrie David T. Perkins Randy Presuhn Juergen Schoenwaelder
杰弗里·D·凯斯·基思·麦克洛赫里·大卫·T·珀金斯·兰迪·普雷森·尤尔根·舍恩瓦埃尔德
The previous versions of this document, edited by Keith McCloghrie, was the result of significant work by four major contributors:
本文件的前几个版本由Keith McCloghrie编辑，是四位主要贡献者的重要工作成果：
Jeffrey D. Case Keith McCloghrie Marshall T. Rose Steven Waldbusser
杰弗里·D·凯斯·基思·麦克洛赫里·马歇尔T·罗斯·史蒂文·瓦尔德布瑟
Additionally, the contributions of the SNMPv2 Working Group to the previous versions are also acknowledged. In particular, a special thanks is extended for the contributions of:
此外，SNMPv2工作组对先前版本的贡献也得到了认可。特别感谢以下各方的贡献：
Alexander I. Alten Dave Arneson Uri Blumenthal Doug Book Kim Curran Jim Galvin Maria Greene Iain Hanson Dave Harrington Nguyen Hien Jeff Johnson Michael Kornegay Deirdre Kostick David Levi Daniel Mahoney Bob Natale Brian O'Keefe Andrew Pearson Dave Perkins Randy Presuhn Aleksey Romanov Shawn Routhier Jon Saperia Juergen Schoenwaelder Bob Stewart Kaj Tesink Glenn Waters Bert Wijnen
亚历山大一世。阿尔滕·戴夫·阿内森·乌里·布鲁门塔尔·道格的书金·柯伦·吉姆·高尔文·玛丽亚·格林·伊恩·汉森·戴夫·哈灵顿·阮希恩杰夫·约翰逊·迈克尔·科内盖·德尔德雷·科斯蒂克·大卫·列维·丹尼尔·马奥尼·鲍伯·纳塔莱·布莱恩·奥基夫·安德鲁·皮尔森·戴夫·帕金斯·兰迪·普雷森·阿列克西·罗曼诺夫·肖恩·劳希尔·乔恩·萨佩里亚·朱尔根·斯沃卡伊·特辛克·格伦·沃特斯·伯特·维恩
The SNMPv2-TM MIB module requires the allocation of a single object identifier for its MODULE-IDENTITY. IANA has allocated this object identifier in the snmpModules subtree, defined in the SNMPv2-SMI MIB module.
SNMPv2 TM MIB模块需要为其模块标识分配单个对象标识符。IANA已在SNMPv2 SMI MIB模块中定义的snmpModules子树中分配了此对象标识符。
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change) the objects accessible through a command responder application.
SNMPv1本身不是一个安全的环境。即使网络本身是安全的（例如通过使用IPSec），即使如此，也无法控制安全网络上的谁可以通过命令响应程序应用程序访问和获取/设置（读取/更改）可访问的对象。
It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended.
建议执行者考虑SNMPv3框架提供的安全特性。具体而言，建议使用基于用户的安全模型STD 62、RFC 3414[RFC3414]和基于视图的访问控制模型STD 62、RFC 3415[RFC3415]。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to a MIB is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change) them.
然后，客户/用户有责任确保对访问MIB的SNMP实体进行了正确配置，以便仅向那些拥有确实获取或设置（更改）对象的合法权限的主体（用户）授予对象访问权限。
[BER] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, December 1987.
[BER]信息处理系统.开放系统互连.抽象语法符号1（ASN.1）的基本编码规则规范，国际标准化组织。国际标准88251987年12月。
[IS8072] Information processing systems - Open Systems Interconnection - Transport Service Definition, International Organization for Standardization. International Standard 8072, June 1986.
[IS8072]信息处理系统-开放系统互连-运输服务定义，国际标准化组织。国际标准8072，1986年6月。
[IS8072A] Information processing systems - Open Systems Interconnection - Transport Service Definition - Addendum 1: Connectionless-mode Transmission, International Organization for Standardization. International Standard 8072/AD 1, December 1986.
[IS8072A]信息处理系统-开放系统互连-传输服务定义-附录1：无连接模式传输，国际标准化组织。国际标准8072/AD 1，1986年12月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[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月。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC3414] Blumenthal, U. and B. Wijnen, "The 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月。
[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.，Presohn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，STD 62，RFC 3415，2002年12月。
[RFC3416] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416]Presohn，R.，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMP）的协议操作版本2”，STD 62，RFC 3416，2002年12月。
[APPLETALK] Sidhu, G., Andrews, R. and A. Oppenheimer, Inside AppleTalk (second edition). Addison-Wesley, 1990.
[APPLETALK]Sidhu，G.，Andrews，R.和A.Oppenheimer，《APPLETALK内部》（第二版）。艾迪生·韦斯利，1990年。
[NOVELL] Network System Technical Interface Overview. Novell, Inc., June 1989.
[NOVELL]网络系统技术接口概述。诺维尔公司，1989年6月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157]Case，J.，Fedor，M.，Schoffstall，M.和J.Davin，“简单网络管理协议”，STD 15，RFC 1157，1990年5月。
[RFC1742] Waldbusser, S. and K. Frisa, "AppleTalk Management Information Base II", RFC 1742, January 1995.
[RFC1742]Waldbusser，S.和K.Frisa，“AppleTalk管理信息库II”，RFC 1742，1995年1月。
[RFC2576] 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", RFC 2576, March 2000.
[RFC2576]Frye，R.，Levi，D.，Routhier，S.和B.Wijnen，“互联网标准网络管理框架第1版、第2版和第3版之间的共存”，RFC 25762000年3月。
[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月。
[RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for Transport Addresses", RFC 3419, November 2002.
[RFC3419]Daniele，M.和J.Schoenwaeld，“运输地址的文本约定”，RFC 3419，2002年11月。
This document differs from RFC 1906 only in editorial improvements. The protocol is unchanged.
本文件与RFC 1906仅在编辑改进方面有所不同。协议没有改变。
Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA
美国加利福尼亚州圣何塞北第一街2141号Randy Presohn BMC软件公司，邮编95131
Phone: +1 408 546-1006
EMail: randy_presuhn@bmc.com
Phone: +1 408 546-1006
EMail: randy_presuhn@bmc.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。