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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4775 (Best Current Practice) | |
| 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
Show full document text