Network Working Group E. Lear
Request for Comments: 4744 Cisco Systems
Category: Standards Track K. Crozier
December 2006
Network Working Group E. Lear
Request for Comments: 4744 Cisco Systems
Category: Standards Track K. Crozier
December 2006
Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)
通过块可扩展交换协议（BEEP）使用NETCONF协议
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document specifies an application protocol mapping for the Network Configuration Protocol (NETCONF) over the Blocks Extensible Exchange Protocol (BEEP).
本文档指定了块可扩展交换协议（BEEP）上网络配置协议（NETCONF）的应用程序协议映射。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Why BEEP? ..................................................2
2. BEEP Transport Mapping ..........................................2
2.1. NETCONF Session Establishment ..............................2
2.2. Starting a Channel for NETCONF .............................4
2.3. NETCONF Session Usage ......................................5
2.4. NETCONF Session Teardown ...................................5
2.5. BEEP Profile for NETCONF ...................................6
3. Security Considerations .........................................6
4. IANA Considerations .............................................7
5. Acknowledgments .................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
1. Introduction ....................................................2
1.1. Why BEEP? ..................................................2
2. BEEP Transport Mapping ..........................................2
2.1. NETCONF Session Establishment ..............................2
2.2. Starting a Channel for NETCONF .............................4
2.3. NETCONF Session Usage ......................................5
2.4. NETCONF Session Teardown ...................................5
2.5. BEEP Profile for NETCONF ...................................6
3. Security Considerations .........................................6
4. IANA Considerations .............................................7
5. Acknowledgments .................................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
The NETCONF protocol [1] defines a simple mechanism through which a network device can be managed. NETCONF is designed to be usable over a variety of application protocols. This document specifies an application protocol mapping for NETCONF over the Blocks Extensible Exchange Protocol (BEEP) [7].
NETCONF协议[1]定义了一种简单的机制，通过该机制可以管理网络设备。NETCONF设计为可在各种应用程序协议上使用。本文档指定NETCONF在块可扩展交换协议（BEEP）[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 RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
Use of BEEP is natural as an application protocol for transport of XML. As a peer-to-peer protocol, BEEP provides an easy way to implement NETCONF, no matter which side of the connection was the initiator. This "bidirectionality" allows for either manager or agent to initiate a connection. This is particularly important to support large numbers of intermittently connected devices, as well as those devices that must reverse the management connection in the face of firewalls and network address translators (NATs).
使用BEEP作为XML传输的应用程序协议是很自然的。作为一种对等协议，BEEP提供了一种实现NETCONF的简单方法，无论连接的哪一侧是发起方。这种“双向性”允许管理器或代理启动连接。这对于支持大量间歇性连接的设备以及面对防火墙和网络地址转换器（NAT）时必须反转管理连接的设备尤为重要。
BEEP makes use of the Simple Authentication and Security Layer (SASL) [3]. The SASL profile used by BEEP allows for a simple and direct mapping to the existing security model for command line interface (CLI), while Transport Layer Security (TLS) [4] provides a strong, well-tested encryption mechanism with either server or server and client-side authentication.
BEEP使用简单身份验证和安全层（SASL）[3]。BEEP使用的SASL配置文件允许简单直接地映射到命令行界面（CLI）的现有安全模型，而传输层安全性（TLS）[4]提供了一种强大的、经过良好测试的加密机制，具有服务器或服务器以及客户端身份验证。
All NETCONF over BEEP implementations MUST implement the profile and functional mapping between NETCONF and BEEP as described below.
所有NETCONF over BEEP实现必须实现NETCONF和BEEP之间的配置文件和功能映射，如下所述。
For purposes of this document, a manager is a NETCONF client, and an agent is a NETCONF server. Use of client/server language in BEEP is avoided because of the common notion that in networking clients connect to servers.
在本文档中，管理器是NETCONF客户机，代理是NETCONF服务器。避免在BEEP中使用客户机/服务器语言，因为在网络中，客户机连接到服务器是一种常见的概念。
Managers may be either BEEP listeners or initiators. Similarly, agents may be either listeners or initiators. To establish a connection, the initiator connects to the listener on TCP port 831. Thus, the initial exchange takes place without regard to whether a manager or the agent is the initiator. After the transport connection is established, as greetings are exchanged, they SHOULD
管理者可以是蜂鸣音监听器，也可以是发起者。类似地，代理可以是侦听器或启动器。要建立连接，启动器将连接到TCP端口831上的侦听器。因此，初始交换的发生与管理者或代理是发起人无关。建立传输连接后，在交换问候语时，他们应该
each announce their support for TLS and optionally SASL. Once BEEP greeting messages are exchanged, if TLS is to be used and available by both parties, the listener STARTs a channel with the TLS profile.
每个人都宣布支持TLS和可选的SASL。一旦交换了嘟嘟声问候信息，如果双方都要使用和使用TLS，则侦听器将使用TLS配置文件启动一个频道。
Once TLS has been started, a new BEEP greeting message is sent by both initiator and listener, as required by the BEEP RFC.
一旦TLS启动，启动器和侦听器将根据BEEP RFC的要求发送新的BEEP问候消息。
After all BEEP greeting messages are exchanged in order for roles to be clear, the agent MUST advertise the NETCONF profile. The manager MUST NOT advertise the NETCONF profile. If the agent side of the communication (either initiator or listener) receives a BEEP <greeting> element that contains the NETCONF profile, it MUST close the connection. Similarly, if neither side issues a NETCONF profile it is equally an error, and the listener MUST close the connection.
在交换所有蜂鸣问候消息以清除角色后，代理必须公布NETCONF配置文件。管理器不得公布NETCONF配置文件。如果通信的代理端（启动器或侦听器）收到包含NETCONF配置文件的BEEP<greeting>元素，则必须关闭连接。类似地，如果任何一方都没有发出NETCONF配置文件，这同样是一个错误，侦听器必须关闭连接。
At this point, if SASL is desired, the initiator starts a BEEP channel to perform a SASL exchange to authenticate itself. Upon completion of authentication the channel is closed. That is, the channel is exclusively used to authenticate.
此时，如果需要SASL，启动器将启动一个BEEP通道，以执行SASL交换以进行自身身份验证。认证完成后，通道关闭。也就是说，通道专门用于身份验证。
Examples of both TLS and SASL profiles can be found in [7].
TLS和SASL剖面的示例见[7]。
It is anticipated that the SASL PLAIN mechanism will be heavily used in conjunction with TLS [5]. In such cases, in accordance with RFC 2595 the PLAIN mechanism MUST NOT be advertised in the first BEEP <greeting>, but only in the one following a successful TLS negotiation. This applies only if TLS and SASL PLAIN mechanisms are both to be used. To avoid risk of eavesdropping, the SASL PLAIN mechanism MUST NOT be used over unencrypted channels. More specifics about the use of SASL and TLS are mentioned in Security Considerations below.
预计SASL平面机构将与TLS一起大量使用[5]。在这种情况下，根据RFC 2595，普通机构不得在第一次嘟嘟声<greeting>中宣传，而只能在TLS协商成功后的嘟嘟声中宣传。这仅适用于同时使用TLS和SASL普通机构的情况。为避免窃听风险，不得在未加密通道上使用SASL普通机制。有关SASL和TLS使用的更多细节，请参见下面的安全注意事项。
Once authentication has occurred, there is no need to distinguish between initiator and listener. We now distinguish between manager and agent, and it is assumed that each knows its role in the conversation.
一旦发生身份验证，就不需要区分启动器和侦听器。现在我们区分经理和代理人，假设他们都知道自己在对话中的角色。
The manager now establishes a new channel and specifies the single NETCONF profile. For example:
管理器现在建立一个新通道并指定单个NETCONF配置文件。例如：
(M = Manager; A = Agent)
(M = Manager; A = Agent)
M: MSG 0 1 . 10 48 118
M: Content-type: application/beep+xml
M:
M: <start number="1">
M: <profile uri="http://iana.org/beep/netconf" />
M: </start>
M: END
A: RPY 0 1 . 38 87
A: Content-Type: application/beep+xml
A:
A: <profile uri="http://iana.org/beep/netconf" />
A: END
M: MSG 0 1 . 10 48 118
M: Content-type: application/beep+xml
M:
M: <start number="1">
M: <profile uri="http://iana.org/beep/netconf" />
M: </start>
M: END
A: RPY 0 1 . 38 87
A: Content-Type: application/beep+xml
A:
A: <profile uri="http://iana.org/beep/netconf" />
A: END
At this point, we are ready to proceed on BEEP channel 1 with NETCONF operations.
此时，我们已准备好在BEEP通道1上进行NETCONF操作。
NETCONF messages are transmitted with a Content-type header set to "text/xml".
NETCONF消息通过设置为“text/xml”的内容类型头进行传输。
Next the manager and the agent exchange NETCONF <hello> elements on the new channel so that each side learns the other's capabilities. This occurs through a MSG. Each side will then respond positively. The following example is adapted from [1] Section 8.1:
接下来，管理器和代理交换新通道上的NETCONF<hello>元素，以便双方了解对方的能力。这是通过MSG实现的。然后，双方都将作出积极回应。以下示例改编自[1]第8.1节：
A: MSG 1 0 . 0 457
A: Content-type: application/beep+xml
A:
A: <?xml version='1.0' encoding="UTF-8"?>
A: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
A: <capabilities>
A: <capability>
A: urn:ietf:params:netconf:base:1.0
A: </capability>
A: <capability>
A: urn:ietf:params:netconf:capability:startup:1.0
A: </capability>
A: <capability>
A: http://example.net/router/2.3/core#myfeature
A: </capability>
A: </capabilities>
A: MSG 1 0 . 0 457
A: Content-type: application/beep+xml
A:
A: <?xml version='1.0' encoding="UTF-8"?>
A: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
A: <capabilities>
A: <capability>
A: urn:ietf:params:netconf:base:1.0
A: </capability>
A: <capability>
A: urn:ietf:params:netconf:capability:startup:1.0
A: </capability>
A: <capability>
A: http://example.net/router/2.3/core#myfeature
A: </capability>
A: </capabilities>
A: <session-id>4</session-id>
A: </hello>
A: END
A: <session-id>4</session-id>
A: </hello>
A: END
M: RPY 1 0 . 0 0 M: END
M:RPY10。0米：结束
Future NETCONF capabilities may require additional BEEP channels. When such capabilities are defined, a BEEP mapping must be defined as well.
未来的NETCONF功能可能需要额外的蜂鸣通道。定义此类功能时，还必须定义一个BEEP映射。
At this point, the NETCONF session is established, and capabilities have been exchanged.
此时，NETCONF会话已建立，功能已交换。
Nearly all NETCONF operations are executed through the <rpc> element. To issue a remote procedure call (RPC), the manager transmits on the operational channel a BEEP MSG containing the RPC and its arguments. In accordance with the BEEP standard, RPC requests may be split across multiple BEEP frames.
几乎所有的NETCONF操作都是通过<rpc>元素执行的。要发出远程过程调用（RPC），管理器会在操作通道上发送一条包含RPC及其参数的蜂鸣消息。根据BEEP标准，RPC请求可以在多个BEEP帧之间分割。
Once received and processed, the agent responds with BEEP RPY messages on the same channel with the response to the RPC. In accordance with the BEEP standard, responses may be split across multiple BEEP frames.
收到并处理后，代理在同一通道上用BEEP RPY消息响应RPC。根据蜂鸣音标准，响应可在多个蜂鸣音帧中分割。
Upon receipt of <close-session> from the manager, once the agent has completed all RPCs, it will close BEEP channel 0. When an agent needs to initiate a close, it will do so by closing BEEP channel 0. Although not required to do so, the agent should allow for a reasonable period for a manager to release an existing lock prior to initiating a close. Once the agent has closed channel 0, all locks are released, and each side follows teardown procedures as specified in [8]. Having received a BEEP close or having sent <close-session>, a manager MUST NOT send further requests. If there are additional activities due to expanded capabilities, they MUST cease in an orderly manner and should be properly described in the capability mapping.
在收到管理器的<close session>后，一旦代理完成所有RPC，它将关闭BEEP通道0。当代理需要启动关闭时，它将通过关闭嘟嘟声通道0来启动关闭。虽然不需要这样做，但代理行应允许经理在启动关闭前有一段合理的时间释放现有锁。一旦代理关闭通道0，所有锁将被释放，并且每一方都遵循[8]中指定的拆卸过程。收到“关闭”蜂鸣音或发送了<close session>，经理不得再发送请求。如果由于扩展能力而有额外活动，则必须有序地停止这些活动，并应在能力映射中正确描述。
Profile Identification: http://iana.org/beep/netconf
Profile Identification: http://iana.org/beep/netconf
Messages exchanged during Channel Creation: not applicable
通道创建期间交换的消息：不适用
Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply"
开始一对一交换的消息：“hello”、“rpc”、“rpc reply”
Messages in positive replies: "rpc-reply"
肯定回复中的消息：“rpc回复”
Messages in negative replies: "rpc-reply"
否定回复中的消息：“rpc回复”
Messages in one-to-many exchanges: none
一对多交换中的消息：无
Message syntax: [1]
消息语法：[1]
Message semantics: [1]
消息语义：[1]
Contact Information: See the "Author's Address" section of this memo.
联系方式：参见本备忘录的“作者地址”部分。
Configuration information is by its very nature sensitive. Its transmission in the clear and without integrity checking leaves devices open to classic so-called "person-in-the-middle" attacks. Configuration information often times contains passwords, user names, service descriptions, and topological information, all of which are sensitive. A NETCONF application protocol, therefore, must minimally support options for both confidentiality and authentication.
配置信息本质上是敏感的。它以清晰且无完整性检查的方式传输，使得设备容易受到经典的所谓“中间人”攻击。配置信息通常包含密码、用户名、服务描述和拓扑信息，所有这些信息都是敏感的。因此，NETCONF应用程序协议必须至少支持机密性和身份验证选项。
The BEEP mapping described in this document addresses both confidentiality and authentication in a flexible manner through the use of TLS and SASL profiles. Confidentiality is provided via the TLS profile and is used as discussed above. In addition, the server certificate shall serve as the server's authentication to the client. The client MUST be prepared to recognize and validate a server certificate and SHOULD by default reject invalid certificates.
本文档中描述的BEEP映射通过使用TLS和SASL配置文件以灵活的方式处理机密性和身份验证。机密性通过TLS配置文件提供，并如上所述使用。此外，服务器证书应作为服务器对客户端的身份验证。客户端必须准备好识别和验证服务器证书，并且默认情况下应拒绝无效证书。
In order to validate a certificate, the client must be able to access a trust anchor. While such validation methods are beyond the scope of this document, they will depend on the type of device and circumstance. Both the implementor and the administrator are cautioned to be aware of any circular dependencies that various methods may introduce. For instance, Online Certificate Status Protocol (OCSP) servers may not be available in a network cold-start scenario and would be ill-advised for core routers to depend on to receive configuration at boot.
为了验证证书，客户端必须能够访问信任锚。虽然此类验证方法超出了本文件的范围，但它们将取决于设备类型和环境。提醒实现者和管理员注意各种方法可能引入的任何循环依赖关系。例如，在线证书状态协议（OCSP）服务器在网络冷启动场景中可能不可用，因此不建议核心路由器依靠它在引导时接收配置。
For client-side authentication, there are several options. The client MAY provide a certificate during the initiation phase of TLS, in which case the subject of that certificate shall be considered principle for authentication purposes. Once again, server implementors should be aware of any interdependencies that could be created through protocols used to validate trust anchors.
对于客户端身份验证，有几个选项。客户可在TLS启动阶段提供证书，在这种情况下，出于认证目的，应将该证书的主题视为原则。同样，服务器实现者应该知道可以通过用于验证信任锚的协议创建的任何相互依赖关系。
TLS endpoints may be authorized based on subject name or certificate authority (CA), depending on circumstances. For instance, it would be unwise for a core Internet router to allow a netconf agent connection simply based on a valid certificate signed by a common CA, but not unreasonable to allow a connection from an agent with a particular distinguished name. On the other hand, it might be desirable for enterprises to trust certificates signed by CAs of their network operations team.
TLS端点可以根据使用者名称或证书颁发机构（CA）进行授权，具体取决于具体情况。例如，核心Internet路由器仅基于由公共CA签名的有效证书来允许netconf代理连接是不明智的，但允许来自具有特定可分辨名称的代理的连接也是合理的。另一方面，企业可能希望信任其网络运营团队的CA签署的证书。
In the case where the client has not authenticated through TLS, the server SHOULD advertise one or more SASL profiles, from which the client will choose. In the singular case where TLS is established, the minimum profile MAY be PLAIN. Otherwise, implementations MUST support the DIGEST-MD5 profile as described in [6], and they MAY support other profiles such as the One-Time Password (OTP) mechanism [10].
如果客户机没有通过TLS进行身份验证，服务器应该公布一个或多个SASL配置文件，客户机将从中进行选择。在建立TLS的单一情况下，最小轮廓可能是平坦的。否则，实现必须支持[6]中所述的DIGEST-MD5配置文件，并且可以支持其他配置文件，如一次性密码（OTP）机制[10]。
Different environments may well allow different rights prior to and then after authentication. An authorization model is not specified in this document. When an operation is not properly authorized, then a simple rpc-error containing "permission denied" is sufficient. Note that authorization information may be exchanged in the form of configuration information, which is all the more reason to ensure the security of the connection.
在身份验证之前和之后，不同的环境可能允许不同的权限。本文档中未指定授权模型。当操作未正确授权时，包含“权限被拒绝”的简单rpc错误就足够了。请注意，授权信息可以以配置信息的形式交换，这更是确保连接安全的原因。
IANA assigned TCP port (831) for NETCONF over BEEP.
IANA通过BEEP为NETCONF分配了TCP端口（831）。
This work is the product of the NETCONF IETF working group, and many people have contributed to the NETCONF discussion. Most notably, Rob Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and Margaret Wasserman all contributed in some fashion to this work, which was originally to be found in the NETCONF base protocol specification. Thanks also to Weijing Chen, Keith Allen, Juergen Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very constructive participation. The authors would also like to thank Elwyn Davies for his constructive review.
这项工作是NETCONF IETF工作组的成果，许多人对NETCONF的讨论做出了贡献。最值得注意的是，Rob Ens、Phil Schafer、Andy Bierman、Wes Hardiger、Ted Goddard和Margaret Wasserman都以某种方式对这项工作做出了贡献，这项工作最初可以在NETCONF基本协议规范中找到。还要感谢陈伟静、基思·艾伦、于尔根·舍恩瓦埃尔德、马歇尔·罗斯和埃蒙·奥图阿泰尔的建设性参与。作者还要感谢Elwyn Davies的建设性评论。
[1] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[1] Enns，R.，编辑，“网络配置协议”，RFC 47412006年12月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[3] Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC4422006年6月。
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[4] Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[5] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.
[5] Newman，C.“将TLS与IMAP、POP3和ACAP一起使用”，RFC 25951999年6月。
[6] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[6] Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[7] Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[8] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[8] Rose，M.“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[9] Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium, First Edition, http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.
[9] Sperberg McQueen，C.，Paoli，J.，Maler，E.，和T.Bray，“可扩展标记语言（XML）1.0（第二版）”，万维网联盟，第一版，http://www.w3.org/TR/2000/REC-xml-20001006，2000年10月。
[10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, October 1998.
[10] Newman，C.，“一次性密码SASL机制”，RFC 2444，1998年10月。
Authors' Addresses
作者地址
Eliot Lear Cisco Systems Glatt-com CH-8301 Glattzentrum, Zurich CH
Eliot Lear思科系统公司Glatt com CH-8301 Glattzentrum，苏黎世
EMail: lear@cisco.com
EMail: lear@cisco.com
Ken Crozier
肯克罗泽
EMail: ken.crozier@gmail.com
EMail: ken.crozier@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。