Network Working Group K. Carlberg
Request for Comments: 3689 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
Network Working Group K. Carlberg
Request for Comments: 3689 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
General Requirements for Emergency Telecommunication Service (ETS)
应急电信服务（ETS）的一般要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
This document presents a list of general requirements in support of Emergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s).
本文件列出了支持应急电信服务（ETS）的一般要求清单。本文件未提供这些要求的解决方案。与特定应用或应用类型相关的附加要求将在单独的文件中规定。
Effective telecommunications capabilities can be imperative to facilitate immediate recovery operations for serious disaster events, such as, hurricanes, floods, earthquakes, and terrorist attacks. Disasters can happen any time, any place, unexpectedly. Quick response for recovery operations requires immediate access to any public telecommunications capabilities at hand. These capabilities include: conventional telephone, cellular phones, and Internet access via online terminals, IP telephones, and wireless PDAs. The commercial telecommunications infrastructure is rapidly evolving to Internet-based technology. Therefore, the Internet community needs to consider how it can best support emergency management and recovery operations.
有效的电信能力对于促进飓风、洪水、地震和恐怖袭击等严重灾害事件的立即恢复行动至关重要。灾难可以在任何时间、任何地点意外发生。对恢复操作的快速响应要求立即访问手头的任何公共电信功能。这些功能包括：通过在线终端、IP电话和无线PDA的传统电话、移动电话和互联网接入。商业电信基础设施正在迅速演变为基于互联网的技术。因此，互联网社区需要考虑如何能够最好地支持急诊科管理和恢复操作。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
Label: The term label has been used for a number of years in various IETF protocols. It is simply an identifier. It can be manifested in the form of a numeric, alphanumeric value, or a specific bit pattern, within a field of a packet header. The exact form is dependent on the protocol in which it is used.
标签：标签一词已在各种IETF协议中使用多年。它只是一个标识符。它可以在数据包头的字段中以数字、字母数字值或特定位模式的形式显示。具体形式取决于使用它的协议。
An example of a label can be found in RFC 3031; the Multiprotocol Label Switching Architecture. Another example can be found in RFC 2597 (and updated by RFC 3260); a bit pattern for the Assured Forwarding PHB group. This latter case is a type of label that does not involve routing. Note that specification of labels is outside the scope of this document. Further comments on labels are discussed below in section 3.
标签示例可在RFC 3031中找到；多协议标签交换体系结构。另一个例子可以在RFC2597中找到（并由RFC3260更新）；保证转发PHB组的位模式。后一种情况是一种不涉及布线的标签类型。请注意，标签规格不在本文件范围内。关于标签的进一步评论将在下文第3节中讨论。
The following are standards from other organizations that are specifically aimed at supporting emergency communications. Most of these standards specify telephony mechanisms or define telephony related labels.
以下是其他组织专门为支持紧急通信而制定的标准。这些标准中的大多数都指定了电话机制或定义了与电话相关的标签。
Standard / Organization
--------------------------
1) T1.631 / ANSI
2) E.106 / ITU
3) F.706 / ITU
4) H.460.4 / ITU
5) I.255.3 / ITU
Standard / Organization
--------------------------
1) T1.631 / ANSI
2) E.106 / ITU
3) F.706 / ITU
4) H.460.4 / ITU
5) I.255.3 / ITU
The first specifies an indicator for SS7 networks that signals the need for a High Probability of Completion (HPC) service. This indicator is termed National Security / Emergency Preparedness (NS/EP) The T1.631 standard [2] is the basis for the U.S. Government Emergency Telecommunications Service (GETS) [7].
第一个为SS7网络指定一个指示器，表示需要高完成概率（HPC）服务。该指标称为国家安全/应急准备（NS/EP）。T1.631标准[2]是美国政府应急电信服务（GETS）[7]的基础。
The second standard describes functional capabilities for the Public Switched Telephone Network (PSTN) to support International Emergency Preparedness System (IEPS) [3]. From the PSTN perspective, one can view NS/EP as a standard with national boundaries, while IEPS is an extension to international boundaries for telephony.
第二个标准描述了公共交换电话网（PSTN）支持国际应急准备系统（IEPS）的功能能力[3]。从PSTN的角度来看，可以将NS/EP视为具有国家边界的标准，而IEPS是电话国际边界的延伸。
The third standard extends IEPS beyond the scope of telephony into other forms that encompass multimedia [4].
第三个标准将IEP扩展到电话以外的其他形式，包括多媒体[4]。
The fourth and fifth standard focuses on a multi-level labeling mechanism distinguishing emergency type traffic from that which is not. The former case focuses on call signaling for H.323 networks [5], while the latter has been applied for both SS7 [6] and data networks.
第四和第五个标准侧重于区分紧急类型流量和非紧急类型流量的多级标记机制。前者侧重于H.323网络的呼叫信令[5]，而后者已应用于SS7[6]和数据网络。
While the above standards are outside the scope of the IETF, they do represent existing efforts in the area of emergency communications, as opposed to conceptual of potential possibilities. They act as example manifestations of Emergency Telecommunications Service (ETS).
虽然上述标准不在IETF的范围内，但它们确实代表了应急通信领域的现有工作，而不是潜在可能性的概念性评估。它们是紧急电信服务（ETS）的典型表现形式。
One problem faced by the IEPREP working group entails how, and to what degree, support for these standards are to be realized within the Internet architecture and the existing suite of IETF standards and associated working groups. This support could be in the form of interoperability with corresponding IETF protocols.
IEPREP工作组面临的一个问题是如何以及在多大程度上在互联网体系结构和现有IETF标准套件及相关工作组中实现对这些标准的支持。这种支持可以是与相应IETF协议的互操作性。
A subsequent problem is to ensure that requirements associated with potential support is not focused just on IP telephony applications. The I-Am-Alive (IAA) database system is an example of an ETS type application used in Japan that supports both signaled and non-signaled access by users [10]. It is a distributed database system that provides registration, querying, and reply primitives to participants during times of an emergency (e.g., an earthquake) so that others can make an after-the-event determination about the status of a person. In this case, a separate signaling protocol like SIP is not always required to establish or maintain a connection.
接下来的一个问题是确保与潜在支持相关的需求不仅仅集中在IP电话应用程序上。I-Am-Alive（IAA）数据库系统是在日本使用的ETS类型应用程序的一个示例，该应用程序支持用户的信号和非信号访问[10]。它是一个分布式数据库系统，在紧急情况（如地震）期间为参与者提供注册、查询和回复原语，以便其他人可以在事件发生后确定人员的状态。在这种情况下，并不总是需要像SIP这样的单独信令协议来建立或维护连接。
Given the case where signaling is optional, requirements and subsequent solutions that address these problems must not assume the existence of signaling and must be able to support applications that only have labels in data packets. These label(s) may be in various places, such as the application or IP header.
考虑到信令是可选的情况，解决这些问题的需求和后续解决方案不得假设存在信令，并且必须能够支持仅在数据包中具有标签的应用程序。这些标签可能位于不同的位置，例如应用程序或IP头。
This document defines a set of general system requirements to achieve support for ETS and addressing the problem space presented in Section 1.3. In defining these requirements, we consider known systems such as GETS and IAA that represent existing manifestations of emergency related systems. These two examples also represent a broad spectrum of characteristics that range from signaling & interactive non-elastic applications to non-signaled & elastic applications.
本文件定义了一套通用系统要求，以实现对ETS的支持，并解决第1.3节中提出的问题空间。在定义这些要求时，我们考虑已知的系统，如GET和IAA，表示急诊科相关系统的现有表现。这两个示例还代表了从信令和交互式非弹性应用到非信令和弹性应用的广泛特性。
We stress that ETS, and its associated requirements, is not the only means of supporting authorized emergency communications. It is simply an approach influenced by existing systems and standards.
我们强调，ETS及其相关要求并非支持授权紧急通信的唯一手段。这只是一种受现有系统和标准影响的方法。
Solutions to requirements are not defined. This document does not specify protocol enhancements or specifications. Requirements for specific types of applications that go beyond the general set stated in section 3 are to be specified in other document(s). At the current writing of this document, [9] has been written for the case of IP telephony.
未定义需求的解决方案。本文档未指定协议增强功能或规范。超出第3节所述一般设置的特定应用类型的要求将在其他文件中规定。在本文件当前编写时，[9]是针对IP电话的情况编写的。
The current IEPREP charter stipulates that any proposed solution to support ETS that responds to the requirements of this document are to be developed in other working groups. We note that other specific requirements (like that of IP telephony) may be defined as an extension of the general requirements presented in section 3 below.
当前的IEPREP章程规定，任何支持ETS的建议解决方案，如符合本文件的要求，将由其他工作组制定。我们注意到，其他特定要求（如IP电话）可定义为下文第3节所述一般要求的延伸。
While the problem space stated in section 1.3 includes standards related to telephony, this document is meant to be broader in scope. Hence, emulation of specific architectures, like the PSTN, or focus on a specific application is out of scope. Further, the specifications of requirements that are aimed at adhering to regulations or laws of governments is also out of the scope of this document. The focus of the IETF and its working groups is technical positions that follow the architecture of the Internet.
虽然第1.3节中所述的问题空间包括与电话相关的标准，但本文件的范围更广。因此，对特定体系结构（如PSTN）的仿真或对特定应用程序的关注超出了范围。此外，旨在遵守政府法规或法律的要求规范也不在本文件范围内。IETF及其工作组的重点是遵循互联网架构的技术职位。
Another item that is not in scope of this document is mandating acceptance and support of the requirements presented in this document. There is an expectation that business contracts, (e.g., Service Level Agreements), will be used to satisfy those requirements that apply to service providers. Absence of an SLA implies best effort service is provided.
不在本文件范围内的另一项是强制接受和支持本文件中提出的要求。人们期望业务合同（如服务水平协议）将用于满足适用于服务提供商的要求。缺少SLA意味着提供了尽力而为的服务。
These are general requirements that apply to authorized emergency telecommunications service. The first requirement is presented as a conditional one since not all applications use or are reliant on signaling.
这些是适用于授权紧急电信服务的一般要求。第一个需求是有条件的，因为并非所有应用程序都使用或依赖于信令。
1) Signaling
1) 信号
IF signaling is to be used to convey the state or existence of emergency, then signaling mechanism(s) MUST exist to carry applicable labels.
如果信号用于传达紧急状态或存在紧急情况，则必须存在信号机制，以携带适用的标签。
2) Labels
2) 标签
Labels may exist in various forms at different layers. They might be carried as part of signaling, and/or as part of the header of a data packet. Labels from different layers are NOT required to be the same, but MAY be related to each other.
标签可能以各种形式存在于不同的层中。它们可以作为信令的一部分和/或作为数据分组的报头的一部分来携带。不同图层的标签不要求相同，但可能相互关联。
3) Policy
3) 政策
Policy MUST be kept separate from label(s). This topic has generated a fair amount of debate, and so we provide additional guidance from the following:
保险单必须与标签分开保存。这个话题引起了相当多的争论，因此我们从以下方面提供了额外的指导：
A set of labels may be defined as being related to each other. Characteristics (e.g., drop precedence) may also be attributed to these labels. [11] is an example of a related set of labels based on a specific characteristic.
一组标签可以定义为相互关联。这些标签也可能具有特征（例如，丢弃优先级）。[11] 是基于特定特征的相关标签集的示例。
However, the mechanisms used to achieve a stated characteristic MUST NOT be stated in the definition of a label. Local policy determines mechanism(s) used to achieve or support a specific characteristic. This allows for the possibility of different mechanisms to achieve the same stated characteristic.
但是，标签定义中不得说明用于实现规定特性的机制。本地策略确定用于实现或支持特定特性的机制。这允许使用不同的机制来实现相同的规定特性。
The interaction between unrelated labels MUST NOT be embedded within the definition of a label. Local policy states the actions (if any) to be taken if unrelated labeled traffic merges at a node.
不相关标签之间的交互不得嵌入标签的定义中。本地策略说明在节点上合并不相关的标记流量时要采取的操作（如果有）。
Finally, labels may have additional characteristics added to them as a result of local policy.
最后，由于当地政策，标签可能会添加其他特性。
4) Network Functionality
4) 网络功能
Functionality to support a better than best effort SHOULD focus on probability versus guarantees. Probability can be realized in terms of reduced probability of packet loss, and/or minimal jitter, and/or minimal end-to-end delay. There is NO requirement that a better than best effort functionality MUST exist. There is NO requirement that if a better than best effort functionality exists then it must be ubiquitous between end users.
支持优于最佳努力的功能应侧重于概率与保证。概率可以通过降低分组丢失概率和/或最小抖动和/或最小端到端延迟来实现。不要求必须存在比尽力而为更好的功能。没有要求如果存在比最佳努力更好的功能，那么它必须在最终用户之间无处不在。
The following are security related requirements that emerge given the requirements 1 through 4 above.
以下是根据上述要求1至4提出的安全相关要求。
5) Authorization
5) 批准
Authorization is a method of validating that a user or some traffic is allowed by policy to use a particular service offering.
授权是一种验证策略是否允许用户或某些流量使用特定服务产品的方法。
Mechanisms must be implemented so that only authorized users have access to emergency telecommunications services. Any mechanism for providing such authorization beyond closed private networks SHOULD meet IETF Security Area criterion (e.g., clear-text passwords would not generally be acceptable). Authorization protects network resources from excessive use, from abuse, and might also support billing and accounting for the offered service.
必须实施各种机制，以便只有经授权的用户才能获得紧急电信服务。在封闭的专用网络之外提供此类授权的任何机制都应符合IETF安全区域标准（例如，明文密码通常不被接受）。授权可以保护网络资源不被过度使用和滥用，还可以支持对提供的服务进行计费和记帐。
Such authorization mechanisms SHOULD be flexible enough to provide various levels of restriction and authorization depending on the expectations of a particular service or customer.
此类授权机制应足够灵活，以根据特定服务或客户的期望提供不同级别的限制和授权。
6) Integrity & Authentication
6) 完整性与认证
In practice, authentication and integrity for IP based communications are generally bound within a single mechanism, even though conceptually they are different. Authentication ensures that the user or traffic is who it claims to be. Integrity offers assurance that unauthorized modifications to objects can be detected.
在实践中，基于IP的通信的身份验证和完整性通常绑定在单个机制中，即使在概念上它们是不同的。身份验证可确保用户或流量是其声称的用户或流量。完整性保证可以检测到对对象的未经授权的修改。
Authorized emergency traffic needs to have reduced risk of adverse impact from denial of service. This implies a need to ensure integrity of the authorized emergency network traffic. It should be noted, though, that mechanisms used to ensure integrity can also be subject to Denial of Service attacks.
授权的紧急通信需要降低拒绝服务造成不利影响的风险。这意味着需要确保授权应急网络流量的完整性。但应注意，用于确保完整性的机制也可能受到拒绝服务攻击。
Users of emergency network services SHOULD consider deploying end-to-end integrity and authentication, rather than relying on services that might be offered by any single provider of emergency network services. Users SHOULD also carefully consider which application-layer security services might be appropriate to use.
急诊科网络服务的使用者应该考虑部署端到端的完整性和认证，而不是依赖急诊科网络服务的任何提供者提供的服务。用户还应该仔细考虑哪些应用层安全服务可能适合使用。
7) Confidentiality
7) 保密性
Some emergency communications might have a requirement that they not be susceptible to interception or viewing by others, due to the sensitive and urgent nature of emergency response activities. An emergency telecommunications service MAY offer options to provide confidentiality for certain authorized user traffic.
由于应急响应活动的敏感性和紧迫性，一些应急通信可能要求它们不易被他人截获或查看。紧急电信服务可提供为某些授权用户通信提供保密性的选项。
Consistent with other IETF standards and the Internet Architecture, this document recommends that IEPREP users SHOULD deploy end-to-end security mechanisms, rather than rely on security services that might be offered by a single network operator. IEPREP users SHOULD carefully consider security alternatives (e.g., PGP, TLS, IPsec transport-mode) at different layers (e.g., Application Layer, Session Layer, Transport Layer) of the Internet Architecture before deployment.
与其他IETF标准和互联网体系结构一致，本文件建议IEPREP用户应部署端到端安全机制，而不是依赖单一网络运营商提供的安全服务。IEEEP用户应该在部署之前仔细考虑Internet架构的不同层（例如，应用层、会话层、传输层）的安全备选方案（例如PGP、TLS、IPSec传输模式）。
This section presents issues that arise in considering solutions for the requirements that have been defined for ETS. This section does not specify solutions nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues.
本节介绍了考虑ETS要求解决方案时出现的问题。本节未规定解决方案，也不得与要求混淆。阐明特定服务的更具体需求集的后续文档可能会对以下问题进行说明。
1) Accounting
1) 会计
Accounting represents a method of tracking actual usage of a service. We assume that the usage of any service better than best effort will be tracked and subsequently billed to the user. Accounting is not addressed as a general requirement for ETS. However, solutions used to realize ETS should not preclude an accounting mechanism.
记帐表示跟踪服务实际使用情况的方法。我们假设将跟踪任何优于尽力而为的服务的使用情况，并随后向用户计费。会计不是ETS的一般要求。然而，用于实现ETS的解决方案不应排除会计机制。
2) Admission Control
2) 准入控制
The requirements of section 3 discuss labels and security. Those developing solutions should understand that the ability labels provide to distinguish emergency flows does not create an ability to selectively admit flows. Admission control as it is commonly understood in circuit-switched networks is not present in IP-based networks, and schemes which presume the ability to selectively admit flows when resources are scarce will fail outside of very controlled environments. In cases where emergency related flows occur outside of controlled environments, the development of technologies based on admission control is not recommended as the foundation of emergency services.
第3节的要求讨论了标签和安全性。那些正在开发的解决方案应该理解，标签所提供的区分紧急流量的能力并不能创造选择性接纳流量的能力。在基于IP的网络中不存在通常在电路交换网络中理解的接纳控制，并且假设在资源稀缺时能够选择性地接纳流的方案将在非常受控的环境之外失败。在急诊科相关的外部环境发生的情况下，不推荐基于准入控制的技术开发作为急诊科的基础。
3) Digital Signatures
3) 数字签名
Verification of digital signatures is computationally expensive. If an operator acts upon a label and hence needs to verify the authenticity of the label, then there is a potential denial-of-service attack on the entity performing the authentication. The DoS attack works by flooding the entity performing the
数字签名的验证在计算上非常昂贵。如果操作员对标签进行操作，因此需要验证标签的真实性，则执行身份验证的实体可能会受到拒绝服务攻击。DoS攻击通过淹没执行攻击的实体来工作
authentication with invalid (i.e., not authentic) labelled information, causing the victim to spend excessive amounts of computing resources on signature validation. Even though the invalid information might get discarded after the signature validation fails, the adversary has already forced the victim to expend significant amounts of computing resource. Accordingly, any system requiring such validation SHOULD define operational and protocol measures to reduce the vulnerability to such a DoS attack.
使用无效（即不真实）标签信息进行身份验证，导致受害者在签名验证上花费过多的计算资源。即使在签名验证失败后，无效信息可能会被丢弃，但对手已经迫使受害者花费大量计算资源。因此，任何需要此类验证的系统都应定义操作和协议措施，以降低此类DoS攻击的脆弱性。
RFC 3487 describes requirements for resource priority mechanisms for the Session Initiation Protocol [8]. The requirements specified in that RFC pertain to a specific application level protocol. In contrast, the requirements of this document are a generalization that are not application specific. From this blueprint (acting as a guideline), more specific requirements may be described in future documents.
RFC 3487描述了会话启动协议的资源优先级机制的要求[8]。RFC中规定的要求与特定的应用程序级协议有关。相比之下，本文件的要求是一种概括，不是特定于应用的要求。根据本蓝图（作为指南），未来文件中可能会描述更具体的要求。
Security in terms of requirements is discussed sections 3.1 and 4.
第3.1节和第4节讨论了要求方面的安全性。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] ANSI, "Signaling System No. 7(SS7) "High Probability of Completion (HPC) Network Capability" , ANSI T1.631-1993 (R1999).
[2] ANSI，“第7号信号系统（SS7）“高完工概率（HPC）网络能力”，ANSI T1.631-1993（R1999）。
[3] "Description of an International Emergency Preference Scheme (IEPS)", ITU-T Recommendation E.106 March, 2000.
[3] “国际紧急优惠计划（IEPS）的说明”，ITU-T建议E.106，2000年3月。
[4] "Description for an International Emergency Multimedia Service", ITU Draft Recommendation F.706, February, 2002.
[4] “国际紧急多媒体服务说明”，国际电联建议F.706草案，2002年2月。
[5] "Call Priority Designation for H.323 Calls", ITU Recommendation H.460.4, November, 2002.
[5] “H.323呼叫的呼叫优先级指定”，国际电联建议H.460.42002年11月。
[6] ITU, "Multi-Level Precedence and Preemption Service, ITU, Recommendation, I.255.3, July, 1990.
[6] 国际电联，“多级优先和抢占服务”，国际电联，建议，I.255.3，1990年7月。
[7] U.S. National Communications System: http://www.ncs.gov
[7] U.S. National Communications System: http://www.ncs.gov
[8] Schulzrinne, H., "Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487, February 2003.
[8] Schulzrinne，H.，“会话启动协议（SIP）的资源优先级机制要求”，RFC 3487，2003年2月。
[9] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunications Service", RFC 3690, February 2004.
[9] Carlberg，K.和R.Atkinson，“紧急电信服务的IP电话要求”，RFC 36902004年2月。
[10] Tada, N., et. al., "IAA System (I Am Alive): The Experiences of the Internet Disaster Drills", Proceedings of INET-2000, June.
[10] Tada，N.，等人，“IAA系统（我还活着）：互联网灾难演习的经验”，INET-2000会议记录，6月。
[11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[11] Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
Ken Carlberg University College London Department of Computer Science Gower Street London, WC1E 6BT United Kingdom
肯卡尔堡大学学院伦敦计算机科学系伦敦高尔街，WC1E 6BT英国
EMail: k.carlberg@cs.ucl.ac.uk
EMail: k.carlberg@cs.ucl.ac.uk
Ran Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA 95051 USA
美国加利福尼亚州圣克拉拉门罗街3585号阿特金森极端网络公司，邮编95051
EMail: rja@extremenetworks.com
EMail: rja@extremenetworks.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。