Network Working Group S. Bradner
Request for Comments: 4775 Harvard
BCP: 125 B. Carpenter, Ed.
Category: Best Current Practice T. Narten
IBM
December 2006
Network Working Group S. Bradner
Request for Comments: 4775 Harvard
BCP: 125 B. Carpenter, Ed.
Category: Best Current Practice T. Narten
IBM
December 2006
Procedures for Protocol Extensions and Variations
协议扩展和变更程序
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document discusses procedural issues related to the extensibility of IETF protocols, including when it is reasonable to extend IETF protocols with little or no review, and when extensions or variations need to be reviewed by the IETF community. Experience has shown that extension of protocols without early IETF review can carry risk. The document also recommends that major extensions to or variations of IETF protocols only take place through normal IETF processes or in coordination with the IETF.
本文件讨论了与IETF协议可扩展性相关的程序性问题，包括何时扩展IETF协议而很少审查或不审查是合理的，何时扩展或变更需要IETF社区审查。经验表明，在没有早期IETF审查的情况下扩展协议可能会带来风险。该文件还建议，IETF协议的主要扩展或变化只能通过正常的IETF过程或与IETF协调进行。
This document is directed principally at other Standards Development Organizations (SDOs) and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes.
本文件主要针对考虑IETF协议扩展要求的其他标准开发组织（SDO）和供应商。它不修改正式的IETF过程。
Table of Contents
目录
1. Introduction ....................................................2
2. Technical Risks in Extensions ...................................3
3. General Considerations ..........................................4
3.1. The Importance of Interoperability .........................4
3.2. Registered Values and the Importance of IANA Assignments ...5
3.3. Significant Extensions Require Technical Review ............5
3.4. Quality and Consistency ....................................6
3.5. The Role of Formal Liaisons ................................6
4. Procedure for Review of Extensions ..............................7
5. Some Specific Issues ...........................................10
6. Intellectual Property ..........................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. Introduction ....................................................2
2. Technical Risks in Extensions ...................................3
3. General Considerations ..........................................4
3.1. The Importance of Interoperability .........................4
3.2. Registered Values and the Importance of IANA Assignments ...5
3.3. Significant Extensions Require Technical Review ............5
3.4. Quality and Consistency ....................................6
3.5. The Role of Formal Liaisons ................................6
4. Procedure for Review of Extensions ..............................7
5. Some Specific Issues ...........................................10
6. Intellectual Property ..........................................10
7. Security Considerations ........................................10
8. IANA Considerations ............................................11
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
BCP 9 [RFC2026] is the current definition of the IETF standards track. This process applies not only to the initial definition of a protocol, but also to any subsequent updates, such that continued interoperability can be guaranteed. However, it is not always clear whether extensions to a protocol should be made within the IETF process, especially when they originate outside the IETF community. This document lays down guidelines and procedures for such extensions.
BCP 9[RFC2026]是IETF标准轨道的当前定义。该过程不仅适用于协议的初始定义，还适用于任何后续更新，以确保持续的互操作性。然而，协议的扩展是否应该在IETF过程中进行并不总是明确的，特别是当它们起源于IETF社区之外时。本文件规定了此类扩展的指南和程序。
When developing protocols, IETF Working Groups (WGs) typically include mechanisms whereby these protocols can be extended in the future. It is, of course, a good principle to design extensibility into protocols; a common definition of a successful protocol is one that becomes widely used in ways not originally anticipated. Well-designed extensibility mechanisms facilitate the evolution of protocols and help make it easier to roll out incremental changes in an interoperable fashion. At the same time, experience has shown that extensibility features should be limited to what is clearly necessary when the protocol is developed, and any later extensions should be done carefully and with a full understanding of the base protocol, existing implementations, and current operational practice. However, it is not the purpose of this document to describe the architectural principles of sound extensibility design.
在开发协议时，IETF工作组（WG）通常包括将来可以扩展这些协议的机制。当然，将可扩展性设计成协议是一个很好的原则；成功协议的一个常见定义是以最初未预期的方式广泛使用的协议。设计良好的可扩展性机制有助于协议的发展，并有助于以可互操作的方式更轻松地推出增量更改。同时，经验表明，可扩展性特性应限于开发协议时明确需要的功能，任何后续扩展都应仔细进行，并充分了解基本协议、现有实现和当前操作实践。然而，本文档的目的不是描述声音可扩展性设计的架构原则。
When extensions to IETF protocols are made within the IETF, the normal IETF process is followed, including the normal processes for IETF-wide review and IESG approval. Extensions developed in this way should respect the same architectural principles and technical criteria as any other IETF work.
在IETF内对IETF协议进行扩展时，遵循正常的IETF流程，包括IETF范围内的审查和IESG批准的正常流程。以这种方式开发的扩展应遵守与任何其他IETF工作相同的体系结构原则和技术标准。
In addition to the IETF itself, other Standards Development Organizations (SDOs), vendors, and technology fora may identify a requirement for an extension to an IETF protocol. The question addressed by this document is how such bodies should proceed. There are several possible scenarios:
除了IETF本身之外，其他标准开发组织（SDO）、供应商和技术论坛也可以确定IETF协议扩展的需求。本文件所涉及的问题是这些机构应如何开展工作。有几种可能的情况：
1. The requirement is straightforward and within the scope of whatever extension mechanism the base protocol includes.
1. 这个要求很简单，并且在基本协议包括的任何扩展机制的范围内。
2. The requirement is, or may be, outside that scope, and: 1. The IETF still has an active WG in the area; 2. The IETF has no active WG, but has relevant expertise; 3. The IETF no longer has a nucleus of relevant expertise.
2. 要求在或可能在该范围之外，并且：1。IETF在该地区仍有一个活跃的工作组；2.IETF没有活跃的工作组，但具有相关专业知识；3.IETF不再拥有相关专业知识的核心。
Especially in the latter three cases, there are technical risks in extension design, described in the next section. These risks are higher when extensions to IETF protocols are made outside the IETF and without consulting the IETF.
特别是在后三种情况下，扩展设计中存在技术风险，将在下一节中介绍。当IETF协议的扩展在IETF之外进行且未咨询IETF时，这些风险更高。
This document is focused on appropriate procedures and practices to minimize the chance that extensions developed outside the IETF will encounter these risks and, therefore, become useless or, worse, damaging to interoperability. Architectural considerations are documented elsewhere. This document is directed principally at other SDOs and vendors considering requirements for extensions to IETF protocols. It does not modify formal IETF processes.
本文档重点介绍适当的程序和实践，以最大限度地减少在IETF之外开发的扩展遇到这些风险的可能性，从而使其变得无用，或者更糟，破坏互操作性。其他地方记录了架构方面的考虑。本文件主要针对考虑IETF协议扩展要求的其他SDO和供应商。它不修改正式的IETF过程。
The IETF claims no special position. Everything said here about IETF protocols would apply with equal force to protocols specified by any SDO. The IETF should follow whatever procedures another SDO lays down for extensions to its own protocols, if the IETF identifies a need for such an extension.
IETF没有要求特殊职位。这里所说的关于IETF协议的所有内容都将同样适用于任何SDO指定的协议。如果IETF确定需要扩展，则IETF应遵循其他SDO为扩展其自身协议制定的任何程序。
Extensions may be developed without full understanding of why the existing protocol was designed the way that it is -- e.g., what ideas were brought up during the original development and rejected because of some problem with them. Also, extensions could unintentionally negate some key function of the existing protocol (such as security or congestion control). Design choices can be made without analyzing their impact on the protocol as a whole, and basic underlying
在开发扩展时，可能没有充分理解现有协议为何按原样设计——例如，在最初的开发过程中提出了哪些想法，但由于存在一些问题而被拒绝。此外，扩展可能会无意中否定现有协议的某些关键功能（如安全或拥塞控制）。可以在不分析其对整个协议和基础协议的影响的情况下进行设计选择
architectural principles of the protocol can be violated. Also, there is a risk that mutually incompatible extensions may be developed independently.
可能违反协议的体系结构原则。此外，还存在相互不兼容的扩展可能独立开发的风险。
Of course, the IETF itself is not immune to such mistakes, suggesting a need for WGs to document their design decisions (including paths rejected) and some rationale for those decisions, for the benefit of both those within the IETF and those outside the IETF, perhaps years later.
当然，IETF本身也无法避免此类错误，这表明工作组需要记录其设计决策（包括被拒绝的路径）以及这些决策的一些基本原理，以利于IETF内部和IETF外部的人员，也许几年后。
Documentation of non-IETF extensions can sometimes be hard to obtain, so assessing the quality of the specification, verifying interoperability, and verifying compatibility with other extensions (including past and future extensions) can be hard or impossible.
非IETF扩展的文档有时很难获得，因此评估规范的质量、验证互操作性以及验证与其他扩展（包括过去和未来的扩展）的兼容性可能很难或不可能。
A set of interrelated extensions to multiple protocols typically carries a greater danger of interoperability issues or incompatibilities than a simple extension. Consequently, it is important that such proposals receive earlier and more in-depth review than unitary extensions.
与简单的扩展相比，对多个协议的一组相互关联的扩展通常会带来更大的互操作性问题或不兼容风险。因此，重要的是，此类提案应比单一延期得到更早和更深入的审查。
All that can be said about extensions applies with equal or greater force to variations -- in fact, by definition, protocol variations damage interoperability. They must, therefore, be intensely scrutinized. An extension adds features and, if well designed, allows interoperability between old and new implementations. A variation modifies features in such a way that old and new implementations may not interoperate. Throughout this document, what is said about extensions also applies to variations.
所有关于扩展的说法都同样或更有力地适用于变化——事实上，根据定义，协议变化破坏了互操作性。因此，必须对其进行严格审查。扩展添加了一些特性，如果设计得当，还允许新旧实现之间的互操作性。变体修改特性的方式可能使新旧实现无法互操作。在本文档中，有关扩展的内容也适用于变体。
According to its Mission Statement [RFC3935], the IETF produces high quality, relevant technical and engineering documents, including protocol standards. The mission statement goes on to say that the benefit of these standards to the Internet "is in interoperability - that multiple products implementing a standard are able to work together in order to deliver valuable functions to the Internet's users".
根据其任务声明[RFC3935]，IETF生产高质量、相关的技术和工程文件，包括协议标准。使命声明接着说，这些标准对互联网的好处在于“互操作性——实现一个标准的多个产品能够协同工作，以便向互联网用户提供有价值的功能”。
One consequence of this mission is that the IETF designs protocols for the single Internet. The IETF expects its protocols to work the same everywhere. Protocol extensions designed for limited environments may be reasonable provided that products with these extensions interoperate with products without the extensions. Extensions that break interoperability are unacceptable when products
该任务的一个结果是IETF为单一互联网设计协议。IETF希望其协议在任何地方都能起到相同的作用。为有限环境设计的协议扩展可能是合理的，前提是具有这些扩展的产品可以与不具有这些扩展的产品进行互操作。当产品失效时，破坏互操作性的扩展是不可接受的
with and without the extension are mixed. It is the IETF's experience that this tends to happen on the Internet even when the original designers of the extension did not expect this to happen.
有和没有扩展名是混合的。根据IETF的经验，这种情况往往发生在互联网上，即使扩展的原始设计者并不期望这种情况发生。
Another consequence of this definition of interoperability is that the IETF values the ability to exchange one product implementing a protocol with another. The IETF often specifies mandatory-to-implement functionality as part of its protocols so that there is a core set of functionality sufficient for interoperability that all products implement. The IETF tries to avoid situations where protocols need to be profiled to specify which optional features are required for a given environment, because doing so harms interoperability on the Internet as a whole.
互操作性定义的另一个结果是IETF重视实现协议的一个产品与另一个产品的交换能力。IETF通常指定强制实现功能作为其协议的一部分，以便有一组核心功能足以实现所有产品实现的互操作性。IETF试图避免需要分析协议以指定给定环境需要哪些可选功能的情况，因为这样做会损害整个Internet上的互操作性。
The IETF, and in particular the IESG, will apply these considerations when evaluating protocol extensions proposed inside or outside the IETF.
IETF，尤其是IESG，将在评估IETF内部或外部提议的协议扩展时应用这些考虑因素。
An extension is often likely to make use of additional values added to an existing IANA registry (in many cases, simply by adding a new "TLV" (type-length-value) field). It is essential that such new values are properly registered by the applicable procedures, including expert review where applicable (see BCP 26, [RFC2434]). Extensions may even need to create new IANA registries in some cases.
扩展通常可能使用添加到现有IANA注册表的附加值（在许多情况下，只需添加一个新的“TLV”（类型长度值）字段）。这些新值必须通过适用程序进行适当登记，包括专家审查（如适用）（见BCP 26，[RFC2434]）。在某些情况下，扩展甚至可能需要创建新的IANA注册中心。
Experience shows that the importance of this is often underestimated during extension design; designers sometimes assume that a new codepoint is theirs for the asking, or even simply for the taking. This is hazardous; it is far too likely that someone just taking a protocol value will find that the same value will later be formally assigned to another function, thus guaranteeing an interoperability problem.
经验表明，在扩展设计过程中，这一点的重要性往往被低估；设计师有时会假设一个新的代码点是他们的要求，甚至只是为了获取。这是危险的；仅仅获取协议值的人很可能会发现相同的值稍后会被正式分配给另一个函数，从而保证互操作性问题。
In many cases, IANA assignment requests trigger a thorough technical review of the proposal by a designated IETF expert reviewer. Requests are sometimes refused after such a review. Thus, extension designers must pay particular attention to any needed IANA assignments and to the applicable criteria.
在许多情况下，IANA分配请求会触发指定IETF专家评审员对提案进行彻底的技术评审。在这种审查之后，请求有时会被拒绝。因此，扩展设计者必须特别注意任何需要的IANA分配和适用的标准。
Some extensions may be considered minor (e.g., adding a straightforward new TLV to an application protocol, which will only impact a subset of hosts) and some may be considered major (e.g., adding a new IP option type, which will potentially impact every node on the Internet). This is essentially a matter of judgment. It
有些扩展可能被认为是次要的（例如，向应用程序协议添加一个简单的新TLV，这只会影响一部分主机），有些扩展可能被认为是主要的（例如，添加一个新的IP选项类型，这可能会影响Internet上的每个节点）。这本质上是一个判断问题。信息技术
could be argued that anything requiring at most Expert Review in [RFC2434] is probably minor, and anything beyond that is major. However, even an apparently minor extension may have unforeseen consequences on interoperability. Thus, the distinction between major and minor is less important than ensuring that the right amount of technical review takes place in either case. In general, the expertise for such review lies within the same SDO that developed the original protocol. Therefore, the expertise for such review for IETF protocols lies within the IETF.
可以说，[RFC2434]中要求最多专家审查的内容可能是次要的，而超出此范围的内容则是主要的。然而，即使是一个表面上很小的扩展也可能会对互操作性产生不可预见的后果。因此，与确保在任何一种情况下进行适当数量的技术审查相比，区分主要审查和次要审查都不那么重要。一般而言，此类审查的专业知识属于制定原始方案的同一SDO。因此，IETF协议审查的专业知识属于IETF。
There may sometimes be doubt whether a particular proposal is or is not truly a protocol extension. When in doubt, it is preferable to err on the side of additional review. However, it should be noted that if an 'extension' only consists of registering a new value with IANA in a First Come First Served registry [RFC2434], this document is not intended to require formal IETF review. Informal review by experts may, nevertheless, be valuable. In other cases (Section 5), there is a well-specified procedure for extensions that should be followed.
有时可能会怀疑某一提案是否真的是议定书的延伸。当有疑问时，最好是在附加审查方面犯错。但是，应注意，如果“扩展”仅包括在先到先得注册表[RFC2434]中向IANA注册新值，则本文件不需要正式的IETF审查。然而，专家的非正式审查可能是有价值的。在其他情况下（第5节），应遵循明确规定的扩展程序。
The only safe rule is that, even if an extension appears minor to the person proposing it, early review by subject matter experts is advisable. For protocols that have been developed in the IETF, the appropriate forum for such review is the IETF, either in the relevant WG or Area, or by individual IETF experts if no such WG exists.
唯一安全的规则是，即使延期对提议延期的人来说显得微不足道，也建议由主题专家提前审查。对于已在IETF中制定的协议，进行此类审查的适当论坛是IETF，无论是在相关工作组或领域，还是由个别IETF专家（如果不存在此类工作组）。
In order to be adequately reviewed by relevant experts, a proposed extension must be documented in a clear and well-written specification that IETF subject matter experts have access to and can review. Ideally, such a document would be published as an Internet Draft, using terminology and content that is sufficiently consistent with the unextended specification that these experts can readily identify the technical changes proposed at an early stage.
为了得到相关专家的充分审查，必须在IETF主题专家可以访问和审查的清晰和书面规范中记录提议的扩展。理想情况下，此类文件将以互联网草稿的形式发布，使用的术语和内容应与未公布的规范充分一致，以便这些专家能够在早期阶段轻松确定提出的技术变更。
The IETF has formal liaisons in place with a number of SDOs; documentation of the liaison process is in [RFC4052], [RFC4053], and [RFC4691]. These liaison channels should be used as relevant for discussing and reviewing extensions, as should informal communication at the engineering level (for example, experts from other SDOs are welcome to participate in IETF meetings and mailing lists). Where formal liaison does not exist, the point of contact in the IETF should be the Chairs of relevant WGs, the most appropriate Area Director, or, in case of doubt, the IESG as a whole.
IETF与多个SDO建立了正式联络；联络过程的文件记录在[RFC4052]、[RFC4053]和[RFC4691]中。这些联络渠道应与讨论和审查扩展相关，工程层面的非正式沟通也应如此（例如，欢迎其他SDO的专家参加IETF会议和邮件列表）。如果不存在正式联络，IETF中的联络点应为相关工作组的主席、最合适的区域主管，或在有疑问的情况下，整个IESG。
In some cases, explicit provision is made in the relevant RFCs for extending individual IETF protocols. Nothing in this document overrides such procedures. Some such cases are mentioned in Section 5.
在某些情况下，相关RFC中对扩展个别IETF协议做出了明确规定。本文件中的任何内容都不能推翻此类程序。第5节提到了一些此类情况。
There are several ways in which an extension to an IETF protocol can be considered for publication as an RFC:
有几种方式可以考虑将IETF协议的扩展发布为RFC：
1. Extensions to IETF protocols developed within the IETF will be subject to the normal IETF process, exactly like new designs. It is not suggested that this is a panacea; appropriate cross-working-group and cross-area review is needed within the IETF to avoid oversights and mistakes.
1. IETF内开发的IETF协议扩展将遵循正常的IETF流程，与新设计完全相同。这并不是说这是一种灵丹妙药；IETF内部需要适当的跨工作组和跨领域审查，以避免疏忽和错误。
2. Extensions to IETF protocols discussed in an IRTF Research Group may well be the prelude to regular IETF discussion. However, a Research Group may desire to specify an experimental extension before the work is mature enough for IETF processing. In this case, the Research Group is required to involve appropriate IETF or IANA experts in their process to avoid oversights.
2. IRTF研究小组讨论的IETF协议扩展很可能是常规IETF讨论的前奏。然而，研究小组可能希望在工作成熟到足以进行IETF处理之前指定一个实验扩展。在这种情况下，研究小组需要让适当的IETF或IANA专家参与其过程，以避免疏忽。
3. Extensions to IETF protocols described in Independent Submissions to the RFC Editor are subject to IESG review, currently described in BCP 92 [RFC3932]. If appropriate, the IESG advises the RFC Editor that full IETF processing is needed, or that relevant IANA procedures need to be followed before publication can proceed. Note that Independent Submissions cannot be placed on the IETF Standards Track; they would need to enter full IETF processing.
3. 独立提交给RFC编辑器中描述的IETF协议扩展需接受IESG审查，目前在BCP 92[RFC3932]中描述。如果合适，IESG建议RFC编辑需要完整的IETF处理，或者在发布之前需要遵循相关的IANA程序。请注意，独立提交的文件不能放在IETF标准轨道上；他们需要进入完整的IETF处理。
Where vendors or other SDOs identify a requirement for extending an IETF protocol, their first step should be to consider the scenarios listed in Section 1. If the requirement is straightforward and within the scope of a documented extension mechanism, the way is clear, and the documented mechanism must be followed. If these two conditions are not met, the next step should be to contact the relevant IETF Area Director to check whether there is an active WG in the area or, at least, relevant expertise available in the IETF. At this point, it will be possible to select the most appropriate of the above three routes. Regular IETF process is most likely to be suitable, assuming sufficient interest can be found in the IETF community. IRTF process is unlikely to be suitable unless there is a genuine research context for the proposed extension.
当供应商或其他SDO识别扩展IETF协议的要求时，他们的第一步应该是考虑第1节中列出的方案。如果需求是直接的，并且在文档化的扩展机制的范围内，那么方法是明确的，并且必须遵循文档化的机制。如果不满足这两个条件，下一步应联系相关的IETF区域主管，以检查该区域是否有活跃的工作组，或者至少IETF中是否有可用的相关专业知识。此时，可以从上述三条路线中选择最合适的路线。假设IETF社区对IETF有足够的兴趣，则常规IETF流程最为合适。IRTF流程不太可能适用，除非提议的扩展有真正的研究背景。
In the event that the IETF no longer has relevant expertise, there are still two choices to discuss with the Area Director: bring the work to the IETF (i.e., the IETF imports expertise) or reach mutual agreement to do the work elsewhere (i.e., the IETF explicitly exports change control).
如果IETF不再具有相关专业知识，则仍有两种选择需要与区域总监讨论：将工作提交给IETF（即IETF导入专业知识）或达成共同协议在其他地方开展工作（即IETF明确导出变更控制）。
In the case of an SDO that identifies a requirement for a standardized extension, a standards development process within the IETF (while maintaining appropriate liaison) is strongly recommended in preference to publishing a non-IETF standard. Otherwise, the implementor community will be faced with a standard split into two or more parts in different styles, obtained from different sources, with no unitary control over quality, compatibility, interoperability, and intellectual property conditions. Note that, since participation in the IETF is open, there is no formality or restriction for participants in other SDOs choosing to work in the IETF as well. In some cases (see Section 5), the IETF has well-defined procedures for this in place.
如果SDO确定了标准化扩展的需求，强烈建议在IETF内进行标准开发过程（同时保持适当的联络），而不是发布非IETF标准。否则，实现者社区将面临一个标准分成两个或多个不同风格的部分，从不同的来源获得，对质量、兼容性、互操作性和知识产权条件没有统一的控制。请注意，由于IETF的参与是开放的，因此对于选择在IETF中工作的其他SDO的参与者，没有任何形式或限制。在某些情况下（见第5节），IETF为此制定了明确的程序。
Naturally, SDOs can and do develop scenarios, requirements, and architectures based on IETF specifications. It is only actual protocol extensions and changes that need to go through the IETF process. However, there is large risk of wasted effort if significant investment is made in planning stages for use of IETF technology without early review and feedback from the IETF. Other SDOs are encouraged to communicate informally or formally with the IETF as early as possible, to avoid false starts. Early technical review in a collaborative spirit is of great value. Each SDO can "own" its ideas and discuss them in its own fora, but should start talking to the IETF experts about those ideas the moment the idea is well formulated. It is understood that close collaboration may be needed in order that the IETF experts correctly understand the systems architecture envisaged by the other SDO. This is much preferable to a situation where another SDO presents the IANA and the IETF with a 'fait accompli.'
当然，SDO可以并且确实基于IETF规范开发场景、需求和体系结构。只有实际的协议扩展和更改需要通过IETF过程。然而，如果在没有IETF的早期审查和反馈的情况下，在使用IETF技术的规划阶段进行重大投资，则存在浪费工作的巨大风险。鼓励其他SDO尽早与IETF进行非正式或正式沟通，以避免错误启动。本着协作精神进行早期技术审查是非常有价值的。每个SDO都可以“拥有”自己的想法，并在自己的论坛上讨论这些想法，但应该在想法形成的那一刻就开始与IETF专家讨论这些想法。据了解，可能需要密切合作，以便IETF专家正确理解其他SDO设想的系统架构。这比另一个SDO向IANA和IETF呈现“既成事实”的情况要好得多
Vendors that identify a requirement for an extension are strongly recommended to start informal discussion in the IETF and to publish a preliminary Internet Draft describing the requirements. This will allow the vendor, and the community, to evaluate whether there is community interest and whether there are any major or fundamental issues. However, in the case of a vendor that identifies a requirement for a proprietary extension that does not generate interest in the IETF (or IRTF) communities, an Independent Submission to the RFC Editor is strongly recommended in preference to publishing a proprietary document. Not only does this bring the draft to the
强烈建议确定扩展需求的供应商在IETF中开始非正式讨论，并发布描述需求的初步互联网草案。这将允许供应商和社区评估是否存在社区利益以及是否存在任何重大或根本问题。但是，如果供应商确定了对专有扩展的要求，而该扩展不会引起IETF（或IRTF）社区的兴趣，则强烈建议向RFC编辑器提交独立的文件，而不是发布专有文档。这不仅使草案成为现实
attention of the community, but it also ensures a minimum of review [RFC3932], and (if published as an RFC) makes the proprietary extension available to the whole community.
社区的关注，但它也确保了最低限度的审查[RFC3932]，并且（如果作为RFC发布）使专有扩展可供整个社区使用。
If, despite these recommendations, a vendor or SDO does choose to publish its own specification for an extension to an IETF protocol, the following guidance applies:
尽管有这些建议，如果供应商或SDO确实选择发布其自己的IETF协议扩展规范，则以下指南适用：
o Extensions to IETF protocols should be well, and publicly, documented, and reviewed at an early stage by the IETF community to be sure that the extension does not undermine basic assumptions and safeguards designed into the protocol (such as security functions) or its architectural integrity.
o IETF社区应在早期阶段对IETF协议的扩展进行充分、公开、记录和审查，以确保扩展不会破坏协议中设计的基本假设和保障措施（如安全功能）或其架构完整性。
o Vendors and other SDOs are formally requested to submit any such proposed publications for IETF review, and are invited to actively participate in the IETF process. Submission may be by an established liaison channel if it exists, or by direct communication with the relevant WG or the IESG. This should be done at an early stage, before a large investment of effort has taken place, in case basic problems are revealed. When there is a formal liaison in place between the other SDO and the IETF, the liaison channel should be used to ensure that review takes place, both by relevant experts and by established review teams or Directorates within the IETF. If there is no formal liaison, the other SDO or vendor should ask the IESG (or a relevant Area Director) to obtain such reviews. Note that general aspects such as security, internationalization, and management may need review, as well as the protocol as such.
o 供应商和其他SDO被正式要求提交任何此类建议出版物供IETF审查，并被邀请积极参与IETF过程。提交可通过已建立的联络渠道（如有）或与相关工作组或IESG直接沟通。这应该在早期阶段进行，在投入大量精力之前，以防基本问题暴露出来。当其他SDO和IETF之间有正式联络时，应使用联络渠道确保相关专家和IETF内成立的评审小组或董事会进行评审。如果没有正式联络，其他SDO或供应商应要求IESG（或相关区域总监）获得此类审查。请注意，安全、国际化和管理等一般方面以及协议本身可能需要审查。
o In the case of extensions involving only routine IANA parameter assignments, for which there is an underlying IETF specification containing clear IANA Considerations, this request is satisfied as long as those considerations are satisfied (see [RFC2434]). Anything beyond this requires an explicit protocol review by experts within the IETF.
o 对于仅涉及常规IANA参数分配的扩展，存在包含明确IANA注意事项的基础IETF规范，只要满足这些注意事项，即可满足该请求（参见[RFC2434]）。除此之外的任何内容都需要IETF内的专家进行明确的协议审查。
o Note that, like IETF specifications, such proposed publications must include an IANA Considerations section to ensure that protocol parameter assignments that are needed to deploy extensions are not made until after a proposed extension has received adequate review, and then to ensure that IANA has precise guidance on how to make those assignments.
o 请注意，与IETF规范一样，此类拟定出版物必须包括IANA注意事项部分，以确保在拟定的扩展得到充分审查之前，不会进行部署扩展所需的协议参数分配，然后确保IANA对如何完成这些任务有准确的指导。
It is relatively common for MIB modules, which are all, in effect, extensions of the SMI data model, to be defined or extended outside the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and reviewers.
MIB模块比较常见，实际上，它们都是SMI数据模型的扩展，在IETF之外定义或扩展。BCP 111[RFC4181]为作者和评审员提供了详细的指导。
A number of protocols have foreseen experimental values for certain IANA parameters, so that experimental usages and extensions may be tested without need for a special parameter assignment. It must be stressed that such values are not intended for production use or as a way to evade the type of technical review described in this document. See [RFC3692] and [RFC4727].
许多协议已经预见了某些IANA参数的实验值，因此可以在不需要特殊参数分配的情况下测试实验使用和扩展。必须强调的是，此类值并非用于生产用途，也不是逃避本文件所述技术审查的一种方式。参见[RFC3692]和[RFC4727]。
RADIUS [RFC2865] is designed to carry attributes and allow definition of new attributes. But it is important that discussion of new attributes involve the IETF community of experts knowledgeable about the protocol's architecture and existing usage in order to fully understand the implications of a proposed extension. Adding new attributes without such discussion creates a high risk of interoperability or functionality failure. For this reason among others, the IETF has an active RADIUS Extensions WG at the time of writing.
RADIUS[RFC2865]设计用于携带属性并允许定义新属性。但是，重要的是，新属性的讨论需要IETF专家社区了解协议的体系结构和现有用法，以便充分理解提议的扩展的含义。在没有此类讨论的情况下添加新属性会造成互操作性或功能失败的高风险。出于这个原因，在撰写本文时，IETF有一个活动的RADIUS Extensions WG。
There are certain documents that specify a change process for specific IETF protocols, such as: The SIP change process [RFC3427] The (G)MPLS change process [CHANGEPROC]
某些文件规定了特定IETF协议的变更过程，例如：SIP变更过程[RFC3427]和（G）MPLS变更过程[CHANGEPROC]
This document does not override such specific change processes.
本文件不覆盖此类特定变更流程。
All IETF documents fall under the IETF's intellectual property rules, BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, there are restrictions on the production of derivative works, and there are rights that remain with the original authors. Anybody outside the IETF considering an extension based on an IETF document must bear these legal restrictions and rights in mind.
所有IETF文件均属于IETF的知识产权规则BCP 78[RFC3978]和BCP 79[RFC3979]及其修订版。特别是，对衍生作品的制作有限制，原作者仍享有一些权利。IETF以外的任何人在考虑基于IETF文件的扩展时，必须牢记这些法律限制和权利。
An extension must not introduce new security risks without also providing an adequate counter-measure, and in particular it must not inadvertently defeat security measures in the unextended protocol. This aspect must always be considered during IETF review.
在没有提供足够的应对措施的情况下，扩展不得引入新的安全风险，特别是它不得无意中破坏未扩展协议中的安全措施。IETF审查期间必须始终考虑这一方面。
The IETF requests IANA to pay attention to the requirements of this document when requested to make protocol parameter assignments for vendors or other SDOs, i.e., to respect the IANA Considerations of all RFCs that contain them, and the general considerations of BCP 26 [RFC2434].
当要求IANA为供应商或其他SDO分配协议参数时，IETF要求IANA注意本文件的要求，即尊重包含这些参数的所有RFC的IANA注意事项以及BCP 26[RFC2434]的一般注意事项。
This document is heavily based on an earlier draft under a different title by Scott Bradner and Thomas Narten.
本文件主要基于斯科特·布拉德纳（Scott Bradner）和托马斯·纳滕（Thomas Narten）在不同标题下的早期草案。
That earlier draft stated: The initial version of this document was put together by the IESG in 2002. Since then, it has been reworked in response to feedback from John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush, Bernard Aboba, and others.
该早期草案指出：该文件的初始版本由IESG于2002年编制。从那时起，它就根据约翰·拉夫尼、亨里克·列夫科维茨、马克·汤斯利、兰迪·布什、伯纳德·阿博巴和其他人的反馈进行了修改。
Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson, Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments on this document.
Ted Hardie、Scott Brim、Dan Romascanu、Jari Arkko、Loa Andersson、Adrian Farrel、Roy Fielding、Keith Moore、Bernard Aboba、Elwyn Davies、Stephen Trowbridge和Ted Ts'o也对该文件发表了宝贵意见。
Sam Hartman contributed the section on interoperability.
Sam Hartman对互操作性部分做出了贡献。
This document was produced using the xml2rfc tool [RFC2629].
本文档是使用xml2rfc工具[RFC2629]生成的。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3427]Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的更改过程”，BCP 67，RFC 3427，2002年12月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932]Alvestrand，H.，“IESG和RFC编辑文件：程序”，BCP 92，RFC 3932，2004年10月。
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004.
[RFC3935]Alvestrand，H.，“IETF的使命声明”，BCP 95，RFC 3935，2004年10月。
[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]Bradner，S.，“IETF在贡献中的权利”，BCP 78，RFC 3978，2005年3月。
[RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.
[RFC3979]Bradner，S.，“IETF技术中的知识产权”，BCP 79，RFC 3979，2005年3月。
[RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
[RFC4052]Daigle，L.和互联网架构委员会，“IETF联络关系管理的IAB流程”，BCP 102，RFC 4052，2005年4月。
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[RFC4053]Trowbridge，S.，Bradner，S.，和F.Baker，“处理进出IETF的联络声明的程序”，BCP 103，RFC 4053，2005年4月。
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]Heard，C.，“MIB文件的作者和评审者指南”，BCP 111，RFC 41812005年9月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[CHANGEPROC] Andersson, L. and A. Farrel, "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", Work in Progress, October 2006.
[CHANGEPROC]Andersson，L.和A.Farrel，“多协议标签交换（MPLS）和通用MPLS（GMPLS）协议和程序的变更过程”，正在进行的工作，2006年10月。
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[RFC2629]Rose，M.，“使用XML编写I-D和RFC”，RFC 26292999年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison to Another Organization", RFC 4691, October 2006.
[RFC4691]Andersson，L.“作为IETF与另一组织的联络人的指南”，RFC 4691，2006年10月。
Authors' Addresses
作者地址
Scott Bradner Harvard University 29 Oxford St. Cambridge, MA 02138 US
斯科特·布拉德纳哈佛大学29牛津圣剑桥，马萨诸塞州02138美国
EMail: sob@harvard.edu
EMail: sob@harvard.edu
Brian Carpenter, Ed. IBM 8 Chemin de Blandonnet 1214 Vernier Switzerland
Brian Carpenter，编辑：IBM 8 Chemin de Blandnnet 1214 Vernier Switzerland
EMail: brc@zurich.ibm.com
EMail: brc@zurich.ibm.com
Thomas Narten IBM 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 US
Thomas Narten IBM 3039 Cornwallis Ave.邮政信箱12195-美国北卡罗来纳州三角研究公园BRQA/502 27709-2195
EMail: narten@us.ibm.com
EMail: narten@us.ibm.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编辑功能的资金目前由互联网协会提供。