Network Working Group R. Finlayson
Request for Comments: 2771 LIVE.COM
Category: Informational February 2000
Network Working Group R. Finlayson
Request for Comments: 2771 LIVE.COM
Category: Informational February 2000
An Abstract API for Multicast Address Allocation
一种用于多播地址分配的抽象API
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications.
本文档描述了应用程序看到的动态多播地址分配服务的“抽象服务接口”。虽然它没有描述一个具体的API（即，对于一种特定的编程语言），但它用抽象的术语描述了这个服务的语义，包括它对应用程序的保证。
Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service.
其他文档（不一定是IETF的产品）将描述此服务的具体API。
Applications are the customers of a multicast address allocation service, so a definition of this service should include not only the inter-node network protocols that are used to implement it, but also the 'protocol' that applications use to access the service. While APIs ("application programming interfaces") for specific programming languages (or operating systems) are outside the domain of the IETF, it is appropriate for us to define - in abstract terms - the semantic interface that this service presents to applications. Specific APIs would then be based upon this abstract service interface.
应用程序是多播地址分配服务的客户，因此该服务的定义不仅应包括用于实现该服务的节点间网络协议，还应包括应用程序用于访问该服务的“协议”。虽然特定编程语言（或操作系统）的API（“应用程序编程接口”）不属于IETF的范畴，但我们可以抽象地定义该服务提供给应用程序的语义接口。然后，特定的API将基于此抽象服务接口。
Note that it is possible to implement the multicast address allocation service in at least two different ways. The first (and perhaps most common) way is for end nodes to allocate addresses by communicating with a separate "Address Allocation Server" node, using the "Host to Address Allocation Server" network protocol (MADCAP) [1][7]. Alternatively, an "Address Allocation Server" implementation
注意，可以以至少两种不同的方式实现多播地址分配服务。第一种（可能也是最常见的）方式是，终端节点通过使用“主机到地址分配服务器”网络协议（MADCAP）[1][7]与单独的“地址分配服务器”节点通信来分配地址。或者，“地址分配服务器”实现
might be co-located (along with one or more applications) on an end node, in which case some other, internal, mechanism might be used to access the server. In either case, however, the abstract service interface (and, presumably, any specific APIs) would remain the same.
可能与一个或多个应用程序一起位于终端节点上，在这种情况下，可能会使用其他一些内部机制来访问服务器。然而，在这两种情况下，抽象服务接口（以及可能的任何特定API）都将保持不变。
The remainder of this document describes the abstract interface.
本文档的其余部分描述了抽象接口。
Note that this interface is intended only for the allocation of dynamic multicast addresses, as used by the traditional multicast service model [2]. Future multicast service models might allocate or assign multicast addresses in other ways, but this is outside the scope of this document.
请注意，此接口仅用于分配动态多播地址，如传统多播服务模型[2]所使用的那样。未来的多播服务模型可能会以其他方式分配或分配多播地址，但这超出了本文的范围。
The interface described below uses the following abstract data types:
下面描述的接口使用以下抽象数据类型：
- AddressFamily: e.g., IPv4 or IPv6
- AddressFamily：例如IPv4或IPv6
- MulticastAddress: An actual multicast address (i.e., that could subsequently be used as the destination of a datagram)
- MulticastAddress：实际的多播地址（即，可随后用作数据报的目的地）
- MulticastAddressSet: A set of "MulticastAddress"es
- MulticastAddressSet：一组“MulticastAddress”元素
- LanguageTag: The code for a (human) language, as defined in [4]
- LanguageTag：在[4]中定义的（人类）语言的代码
- Scope: An "administrative scope" [3] from which multicast addresses are to be allocated. Each scope is a "MulticastAddressSet", with an associated set of (character-string) names - indexed by "LanguageTag". (Each language tag has at most one corresponding name, per scope.) For each scope, a (language tag, name) pair may be defined to be the 'default' name for this scope. (See the section "Querying the name of a scope" below.)
- 作用域：从中分配多播地址的“管理作用域”[3]。每个作用域都是一个“MulticastAddressSet”，具有一组关联的（字符串）名称，由“LanguageTag”索引。（每个语言标记每个作用域最多有一个对应的名称。）对于每个作用域，可以将（语言标记，名称）对定义为该作用域的“默认”名称。（请参阅下面的“查询作用域名称”一节。）
(An implementation of this abstract data type might also include other information, such as a default TTL for the scope.)
（此抽象数据类型的实现还可能包括其他信息，例如作用域的默认TTL。）
- Time: An (absolute) event time. This is used for specifying the "lifetime" of multicast addresses: the period of time during which allocated multicast addresses are guaranteed to be available. (It is also used to specify the desired start time for an "advance allocation".)
- 时间：一个（绝对）事件时间。这用于指定多播地址的“生存期”：保证分配的多播地址可用的时间段。（它还用于指定“提前分配”的所需开始时间。）
Note that a concrete API might prefer to specify some of these times as relative times (i.e., relative to the current time-of-day), rather than absolute time. (Relative times have the advantage of not requiring clock synchronization.)
请注意，具体的API可能更愿意将其中一些时间指定为相对时间（即相对于一天中的当前时间），而不是绝对时间。（相对时间的优点是不需要时钟同步。）
- Lease: A compound data type that describes the result of a (successful) multicast address allocation. It consists of:
- Lease：描述（成功）多播地址分配结果的复合数据类型。它包括：
- [MulticastAddressSet] The set of addresses that were allocated;
- [MulticastAddressSet]分配的地址集；
- [AddressFamily] The address family of these addresses
- [AddressFamily]这些地址的地址系列
- [Time] The lifetime of these addresses (the same for each address)
- [时间]这些地址的生存期（每个地址相同）
- [Time] The "start time" of the allocation. (See the discussion of "advance allocation" below.) (A concrete API would likely also include a MADCAP "Lease Identifier" [1].)
- [时间]分配的“开始时间”。（见下文“提前分配”的讨论。）（具体的API可能还包括一个MADCAP“租赁标识符”[1]。）
- NestingRelationship: A binary data type that describes whether or not two scopes nest. Two scopes nest if traffic sent sent to a multicast group within one scope could be seen by all hosts present within the other scope were they to join the multicast group within the first scope. This value would be "False" for overlapping scopes where only some (or none) of the hosts within the second scope could see traffic sent to an address due to the presence of an administratively scoped boundary. In cases where the first and second scopes are topologically identical this value would be "True."
- NestingRelationship：描述两个作用域是否嵌套的二进制数据类型。如果发送到一个作用域内的多播组的流量可以被另一个作用域内的所有主机看到，则两个作用域嵌套，前提是它们要加入第一个作用域内的多播组。对于重叠作用域，此值为“False”，因为存在管理作用域边界，第二个作用域中只有一些（或没有）主机可以看到发送到地址的流量。在第一个作用域和第二个作用域拓扑相同的情况下，此值为“True”
- Status: A result code.
- 状态：结果代码。
3.1 Allocating multicast addresses:
3.1 分配多播地址：
alloc_multicast_addr(in AddressFamily family, in Scope scope, in Integer minDesiredAddresses, in Integer maxDesiredAddresses, in Time minDesiredStartTime, in Time maxDesiredStartTime, in Time minDesiredLifetime, in Time maxDesiredLifetime, out Lease multicastAddressSetLease, out Status status)
alloc_multicast_addr（地址族内、作用域内、整数minDesiredAddresses内、整数maxDesiredAddresses内、时间minDesiredStartTime内、时间maxDesiredStartTime内、时间minDesiredLifetime内、时间maxDesiredLifetime内、出租约multicastAddressSetLease外状态）
This operation attempts to allocate a set of multicast addresses (the size of this set is in the range [minDesiredAddresses, maxDesiredAddresses]) within the given address family and scope, and within a given range of desired lifetimes. ("minDesiredStartTime" and "maxDesiredStartTime" are used to specify "advance allocation"; this is described in more detail below.)
此操作尝试在给定的地址系列和范围内，以及在给定的所需生存期范围内分配一组多播地址（该组地址的大小在[minDesiredAddresses，maxDesiredAddresses]范围内）。（“minDesiredStartTime”和“maxDesiredStartTime”用于指定“提前分配”；下面将对此进行更详细的描述。）
If the address allocation succeeds, the result is returned in "multicastAddressSetLease" (with "status" = OK).
如果地址分配成功，结果将在“multicastAddressSetLease”中返回（“status”=OK）。
During the lifetime of this lease, the allocation service will make a "best-effort" attempt to not allocate any of these addresses to others. (However, once the lease's lifetime has expired, any of its addresses can be allocated to others.)
在此租约有效期内，分配服务将尽最大努力不将这些地址分配给其他地址。（但是，一旦租约的有效期到期，其任何地址都可以分配给其他地址。）
Multicast addresses are allocated for a limited lifetime. An application may attempt to extend this lifetime, but this operation may fail. Therefore, an application must be prepared for the possibility it will not be able to use the same addresses for as long as it desires. In particular, the application must be prepared to either quit early (because its original multicast address assignments have expired), or, alternatively, to occasionally 'renumber' its multicast addresses (in some application or higher-level-protocol dependent way), by making a new allocation. However, if an application needs to consider 'renumbering', it will always know this in advance, at the time it acquired its current address(es) - by checking the lifetime in the returned lease. An application will never need to be notified asynchronously of the need to 'renumber'.
在有限的生存期内分配多播地址。应用程序可能会尝试延长此生存期，但此操作可能会失败。因此，必须准备好应用程序，以防其无法在所需的时间内使用相同的地址。特别是，应用程序必须准备提前退出（因为其原始多播地址分配已过期），或者，通过进行新的分配，偶尔“重新编号”其多播地址（在某些应用程序或更高级别的协议相关方式中）。但是，如果一个应用程序需要考虑“重新编号”，它将总是事先知道它，在它获取当前地址（ES）的时候——通过检查返回的租约中的生存期。应用程序永远不需要异步通知需要“重新编号”。
Possible errors:
可能的错误：
- bad address family - bad scope - bad desired number of addresses (e.g., max < min) - bad desired lifetimes (e.g., max < min) - errors with the two "start time" parameters (see "Advance allocation" below) - no addresses can be allocated (for the requested parameters)
- 错误的地址系列-错误的范围-错误的期望地址数（例如，最大<最小）-错误的期望寿命（例如，最大<最小）-两个“开始时间”参数错误（请参阅下面的“提前分配”）-无法分配地址（对于请求的参数）
An allocation attempt can also fail with a result "status" code of TRY_LATER, indicating that the requested allocation cannot be made at this time, but that it might succeed if the caller retries the attempt at some future time. (This future time is returned in the "start time" field of the
分配尝试也可能失败，结果“status”代码为TRY_LATER，表示此时无法进行请求的分配，但如果调用方在将来某个时间重试该尝试，则分配可能会成功。（此未来时间将在
"multicastAddressSetLease"; the other parts of this lease are undefined.)
“multicastAddressSetLease”；本租约的其他部分未定义。）
Note that a concrete (i.e., programming language-specific) API for multicast address allocation will probably include additional, specialized variants of this general allocation operation. For instance, it may include separate operations for:
请注意，用于多播地址分配的具体（即，特定于编程语言的）API可能会包括此一般分配操作的其他专用变体。例如，它可能包括以下各项的单独操作：
- allocating only a single address (i.e., minDesiredAddresses = maxDesiredAddresses = 1); - (attempting to) allocate an address with a single, fixed lifetime (i.e., minDesiredLifetime = maxDesiredLifetime); - (attempting to) allocate an address for immediate use (i.e., minDesiredStartTime = maxDesiredStartTime = 'now')
- 仅分配一个地址（即minDesiredAddresses=maxDesiredAddresses=1）；-（试图）分配具有单一固定生存期的地址（即minDesiredLifetime=maxDesiredLifetime）；-（试图）分配一个地址以供立即使用（即minDesiredStartTime=maxDesiredStartTime='now'）
3.2 Changing multicast addresses' lifetime:
3.2 更改多播地址的生存期：
change_multicast_addr_lifetime(in Lease multicastAddressSetLease, in Time minDesiredLifetime, in Time maxDesiredLifetime, out Time lifetime)
更改\u多播\u地址\u生存期（租约内多播地址集租约、时间内minDesiredLifetime、时间内maxDesiredLifetime、时间外生存期）
This operation attempts to change the lifetime of previously allocated multicast addresses. Unless an error occurs, it returns the new lifetime (which might remain unchanged).
此操作尝试更改以前分配的多播地址的生存期。除非发生错误，否则它将返回新的生存期（可能保持不变）。
Possible errors:
可能的错误：
- bad address family - bad durations (e.g., max < min)
- 错误地址系列-错误持续时间（例如，最大值<最小值）
- the addresses' lifetime could not be changed (and the existing lifetime was not in the requested range [minDesiredLifetime,maxDesiredLifetime]) - the addresses were not ones that we had allocated (see section 5.9) - or they have already expired
- 无法更改地址的生存期（并且现有生存期不在请求的范围[minDesiredLifetime，maxDesiredLifetime]）-地址不是我们分配的地址（请参阅第5.9节）-或者它们已经过期
3.3 Deallocating multicast addresses:
3.3 取消分配多播地址：
deallocate_multicast_addr(in Lease multicastAddressSetLease) This operation attempts to deallocate previously allocated multicast addresses.
解除分配\多播\地址（in-Lease multicastAddressSetLease）此操作尝试解除分配以前分配的多播地址。
Possible errors:
可能的错误：
- bad address family - the addresses were not ones that we had allocated (or they have already expired)
- 地址系列错误-地址不是我们分配的（或已过期）
3.4 Querying the set of usable multicast address scopes:
3.4 查询可用多播地址范围集：
get_multicast_addr_scopes(in AddressFamily family, out "set of" Scope)
获取\u多播\u地址\u作用域（在AddressFamily家族中，在“集合”作用域之外）
This operation returns the set of administrative multicast address scopes that are defined for this node.
此操作返回为此节点定义的管理多播地址范围集。
Possible errors:
可能的错误：
- bad address family
- 地址不正确的家庭
3.5 Querying the name of a scope:
3.5 查询作用域的名称：
get_scope_name(in Scope scope, in LanguageTag language, out String name, out LanguageTag languageForName)
获取\u范围\u名称（范围内、语言内标记语言、输出字符串名称、输出语言标记语言FORNAME）
This operation returns a character-string name for a given scope. If the scope has a name in the specified "language", then this name (and language) is returned. Otherwise, the scope's default (language, name) pair is returned.
此操作返回给定范围的字符串名称。如果作用域具有指定“语言”的名称，则返回该名称（和语言）。否则，将返回作用域的默认（语言、名称）对。
Possible errors:
可能的错误：
- bad scope.
- 坏范围。
3.6 Querying the nesting state of known usable multicast address scopes:
3.6 查询已知可用多播地址作用域的嵌套状态：
get_scope_nesting_state(in "set of" Scope, out "matrix of" NestingRelationship)
获取\u范围\u嵌套\u状态（在“范围集合”中，在“嵌套关系”的“矩阵”中）
Possible errors:
可能的错误：
- bad scope. - nesting state undetermined at this time.
- 坏范围此时未确定嵌套状态。
This operation would return a matrix that shows the current nesting relationships between the supplied set of scopes which would have previously been supplied via the get_multicast_addr_scopes(...) function.
此操作将返回一个矩阵，该矩阵显示所提供的一组作用域之间的当前嵌套关系，这些作用域以前是通过get_multicast_addr_scopes（…）函数提供的。
3.7 Querying the set of scopes that a given scope is known to nest inside:
3.7 查询已知给定作用域嵌套在其中的作用域集：
get_larger_scopes(in Scope, out "set of" Scope)
获取更大的范围（范围内，范围外）
This operation returns the set of administrative multicast address scopes that are known to encompass the supplied Scope.
此操作返回一组已知包含所提供作用域的管理多播地址作用域。
Possible errors:
可能的错误：
- bad scope. - nesting state undetermined at this time.
- 坏范围此时未确定嵌套状态。
3.8 Querying the set of scopes that are known to nest inside a given scope:
3.8 查询已知嵌套在给定范围内的范围集：
get_smaller_scopes(in Scope, out "set of" Scope)
获取较小的范围（范围内，范围外）
This operation returns the set of administrative multicast address scopes that are known to nest inside the supplied Scope (NB this would include those scopes that are topologically identical to the supplied scope).
此操作返回一组已知嵌套在提供的作用域内的管理多播地址作用域（注意，这将包括那些在拓扑上与提供的作用域相同的作用域）。
Possible errors:
可能的错误：
- bad scope. - nesting state undetermined at this time.
- 坏范围此时未确定嵌套状态。
3.9 Note: The decision as to who is allowed to deallocate (or change the lifetime of) a previously allocated multicast address set lease is implementation-specific, and depends upon the security policy of the host system. Thus it is not specified in this abstract API. One possible starting point, however, is the following:
3.9 注意：关于允许谁解除分配（或更改）先前分配的多播地址集租约的生存期的决定是特定于实现的，并且取决于主机系统的安全策略。因此，在这个抽象API中没有指定它。然而，一个可能的起点是：
A previously allocated multicast address can be deallocated (or have its lifetime queried or changed) by the same "principal", and on the same node, as that which originally allocated it. ("principal" might, for example, be a "user" in the host operating system.)
先前分配的多播地址可以由相同的“主体”在相同的节点上解除分配（或查询或更改其生存期），与最初分配它的地址相同。（“主体”例如可能是主机操作系统中的“用户”。）
By specifying "minDesiredStartTime = maxDesiredStartTime = 'now'", the address allocation operation - "alloc_multicast_addr" - described above can be used to request a set of multicast addresses that can be used *immediately* (and until their lifetime expires). During this whole time, the addresses are not available for allocation to others.
通过指定“minDesiredStartTime=maxDesiredStartTime=‘now’”，上述地址分配操作——“alloc_multicast_addr”——可用于请求一组可立即使用的多播地址（直到其生存期到期）。在这段时间内，地址无法分配给其他人。
It is also possible - using the "minDesiredStartTime" and "maxDesiredStartTime" parameters - to allocate multicast addresses *in advance* - i.e., so that they have a future "start time" as well as an expiration time. Before the start time, the multicast addresses may be allocated to others.
也可以使用“minDesiredStartTime”和“maxDesiredStartTime”参数预先分配多播地址*——即，使它们具有未来的“开始时间”和到期时间。在开始时间之前，可以将多播地址分配给其他多播地址。
Advance allocation is convenient for allocating addresses for events that begin far in the future - e.g., several weeks or months away. Without advance allocation, it would be necessary to allocate addresses for a long period of time - even when it will not be used. Such a request would not only be a wasteful use of the multicast address space, but it may also be difficult to implement (especially since address allocations are expected to remain valid in spite of topology changes).
提前分配便于为遥远的将来开始的事件（例如，几周或几个月之后）分配地址。如果没有预先分配，就必须在很长一段时间内分配地址，即使它不会被使用。这样的请求不仅浪费了多播地址空间，而且可能很难实现（特别是因为尽管拓扑发生了变化，地址分配仍将保持有效）。
Advance allocation requests can produce the following errors (in addition to those defined earlier):
提前分配请求可能会产生以下错误（除先前定义的错误外）：
- bad start time durations (e.g., max < min) - requested start times conflict with requested lifetimes (i.e., min start time > max lifetime)
- 错误的启动时间持续时间（例如，最大<最小）-请求的启动时间与请求的生存时间冲突（即，最小启动时间>最大生存时间）
The following operation is also defined:
还定义了以下操作：
change_multicast_addr_start_time(in Lease multicastAddressSetLease, in Time minDesiredStartTime, in Time maxDesiredStartTime, out Time startTime)
更改\u多播\u地址\u开始\u时间（租入多播地址集租入时间minDesiredStartTime、租入时间maxDesiredStartTime、租出时间startTime）
This operation attempts to change the start time of previously allocated multicast addresses. Unless an error occurs, it returns the new start time (which might remain unchanged).
此操作尝试更改以前分配的多播地址的开始时间。除非发生错误，否则它将返回新的开始时间（可能保持不变）。
Possible errors: the same as "change_multicast_addr_lifetime"
可能的错误：与“更改\u多播\u地址\u生存期”相同
As noted in section 5.9 above, each implementation of this abstract API should define a security policy that specifies when (and by whom) previously allocated multicast addresses can be deallocated (or queried, or have their lifetime changed).
如上文第5.9节所述，此抽象API的每个实现都应该定义一个安全策略，指定何时（以及由谁）可以解除分配（或查询，或更改其生存期）。
Because multicast addresses are a finite resource, there is a potential for a "denial of service" attack by allocating a large number of multicast addresses without deallocating them. Preventing such an attack, however, is not the role of the API, but rather by the underlying MAAS ("Multicast Address Allocation Server(s)" [6]).
由于多播地址是一种有限资源，因此通过分配大量多播地址而不取消分配地址，可能会发生“拒绝服务”攻击。但是，防止此类攻击不是API的作用，而是由底层MAA（“多播地址分配服务器”[6]）来实现。
Many thanks to other participants in the "MALLOC" working group - in particular Steve Hanna, Dave Thaler, Roger Kermode, and Pavlin Radoslavov - for their valuable comments.
非常感谢“MALLOC”工作组的其他参与者——特别是史蒂夫·汉纳、戴夫·泰勒、罗杰·克莫德和帕夫林·拉多斯拉沃夫——提出了宝贵的意见。
[1] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.
[1] Hanna，S.，Patel，B.和M.Shah，“多播地址动态客户端分配协议（MADCAP）”，RFC2730，1999年12月。
[2] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[2] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[3] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July, 1998.
[3] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[4] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[4] Alvestrand，H.，“语言识别标签”，RFC1766，1995年3月。
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[5] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[6] Estrin, D., Handley, M. and D. Thaler, "The Internet Multicast Address Allocation Architecture", Work in Progress.
[6] Estrin，D.，Handley，M.和D.Thaler，“互联网多播地址分配架构”，正在进行中。
[7] Kermode, R., "MADCAP Multicast Scope Nesting State Option", Work in Progress.
[7] Kermode，R.，“MADCAP多播作用域嵌套状态选项”，正在进行中。
Ross Finlayson, Live Networks, Inc. (LIVE.COM)
罗斯·芬莱森，直播网络公司（Live.COM）
EMail: finlayson@live.com
WWW: http://www.live.com/
EMail: finlayson@live.com
WWW: http://www.live.com/
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。