Skip to main content

Observations on Proposing Protocol Enhancements that Address Stated Requirements but also go Further by Meeting more General Needs

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Adrian Farrel
Last updated 2003-06-11
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


Procedures in place and currently being developed within the IETF encourage the development and agreement of clear requirements before the new protocols or protocol extensions are accepted as work items. This does not preclude nor prohibit individuals from engaging in such protocol work outside of the IETF, but it acknowledges that acceptance of the work may be subject to proving the requirements through a requirements document or through deployment and usage experience. That work within the IETF on a requirements document may change the underlying assumptions made by protocol developers and thereby render their work obsolete or risible is a risk taken by all who spend their time enhancing the set of available protocols without first agreeing the requirements. At the same time, some problem statements or requirement documents are very narrowly scoped to address a very specific need. There is a risk that the development of a solution to such a precise problem may be non-extensible and may make the protocol unusable in a wider context. This document examines the need to avoid tying new protocol developments too tightly to the problem statement or requirement documents. It uses an example from the ITU ASON requirements for signaling protocols within optical networks to illustrate how adhering to the requirements statement too zealously may unnecessarily restrict the applicability of the protocol in a wider context.


Adrian Farrel

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)