Procedures for Protocol Extensions and Variations
RFC 4775
Document | Type |
RFC - Best Current Practice
(December 2006; No errata)
Also known as BCP 125
Was draft-carpenter-protocol-extensions (individual in gen area)
|
|
---|---|---|---|
Authors | Thomas Narten , Scott Bradner , Brian Carpenter | ||
Last updated | 2018-12-20 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4775 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | (None) |
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). 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. 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. Bradner, et al. Best Current Practice [Page 1] RFC 4775 Procedures for Protocol Extensions December 2006 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 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. 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. Bradner, et al. Best Current Practice [Page 2] RFC 4775 Procedures for Protocol Extensions December 2006 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 aShow full document text