@techreport{farrel-problem-protocol-icrm-00,
    number =    {draft-farrel-problem-protocol-icrm-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-farrel-problem-protocol-icrm/00/},
    author =    {Adrian Farrel},
    title =     {{Observations on Proposing Protocol Enhancements that Address Stated Requirements but also go Further by Meeting more General Needs
}},
    pagetotal = 12,
    year =      2003,
    month =     jun,
    day =       11,
    abstract =  {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.},
}