Network Working Group K. Kompella
Request for Comments: 4020 Juniper Networks
BCP: 100 A. Zinin
Category: Best Current Practice Alcatel
February 2005
Network Working Group K. Kompella
Request for Comments: 4020 Juniper Networks
BCP: 100 A. Zinin
Category: Best Current Practice Alcatel
February 2005
Early IANA Allocation of Standards Track Code Points
IANA标准轨道代码点的早期分配
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication.
本备忘录讨论了IANA先前分配的代码点，作为对“标准行动”IANA政策产生的问题的一种补救措施，该政策针对IETF流程要求或要求在发布之前具有实施和部署经验的协议。
In Standards Track 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 IANA allocation policies are described in RFC 2434 [2434]. 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 is willing to retain tight control of the protocol, policies such as IESG Approval, IETF Consensus, or Standards Action have been used. The Standards Action policy represents a problem in situations where implementation and/or deployment experience are desired or required for the Standards Action.
在标准跟踪RFC中，通常需要为各种对象、消息或其他协议实体分配代码点，以便实现可以互操作。其中许多代码点空间都有由Internet分配号码管理局（IANA）处理的注册表。RFC 2434[2434]中描述了几种IANA分配策略。其中一些，如先到先得或专家评审，在IANA执行分配之前不需要正式的IETF行动。然而，在代码点是稀缺资源和/或IETF社区愿意保持对协议的严格控制的情况下，使用了IESG批准、IETF共识或标准行动等政策。在需要或需要标准行动的实施和/或部署经验的情况下，标准行动政策是一个问题。
To break the deadlock, "pre-RFC" implementations have sometimes simply chosen some "seemingly unused" code points; these may turn out to be different from those later assigned by IANA. To make matters worse, these "pre-RFC" implementations are often deployed. This creates several potential interoperability problems between early
为了打破僵局，“预RFC”实现有时只是选择一些“似乎未使用”的代码点；这些结果可能与IANA后来分配的结果不同。更糟糕的是，这些“预RFC”实现经常被部署。这会在早期版本之间产生几个潜在的互操作性问题
implementations and implementations of the final standard, as described below:
最终标准的实施和实施，如下所述：
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 used silently for other extensions. Different extensions will collide.
2. IANA为其他扩展分配静默使用的代码点。不同的扩展将发生冲突。
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 finding a better solution. 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, and early deployments provide useful feedback on the technical and operational quality of the specification.
可以很容易地说，RFC之前的实现应该是私有的，不应该部署；然而，无论是标准过程的长度，还是早期实施和早期部署的巨大价值，都表明要找到更好的解决方案。例如，对于路由区域工作组生成的文件，RFC前实施是非常可取的，有时甚至是必需的，早期部署提供了关于规范技术和操作质量的有用反馈。
This memo proposes that, under strictly controlled circumstances, IANA make an early allocation of code points. The memo lays out the conditions for early allocation, as well as the process to be followed; it also says how these allocations are dealt with in the event of a failure in the process (such as the RFC not being published).
该备忘录建议，在严格控制的情况下，IANA应尽早分配代码点。备忘录列出了提前分配的条件以及应遵循的流程；它还说明了在流程出现故障（如RFC未发布）时如何处理这些分配。
This memo only addresses the early allocation of code points from spaces whose allocation policy is "Standards Action" [2434] AND that have been amended to permit early allocation. This permission must be granted by the IESG, and code spaces with permission for early allocation must be marked as such in the IANA registry.
本备忘录仅针对分配策略为“标准行动”[2434]且已修改为允许提前分配的空间的代码点的提前分配。此权限必须由IESG授予，具有提前分配权限的代码空间必须在IANA注册表中标记为这样。
The following conditions must hold before a request may be made for early allocation of code points:
在请求提前分配代码点之前，必须满足以下条件：
a) The code points must be from a space designated as "Standards Action", amended by IESG approval to permit Early Allocation.
a) 代码点必须来自指定为“标准行动”的空间，经IESG批准进行修改，以允许提前分配。
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 that is proposed as Standards Track.
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) There is sufficient interest in early (pre-RFC) implementation and deployment in the community.
d) 社区对早期（RFC前）实施和部署有足够的兴趣。
If conditions (a) or (b) are not met, then the processes in this memo do not apply.
如果不满足条件（a）或（b），则本备忘录中的流程不适用。
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. If this is not the case, replace "WG chairs" below with "shepherding Area Director".
下面描述的过程假设所讨论的文件是IETF工作组的产品。如果不是这样，请将下面的“工作组主席”替换为“牧羊区主任”。
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 which document they should be assigned to.
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 in the case of the given document.
3) 工作组主席衡量工作组内部是否达成共识，即在给定文件的情况下，提前分配是适当的。
4) If it is, with the approval of the Area Director(s), the WG chairs request IANA to make an early allocation.
4) 如果是，经区域总监批准，工作组主席要求IANA提前分配。
5) 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 allocation should also be recorded in the registry and made visible to the public.
5) IANA从适当的登记处进行分配，将其标记为“临时”，自分配之日起一年内有效。分配日期也应记录在登记处，并向公众公布。
Note that Internet Drafts should not include a specific value of a code point until this value has been formally allocated by IANA.
请注意，在IANA正式分配代码点的特定值之前，互联网草案不应包括该值。
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 so 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注意事项部分中有早期分配，以及分配的代码点值。分配就是从分配描述中删除“临时”标记。
If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may follow an abbreviated version of the process 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.
如果早期分配在文件进展到IANA通常进行分配之前到期，则作者和工作组主席可遵循第3.1节中流程的简化版本，请求更新代码点。最多可提出一次续展请求；因此，作者应谨慎选择何时提出原始请求。
As an exception to the above rule, under rare circumstances, more than one allocation renewal may be justified. All such renewal requests must be reviewed by the IESG. The renewal request to the IESG must include the reasons why such 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 a Standards Track RFC, the WG chairs are responsible for informing IANA that the code points are to be marked "deprecated" (and are not to be allocated). The WG chairs are further responsible for informing IANA when the deprecated code points can be completely de-allocated (i.e., made available for new allocations).
如果未提出后续请求，或文件未能进展到标准跟踪RFC，工作组主席负责通知IANA代码点标记为“不推荐”（且不分配）。工作组主席还负责通知IANA何时可以完全取消分配不推荐的代码点（即可用于新的分配）。
In particular, it is not IANA's responsibility to track the status of allocations, their expiration, 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 should not be expired while the document is under IESG consideration or waiting 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 Standards Action policy and as such directly affects IANA functions.
本文件根据标准行动政策规定了登记册中代码点的早期分配程序，因此直接影响IANA功能。
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
It is important to keep in mind 'denial of service' attacks on IANA as a result of the processes 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, but they should be subject to scrutiny to ensure this.
请务必记住，由于本备忘录中的流程，IANA受到“拒绝服务”攻击。有两个是显而易见的：早期分配导致的代码空间耗尽和IANA本身的进程过载。这里描述的过程试图缓解这两个问题，但它们应该经过仔细检查以确保这一点。
Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their input.
非常感谢Bert Wijnen、Adrian Farrel和Bill Fenner的投入。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
加利福尼亚州米德尔菲尔德东路山景城701号亚历克斯·齐宁阿尔卡特，邮编94043
EMail: zinin@psg.com
EMail: zinin@psg.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。