One document matched: draft-iesg-vendor-extensions-00.txt

INTERNET-DRAFT                                          Scott O. Bradner
<draft-iesg-vendor-extensions-00.txt>                 Harvard University
                                                           Thomas Narten
                                                                     IBM
                                                       December 20, 2002

           Considerations on the Extensibility of IETF protocols


                   <draft-iesg-vendor-extensions-00.txt>


Status of this Memo
   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as work in progress.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document discusses 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 need to be reviewed by
   the larger IETF community. The document also recommends that major
   extensions to IETF protocols only take place through normal IETF
   processes or if adequate controls are in place to ensure sufficient
   IETF review.

   Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    2




draft-iesg-vendor-extensions-00.txt                             [Page 1]

INTERNET-DRAFT                                        December  20, 2002


   2.  Principles...............................................    2

   3.  Recommendation...........................................    4

   4.  IANA Considerations......................................    5

   5.  Security Considerations..................................    5

   6.  Acknowledgments..........................................    5

   7.  Informative References...................................    5

   8.  Editor's Addresses.......................................    5


1.  Introduction

   When developing protocols, quite a few IETF working groups have made
   facilities whereby these protocols can be extended in the future.
   Vendors, other standards development organizations and technology
   fora have used those facilities.  Sometimes the result is non-
   interoperability or poorly designed mechanisms.

   The purpose of this memo is to make explicit some guiding princples
   based on the community's experience with these mechanisms. The IESG
   is presently applying some version of these principles when
   evaluating proposals for new standards.


2.  Principles

   The most important principle driving this memo, and in fact the IETF
   as a whole is the principle of:

    o IETF Standards are intended to permit multiple implementers to
      build implementations of protocols that will interoperate.

   It is a good principle to design extensible protocols but extensions
   should be done carefully and with a full understanding of the base
   protocol.

   If extensions to IETF protocols are done outside the IETF, experience
   has shown that documentation of these extensions can be hard to
   obtain, short-sighted design choices are sometimes made, basic
   underlying architectural principals of the protocol are sometimes
   violated, assessing the quality of the specification is hard, and
   achieving interoperability can be hard.




draft-iesg-vendor-extensions-00.txt                             [Page 2]

INTERNET-DRAFT                                        December  20, 2002


   It can be particularly difficult for a user to figure out who is at
   fault and what to do about it if two pieces of software that both
   claim to be implementations of an IETF standard do not work together.

   Yet there are situations where extensions to IETF protocols can make
   sense. There are two general classes of extensions. The first class,
   called minor extensions, refers to extensions of limited scope. In
   such cases:

    - the extension is proprietary in nature, in that it is used to
      carry out vendor-specific tasks and does not have general
      applicability, or


    - the problem being solved is so narrowly scoped that a standardized
      approach is not justified (however, few problems can be scoped
      very narrowly, and often there is a need for more global context,
      cf. P-headers in RFC 3427/draft-tsvarea-sipchange-03.txt).

    - only one (or a very small number of) vendors will ever implement
      the extension

    - the extension doesn't modify the underlying protocol itself.
      Instead, the underlying protocol carries the extension as opaque
      data.


   Examples of minor extensions include the DHC vendor-specific option,
   the enterprise OID tree for MIB modules, vnd. MIME types, and some
   classses of (non-critical) certification extensions. Such extensions
   can safely be made without IETF coordination and are indicated by
   having an IANA Considerations that allows assignments of code points
   with minimal overhead (e.g., first come first served) [IANA-CONSID].

   The more interesting class of extensions, called major extensions,
   involves those in which multiple vendors are expected to implement
   the extension and the extension is viewed as solving an important
   problem. Such extensions should only be done when:

    - there is a clear need for the function and there is no other
      mechanism within the protocol that already accomplishes the goal
      of the extension, even if it would do so with less efficiency.

    - it is expected that multiple vendors will need to implement the
      extension

    - use of the extension will be required in environments where if the
      extensions doesn't work properly, the underlying protocol will be



draft-iesg-vendor-extensions-00.txt                             [Page 3]

INTERNET-DRAFT                                        December  20, 2002


      viewed as having failed.

   Major extensions should be well, and publicly, documented and checked
   by the IETF community to be sure that the extension does not defeat
   safeguards designed into the protocol, such as security functions, or
   undermine its architectural integrity.


3.  Recommendation

   The following principles are the main guiding principles concerning
   extensions to IETF protocol:

    o All major extensions to IETF protocols should be done with direct
      involvement of the IETF.

    o The decision on whether an extension is major or minor should be
      done with the direct involvement of the IETF.

   Extensions should be done by IETF working groups using normal IETF
   processes or, if a working group does not consider a proposed
   extension to be general enough, documented in an IETF informational
   RFC that is reviewed by the working group and the IESG.  No
   individual, vendor, SDO or forum should be able create what is viewed
   to be a major extension to an IETF protocol on its own and
   legitimately be able to claim that implementations that implement the
   extension are compliant to the IETF specification.

   Exactly what is considered to be a major extension and what is
   considered minor depends on the specific protocol being extended. For
   example, some protocols are designed to carry opaque data without
   impacting the underlying protocol. The definition of additional
   opaque data types would usually not be considered a major extension,
   whereas a change that modified the underlying protocol mechanisms
   would be.

   Thus IETF protocols should not be designed to encourage the
   definition of major extensions outside the IETF process.  IETF
   protocols should carefully analyze and identify which protocol
   components can be extended safely with minimal or no community review
   and which need community review, and then write appropriate IANA
   considerations sections that ensure the appropriate level of
   community review. For example, the definition of additional data
   formats that can be carried may require no review, while the addition
   of new protocol message types might require a Standards Track action
   [IANA-CONSID].





draft-iesg-vendor-extensions-00.txt                             [Page 4]

INTERNET-DRAFT                                        December  20, 2002


4.  IANA Considerations

   None.


5.  Security Considerations

   Insufficiently reviewed extensions can easily lead to protocols with
   significant security vulnerabilities.


6.  Acknowledgments

   The initial version of this document was put together by the IESG.


7.  Informative References

   [IANA-CONSID] Guidelines for Writing an IANA Considerations Section
           in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 2434.


8.  Editor's Addresses

   Scott O. Bradner
   Harvard University
   Holyoke Center, Room 813
   1350 Mass. Ave.
   Cambridge, MA  02138
   USA

   Phone: +1 617-495-3864
   EMail: sob@harvard.edu

   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: +1 919 254 7798
   EMail: narten@us.ibm.com









draft-iesg-vendor-extensions-00.txt                             [Page 5]