Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 7120 ICANN
BCP: 100 January 2014
Obsoletes: 4020
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 7120 ICANN
BCP: 100 January 2014
Obsoletes: 4020
Category: Best Current Practice
ISSN: 2070-1721
Early IANA Allocation of Standards Track Code Points
IANA标准轨道代码点的早期分配
Abstract
摘要
This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.
本备忘录描述了IANA从“规范要求”、“RFC要求”、“IETF审查”或“标准行动”政策适用的注册中心提前分配代码点的过程。此过程可用于缓解以下问题：在发布RFC（通常会触发代码点分配）之前，需要分配代码点以促进所需或所需的实现和部署经验。本文件中的程序仅适用于IETF流文件。
This document obsoletes RFC 4020.
本文件淘汰了RFC 4020。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7120.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7120.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conditions for Early Allocation . . . . . . . . . . . . . . . . 4
3. Process for Early Allocation . . . . . . . . . . . . . . . . . 4
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Follow-Up . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conditions for Early Allocation . . . . . . . . . . . . . . . . 4
3. Process for Early Allocation . . . . . . . . . . . . . . . . . 4
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Follow-Up . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
In protocol specifications documented in RFCs, there is often a need to allocate code points for various objects, messages, or other protocol entities so that implementations can interoperate. Many of these code point spaces have registries handled by the Internet Assigned Number Authority (IANA). Several IETF policies for IANA allocation of protocol parameters are described in RFC 5226 [RFC5226]. Some of them, such as "First Come First Served" or "Expert Review", do not require a formal IETF action before the IANA performs allocation. However, in situations where code points are a scarce resource and/or the IETF community has consensus to retain tight control of the registry content, policies such as "IETF Review" (formerly "IETF Consensus"), or "Standards Action" have been used. Such allocation policies present a problem in situations where implementation and/or deployment experience are desired or required before the document becomes an RFC.
在RFCs中记录的协议规范中，通常需要为各种对象、消息或其他协议实体分配代码点，以便实现可以互操作。其中许多代码点空间都有由Internet分配号码管理局（IANA）处理的注册表。RFC 5226[RFC5226]中描述了几种IETF协议参数IANA分配策略。其中一些，如“先到先得”或“专家评审”，在IANA执行分配之前不需要正式的IETF行动。然而，在代码点是稀缺资源和/或IETF社区一致同意保留对注册中心内容的严格控制的情况下，使用了诸如“IETF审查”（以前称为“IETF共识”）或“标准行动”等政策。在文档成为RFC之前需要或需要实施和/或部署经验的情况下，此类分配策略会出现问题。
To break the deadlock, document authors often choose some "seemingly unused" code points, often by selecting the next available value from the registry; this is problematic because these may turn out to be different from those later assigned by IANA. To make this problem worse, "pre-RFC" implementations are often developed and deployed based on these code point selections. This creates several potential interoperability problems between early implementations and implementations of the final standard, as described below:
为了打破僵局，文档作者通常选择一些“似乎未使用”的代码点，通常是从注册表中选择下一个可用值；这是有问题的，因为这些结果可能与IANA后来分配的结果不同。更糟糕的是，“预RFC”实现通常是基于这些代码点选择开发和部署的。这在早期实施和最终标准实施之间产生了几个潜在的互操作性问题，如下所述：
1. IANA allocates code points different from those that early implementations assumed would be allocated. Early implementations won't interoperate with standard ones.
1. IANA分配的代码点不同于早期实现假定分配的代码点。早期的实现无法与标准实现进行互操作。
2. IANA allocates code points for one extension while a "pre-RFC" implementation of a different extension chooses the same code point. The different extensions will collide on the same code point in the field.
2. IANA为一个扩展分配代码点，而不同扩展的“pre-RFC”实现选择相同的代码点。不同的扩展将在字段中的同一代码点上发生冲突。
This gets in the way of the main purpose of standards; namely, to facilitate interoperable implementations.
这妨碍了标准的主要目的；即，促进可互操作的实现。
It is easy to say that pre-RFC implementations should be kept private and should not be deployed; however, both the length of the standards process and the immense value of early implementations and early deployments suggest that finding a better solution is worthwhile. As an example, in the case of documents produced by Working Groups in the Routing Area, a pre-RFC implementation is highly desirable and sometimes even required [RFC4794], and early deployments provide useful feedback on the technical and operational quality of the specification.
可以很容易地说，RFC之前的实现应该是私有的，不应该部署；然而，无论是标准过程的长度，还是早期实施和早期部署的巨大价值，都表明寻找更好的解决方案是值得的。例如，对于路由区域的工作组生成的文档，RFC前实施是非常可取的，有时甚至是必需的[RFC4794]，早期部署提供了关于规范的技术和操作质量的有用反馈。
This memo addresses the early allocation of code points so that reservations are made in the IANA registries before the publication of an RFC. The early allocation mechanisms are applied only to spaces whose allocation policy is "Specification Required" (where an RFC is used as the stable reference), "RFC Required", "IETF Review", or "Standards Action". For an explanation of these allocation policies, see [RFC5226].
本备忘录涉及代码点的早期分配，以便在发布RFC之前在IANA注册中心进行预订。早期分配机制仅适用于分配策略为“规范要求”（RFC用作稳定参考）、“RFC要求”、“IETF审查”或“标准行动”的空间。有关这些分配策略的说明，请参阅[RFC5226]。
A policy for IANA early allocations was previously described in [RFC4020]. This document obsoletes RFC 4020 and includes other registration procedures regarding the types of registries that can qualify for early allocation. The procedures in this document are intended to apply only to IETF Stream documents.
IANA早期分配政策在[RFC4020]中已有描述。本文件废除了RFC 4020，并包含了与可提前分配的注册类型相关的其他注册程序。本文件中的程序仅适用于IETF流文件。
The following conditions must hold before a request for early allocation of code points will be considered by IANA:
IANA在考虑提前分配代码点的请求之前，必须满足以下条件：
a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC.
a. 代码点必须来自指定为“RFC要求”、“IETF审查”或“标准行动”的空间。此外，如果规范将作为RFC发布，则允许从“所需规范”注册表中提前分配代码点的请求。
b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft.
b. 互联网草案中必须充分描述与处理由代码点（以下称为“规范”）定义的协议实体相关的格式、语义、处理和其他规则。
c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable.
c. 这些代码点的规格必须稳定；i、 例如，如果有变更，基于早期和后期规范的实现必须是无缝互操作的。
d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field.
d. 工作组主席和区域主管（ADs）判断，社区对早期（RFC前）实施和部署有足够的兴趣，或者未能提前分配可能会导致对现场代码点的争夺。
There are three processes associated with early allocation: making the request for code points; following up on the request; and revoking an early allocation. It cannot be emphasized enough that these processes must have a minimal impact on IANA itself, or they will not be feasible.
有三个与早期分配相关的过程：请求代码点；对请求采取后续行动；取消提前分配。这些过程必须对IANA本身产生最小的影响，这一点再怎么强调也不过分，否则它们就不可行了。
The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding Area Director".
下面描述的过程假设所讨论的文件是IETF工作组（WG）的产品。如果不是这样，请将下面的“工作组主席”替换为“牧羊区主任”。
The process for requesting and obtaining early allocation of code points is as follows:
请求和获得代码点早期分配的过程如下：
1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned.
1. 该文件的作者（编辑）向工作组主席提交了提前分配请求，具体说明哪些代码点需要提前分配，以及应分配给哪些文件。
2. The WG chairs determine whether the conditions for early allocations described in Section 2 are met, particularly conditions (c) and (d).
2. 工作组主席确定是否满足第2节所述的提前分配条件，特别是条件（c）和（d）。
3. The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate for the given document.
3. 工作组主席衡量工作组内部是否一致认为提前分配适用于给定文件。
4. If steps 2) and 3) are satisfied, the WG chairs request approval from the Area Director(s). The Area Director(s) may apply judgement to the request, especially if there is a risk of registry depletion.
4. 如果满足第2）步和第3）步，工作组主席应请求区域总监批准。区域主任可对请求作出判断，尤其是在存在登记册耗尽风险的情况下。
5. If the Area Directors approve step 4), the WG chairs request IANA to make an early allocation.
5. 如果区域主管批准步骤4），工作组主席要求IANA提前进行分配。
6. IANA makes an allocation from the appropriate registry, marking it as "Temporary", valid for a period of one year from the date of allocation. The date of first allocation and the date of expiry are also recorded in the registry and made visible to the public.
6. IANA从适当的登记处进行分配，将其标记为“临时”，自分配之日起一年内有效。首次分配的日期和有效期也会记录在登记处，并向公众公布。
Note that Internet-Drafts should not include a specific value of a code point until IANA has completed the early allocation for this value.
请注意，在IANA完成该值的早期分配之前，Internet草稿不应包含代码点的特定值。
It is the responsibility of the document authors and the Working Group chairs to review changes in the document, and especially in the specifications of the code points for which early allocation was requested, to ensure that the changes are backward compatible.
文件作者和工作组主席有责任审查文件中的更改，特别是要求提前分配的代码点规范中的更改，以确保更改向后兼容。
If at some point changes that are not backward compatible are nonetheless required, a decision needs to be made as to whether previously allocated code points must be deprecated (see Section 3.3 for more information on code point deprecation). The considerations include aspects such as the possibility of existing deployments of the older implementations and, hence, the possibility for a collision between older and newer implementations in the field.
如果在某些情况下仍然需要进行不向后兼容的更改，则需要决定是否必须弃用以前分配的代码点（有关代码点弃用的更多信息，请参阅第3.3节）。考虑因素包括一些方面，例如旧实现的现有部署的可能性，以及因此在现场旧实现和新实现之间发生冲突的可能性。
If the document progresses to the point at which IANA normally makes code point allocations, it is the responsibility of the authors and the WG chairs to remind IANA that there were early allocations and of the code point values allocated in the IANA Considerations section of the RFC-to-be. Allocation is then just a matter of removing the "Temporary" tag from the allocation description.
如果文件进展到IANA通常进行代码点分配的时间点，则作者和工作组主席有责任提醒IANA有早期分配，以及RFC的IANA注意事项部分中分配的代码点值。分配就是从分配描述中删除“临时”标记。
As described in Section 3.1, each temporary assignment is recorded in the registry with the date of expiry of the assignment. If an early allocation expires before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may repeat the process described in Section 3.1 to request renewal of the code points. At most, one renewal request may be made; thus, authors should choose carefully when the original request is to be made.
如第3.1节所述，每份临时转让均记录在登记处，并注明转让到期日。如果在文件进展到IANA通常进行分配之前，提前分配到期，则作者和工作组主席可重复第3.1节中所述的过程，以请求更新代码点。最多可提出一次续展请求；因此，作者应谨慎选择何时提出原始请求。
As an exception to the above rule, under rare circumstances, more than one allocation renewal may be justified. All such further renewal requests must be reviewed by the IESG. The renewal request to the IESG must include the reasons why such further renewal is necessary and the WG's plans regarding the specification.
作为上述规则的一个例外，在极少数情况下，可能有理由延长一次以上的分配。所有此类进一步续约请求必须由IESG审查。向IESG提出的更新请求必须包括需要进一步更新的原因以及工作组关于规范的计划。
If a follow-up request is not made, or the document fails to progress to an RFC, the assignment will remain visible in the registry, but the temporary assignment will be shown to have expired as indicated by the expiry date. The WG chairs are responsible for informing IANA that the expired assignments are not required and that the code points are to be marked "deprecated".
如果未提出跟进请求，或文件未能进展到RFC，则转让将在注册表中保持可见，但临时转让将显示为已到期，如到期日期所示。工作组主席负责通知IANA不需要过期的任务，代码点应标记为“不推荐”。
A deprecated code point is not marked as allocated for use as described in any document (that is, it is not allocated) and is not available for allocation in a future document. The WG chairs may inform IANA that a deprecated code point can be completely de-allocated (i.e., made available for new allocations) at any time after it has been deprecated. Factors influencing this decision will include whether there may be implementations using the previous temporary allocation and the availability of other unallocated code points in the registry.
不推荐使用的代码点未标记为任何文档中描述的已分配使用（即未分配），并且不可在将来的文档中分配。工作组主席可通知IANA，不推荐使用的代码点可在不推荐使用后的任何时间完全取消分配（即可用于新的分配）。影响此决定的因素将包括是否存在使用先前临时分配的实现以及注册表中其他未分配代码点的可用性。
Implementers and deployers need to be aware that deprecation and de-allocation could take place at any time after expiry; therefore, an expired early allocation is best considered as deprecated.
实施者和部署者需要知道，弃用和取消分配可能在到期后的任何时候发生；因此，过期的早期分配最好被视为已弃用。
It is not IANA's responsibility to track the status of allocations, their expirations, or when they may be re-allocated.
IANA不负责跟踪分配的状态、到期时间或重新分配的时间。
Note that if a document is submitted for review to the IESG, and at the time of submission some early allocations are valid (not expired), these allocations must not be considered to have expired while the document is under IESG consideration or is awaiting publication in the RFC Editor's queue after approval by the IESG.
请注意，如果将文件提交给IESG审查，并且在提交时，一些早期分配是有效的（未过期），则在IESG考虑该文件时或在IESG批准后等待在RFC编辑队列中发布时，不得认为这些分配已过期。
This document defines procedures for early allocation of code points in the registries with the "Specification Required", "RFC Required", "IETF Review", and "Standards Action" policies and as such directly affects IANA. This document removes the need for registries to be marked as specifically allowing early allocation. IANA has updated impacted registries by removing any such markings.
本文件规定了注册中心代码点的早期分配程序，包括“规范要求”、“RFC要求”、“IETF审查”和“标准行动”政策，因此直接影响IANA。本文档不再需要将注册表标记为特别允许提前分配。IANA已通过删除任何此类标记来更新受影响的注册。
It is important to keep in mind that denial-of-service attacks on IANA are possible as a result of the processes defined in this memo. There are two that are immediately obvious: depletion of code space by early allocations and process overloading of IANA itself. The processes described here attempt to alleviate both of these potential attacks, but they are subject to scrutiny by IANA to ensure that they work. IANA may at any time request that the IESG suspend the procedures described in this document.
请务必记住，本备忘录中定义的过程可能导致对IANA的拒绝服务攻击。有两个是显而易见的：早期分配导致的代码空间耗尽和IANA本身的进程过载。这里描述的过程试图缓解这两种潜在的攻击，但它们受到IANA的审查，以确保它们有效。IANA可随时要求IESG暂停本文件所述程序。
There is a significant concern that the procedures in this document could be used as an end-run on the IETF process to achieve code point allocation when an RFC will not be published. For example, a WG or a WG chair might be pressured to obtain an early allocation for a protocol extension for a particular company or for another Standards Development Organization even though it might be predicted that an IETF LC or IESG Evaluation would reject the approach that is documented. The requirement for AD consent of early review is an important safeguard, and ADs with any concern are strongly recommended to escalate the issue for IESG-wide discussion.
当RFC不会发布时，本文件中的程序可作为IETF过程的最终运行，以实现代码点分配，这是一个值得关注的问题。例如，工作组或工作组主席可能会受到压力，要求提前为某一特定公司或另一标准开发组织的协议扩展获得分配，即使预计IETF LC或IESG评估会拒绝记录的方法。早期审查的广告同意要求是一项重要的保障措施，强烈建议有任何顾虑的广告将问题升级，供IESG广泛讨论。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020]Kompella，K.和A.Zinin，“早期IANA标准轨道代码点分配”，BCP 100，RFC 4020，2005年2月。
[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, December 2006.
[RFC4794]Fenner，B.，“RFC 1264已过时”，RFC 47942006年12月。
Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their input on RFC 4020. Thank you to Kireeti Kompella and Alex Zinin for authoring RFC 4020. Thank you to Adrian Farrel, Stewart Bryant, Leo Vegoda, John Klensin, Subramanian Moonesamy, Loa Andersson, Tom Petch, Robert Sparks, Eric Rosen, Amanda Baber, and Pearl Liang for their reviews of this document.
非常感谢Bert Wijnen、Adrian Farrel和Bill Fenner对RFC 4020的投入。感谢Kireeti Kompella和Alex Zinin创作RFC 4020。感谢Adrian Farrel、Stewart Bryant、Leo Vegoda、John Klesins、Subramanian Moonesamy、Loa Andersson、Tom Petch、Robert Sparks、Eric Rosen、Amanda Baber和Pearl Liang对本文件的评论。
Author's Address
作者地址
Michelle Cotton Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America
美国加利福尼亚州洛杉矶滨水路12025号300室Michelle Cotton互联网公司，邮编90094-2536
Phone: +1-310-823-5800
EMail: michelle.cotton@icann.org
URI: http://www.icann.org/
Phone: +1-310-823-5800
EMail: michelle.cotton@icann.org
URI: http://www.icann.org/