Network Working Group                                         S. Bradner
Request for Comments: 4775                                       Harvard
BCP: 125                                               B. Carpenter, Ed.
Category: Best Current Practice                                T. Narten
                                                           December 2006
Network Working Group                                         S. Bradner
Request for Comments: 4775                                       Harvard
BCP: 125                                               B. Carpenter, Ed.
Category: Best Current Practice                                T. Narten
                                                           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).




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.


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.


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
1. Introduction
1. 介绍

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.


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.


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:


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.


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.


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.


2. Technical Risks in Extensions
2. 扩展中的技术风险

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.


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.


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.


3. General Considerations
3. 一般考虑
3.1. The Importance of Interoperability
3.1. 互操作性的重要性

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".


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


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.


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.


The IETF, and in particular the IESG, will apply these considerations when evaluating protocol extensions proposed inside or outside the IETF.


3.2. Registered Values and the Importance of IANA Assignments
3.2. 注册价值和IANA分配的重要性

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.


3.3. Significant Extensions Require Technical Review
3.3. 重大扩展需要技术审查

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


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.


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.


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.


3.4. Quality and Consistency
3.4. 质量和一致性

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.


3.5. The Role of Formal Liaisons
3.5. 正式联络人的作用

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.


4. Procedure for Review of Extensions
4. 审查延期的程序

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.


There are several ways in which an extension to an IETF protocol can be considered for publication as an 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.


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).


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.


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.'


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


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.


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:


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对如何完成这些任务有准确的指导。

5. Some Specific Issues
5. 一些具体问题

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].


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]


This document does not override such specific change processes.


6. Intellectual Property
6. 知识产权

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文件的扩展时,必须牢记这些法律限制和权利。

7. Security Considerations
7. 安全考虑

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.


8. IANA Considerations
8. IANA考虑

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]的一般注意事项。

9. Acknowledgements
9. 致谢

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.


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].


10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[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月。

10.2. Informative References
10.2. 资料性引用

[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.


[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



Brian Carpenter, Ed. IBM 8 Chemin de Blandonnet 1214 Vernier Switzerland

Brian Carpenter,编辑:IBM 8 Chemin de Blandnnet 1214 Vernier Switzerland


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


Full Copyright Statement


Copyright (C) The IETF Trust (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中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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


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




Funding for the RFC Editor function is currently provided by the Internet Society.