    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 a
       requirement for an extension to an IETF protocol.  The question
       addressed by this document is how such bodies should proceed.  There
       are several possible scenarios:

       1.  The requirement is straightforward and within the scope of
           whatever extension mechanism the base protocol includes.

       2.  The requirement is, or may be, outside that scope, and:
           1.  The IETF still has an active WG in the area;
           2.  The IETF has no active WG, but has relevant expertise;
           3.  The IETF no longer has a nucleus of relevant expertise.

       Especially in the latter three cases, there are technical risks in
       extension design, described in the next section.  These risks are
       higher when extensions to IETF protocols are made outside the IETF
       and without consulting the IETF.

       This document is focused on appropriate procedures and practices to
       minimize the chance that extensions developed outside the IETF will
       encounter these risks and, therefore, become useless or, worse,
       damaging to interoperability.  Architectural considerations are
       documented elsewhere.  This document is directed principally at other
       SDOs and vendors considering requirements for extensions to IETF
       protocols.  It does not modify formal IETF processes.

       The IETF claims no special position.  Everything said here about IETF
       protocols would apply with equal force to protocols specified by any
       SDO.  The IETF should follow whatever procedures another SDO lays
       down for extensions to its own protocols, if the IETF identifies a
       need for such an extension.

    2.  Technical Risks in Extensions

       Extensions may be developed without full understanding of why the
       existing protocol was designed the way that it is -- e.g., what ideas
       were brought up during the original development and rejected because
       of some problem with them.  Also, extensions could unintentionally
       negate some key function of the existing protocol (such as security
       or congestion control).  Design choices can be made without analyzing
       their impact on the protocol as a whole, and basic underlying

    Bradner, et al.          Best Current Practice                  [Page 3]

    RFC 4775           Procedures for Protocol Extensions      December 2006

       architectural principles of the protocol can be violated.  Also,
       there is a risk that mutually incompatible extensions may be
       developed independently.

       Of course, the IETF itself is not immune to such mistakes, suggesting
       a need for WGs to document their design decisions (including paths
       rejected) and some rationale for those decisions, for the benefit of
       both those within the IETF and those outside the IETF, perhaps years
       later.

       Documentation of non-IETF extensions can sometimes be hard to obtain,
       so assessing the quality of the specification, verifying
       interoperability, and verifying compatibility with other extensions
       (including past and future extensions) can be hard or impossible.

       A set of interrelated extensions to multiple protocols typically
       carries a greater danger of interoperability issues or
       incompatibilities than a simple extension.  Consequently, it is
       important that such proposals receive earlier and more in-depth
       review than unitary extensions.

       All that can be said about extensions applies with equal or greater
       force to variations -- in fact, by definition, protocol variations
       damage interoperability.  They must, therefore, be intensely
       scrutinized.  An extension adds features and, if well designed,
       allows interoperability between old and new implementations.  A
       variation modifies features in such a way that old and new
       implementations may not interoperate.  Throughout this document, what
       is said about extensions also applies to variations.

    3.  General Considerations

    3.1.  The Importance of Interoperability

       According to its Mission Statement [RFC3935], the IETF produces high
       quality, relevant technical and engineering documents, including
       protocol standards.  The mission statement goes on to say that the
       benefit of these standards to the Internet "is in interoperability -
       that multiple products implementing a standard are able to work
       together in order to deliver valuable functions to the Internet's
       users".

       One consequence of this mission is that the IETF designs protocols
       for the single Internet.  The IETF expects its protocols to work the
       same everywhere.  Protocol extensions designed for limited
       environments may be reasonable provided that products with these
       extensions interoperate with products without the extensions.
       Extensions that break interoperability are unacceptable when products

    Bradner, et al.          Best Current Practice                  [Page 4]

    RFC 4775           Procedures for Protocol Extensions      December 2006

       with and without the extension are mixed.  It is the IETF's
       experience that this tends to happen on the Internet even when the
       original designers of the extension did not expect this to happen.

       Another consequence of this definition of interoperability is that
       the IETF values the ability to exchange one product implementing a
       protocol with another.  The IETF often specifies mandatory-to-
       implement functionality as part of its protocols so that there is a
       core set of functionality sufficient for interoperability that all
       products implement.  The IETF tries to avoid situations where
       protocols need to be profiled to specify which optional features are
       required for a given environment, because doing so harms
       interoperability on the Internet as a whole.

       The IETF, and in particular the IESG, will apply these considerations
       when evaluating protocol extensions proposed inside or outside the
       IETF.

    3.2.  Registered Values and the Importance of IANA Assignments

       An extension is often likely to make use of additional values added
       to an existing IANA registry (in many cases, simply by adding a new
       "TLV" (type-length-value) field).  It is essential that such new
       values are properly registered by the applicable procedures,
       including expert review where applicable (see BCP 26, [RFC2434]).
       Extensions may even need to create new IANA registries in some cases.

       Experience shows that the importance of this is often underestimated
       during extension design; designers sometimes assume that a new
       codepoint is theirs for the asking, or even simply for the taking.
       This is hazardous; it is far too likely that someone just taking a
       protocol value will find that the same value will later be formally
       assigned to another function, thus guaranteeing an interoperability
       problem.

       In many cases, IANA assignment requests trigger a thorough technical
       review of the proposal by a designated IETF expert reviewer.
       Requests are sometimes refused after such a review.  Thus, extension
       designers must pay particular attention to any needed IANA
       assignments and to the applicable criteria.

    3.3.  Significant Extensions Require Technical Review

       Some extensions may be considered minor (e.g., adding a
       straightforward new TLV to an application protocol, which will only
       impact a subset of hosts) and some may be considered major (e.g.,
       adding a new IP option type, which will potentially impact every node
       on the Internet).  This is essentially a matter of judgment.  It

    Bradner, et al.          Best Current Practice                  [Page 5]

    RFC 4775           Procedures for Protocol Extensions      December 2006

       could be argued that anything requiring at most Expert Review in
       [RFC2434] is probably minor, and anything beyond that is major.
       However, even an apparently minor extension may have unforeseen
       consequences on interoperability.  Thus, the distinction between
       major and minor is less important than ensuring that the right amount
       of technical review takes place in either case.  In general, the
       expertise for such review lies within the same SDO that developed the
       original protocol.  Therefore, the expertise for such review for IETF
       protocols lies within the IETF.

       There may sometimes be doubt whether a particular proposal is or is
       not truly a protocol extension.  When in doubt, it is preferable to
       err on the side of additional review.  However, it should be noted
       that if an 'extension' only consists of registering a new value with
       IANA in a First Come First Served registry [RFC2434], this document
       is not intended to require formal IETF review.  Informal review by
       experts may, nevertheless, be valuable.  In other cases (Section 5),
       there is a well-specified procedure for extensions that should be
       followed.

       The only safe rule is that, even if an extension appears minor to the
       person proposing it, early review by subject matter experts is
       advisable.  For protocols that have been developed in the IETF, the
       appropriate forum for such review is the IETF, either in the relevant
       WG or Area, or by individual IETF experts if no such WG exists.

    3.4.  Quality and Consistency

       In order to be adequately reviewed by relevant experts, a proposed
       extension must be documented in a clear and well-written
       specification that IETF subject matter experts have access to and can
       review.  Ideally, such a document would be published as an Internet
       Draft, using terminology and content that is sufficiently consistent
       with the unextended specification that these experts can readily
       identify the technical changes proposed at an early stage.

    3.5.  The Role of Formal Liaisons

       The IETF has formal liaisons in place with a number of SDOs;
       documentation of the liaison process is in [RFC4052], [RFC4053], and
       [RFC4691].  These liaison channels should be used as relevant for
       discussing and reviewing extensions, as should informal communication
       at the engineering level (for example, experts from other SDOs are
       welcome to participate in IETF meetings and mailing lists).  Where
       formal liaison does not exist, the point of contact in the IETF
       should be the Chairs of relevant WGs, the most appropriate Area
       Director, or, in case of doubt, the IESG as a whole.

    Bradner, et al.          Best Current Practice                  [Page 6]

    RFC 4775           Procedures for Protocol Extensions      December 2006

    4.  Procedure for Review of Extensions

       In some cases, explicit provision is made in the relevant RFCs for
       extending individual IETF protocols.  Nothing in this document
       overrides such procedures.  Some such cases are mentioned in
       Section 5.

       There are several ways in which an extension to an IETF protocol can
       be considered for publication as an RFC:

       1.  Extensions to IETF protocols developed within the IETF will be
           subject to the normal IETF process, exactly like new designs.  It
           is not suggested that this is a panacea; appropriate cross-
           working-group and cross-area review is needed within the IETF to
           avoid oversights and mistakes.

       2.  Extensions to IETF protocols discussed in an IRTF Research Group
           may well be the prelude to regular IETF discussion.  However, a
           Research Group may desire to specify an experimental extension
           before the work is mature enough for IETF processing.  In this
           case, the Research Group is required to involve appropriate IETF
           or IANA experts in their process to avoid oversights.

       3.  Extensions to IETF protocols described in Independent Submissions
           to the RFC Editor are subject to IESG review, currently described
           in BCP 92 [RFC3932].  If appropriate, the IESG advises the RFC
           Editor that full IETF processing is needed, or that relevant IANA
           procedures need to be followed before publication can proceed.
           Note that Independent Submissions cannot be placed on the IETF
           Standards Track; they would need to enter full IETF processing.

       Where vendors or other SDOs identify a requirement for extending an
       IETF protocol, their first step should be to consider the scenarios
       listed in Section 1.  If the requirement is straightforward and
       within the scope of a documented extension mechanism, the way is
       clear, and the documented mechanism must be followed.  If these two
       conditions are not met, the next step should be to contact the
       relevant IETF Area Director to check whether there is an active WG in
       the area or, at least, relevant expertise available in the IETF.  At
       this point, it will be possible to select the most appropriate of the
       above three routes.  Regular IETF process is most likely to be
       suitable, assuming sufficient interest can be found in the IETF
       community.  IRTF process is unlikely to be suitable unless there is a
       genuine research context for the proposed extension.

    Bradner, et al.          Best Current Practice                  [Page 7]

    RFC 4775           Procedures for Protocol Extensions      December 2006

       In the event that the IETF no longer has relevant expertise, there
       are still two choices to discuss with the Area Director: bring the
       work to the IETF (i.e., the IETF imports expertise) or reach mutual
       agreement to do the work elsewhere (i.e., the IETF explicitly exports
       change control).

       In the case of an SDO that identifies a requirement for a
       standardized extension, a standards development process within the
       IETF (while maintaining appropriate liaison) is strongly recommended
       in preference to publishing a non-IETF standard.  Otherwise, the
       implementor community will be faced with a standard split into two or
       more parts in different styles, obtained from different sources, with
       no unitary control over quality, compatibility, interoperability, and
       intellectual property conditions.  Note that, since participation in
       the IETF is open, there is no formality or restriction for
       participants in other SDOs choosing to work in the IETF as well.  In
       some cases (see Section 5), the IETF has well-defined procedures for
       this in place.

       Naturally, SDOs can and do develop scenarios, requirements, and
       architectures based on IETF specifications.  It is only actual
       protocol extensions and changes that need to go through the IETF
       process.  However, there is large risk of wasted effort if
       significant investment is made in planning stages for use of IETF
       technology without early review and feedback from the IETF.  Other
       SDOs are encouraged to communicate informally or formally with the
       IETF as early as possible, to avoid false starts.  Early technical
       review in a collaborative spirit is of great value.  Each SDO can
       "own" its ideas and discuss them in its own fora, but should start
       talking to the IETF experts about those ideas the moment the idea is
       well formulated.  It is understood that close collaboration may be
       needed in order that the IETF experts correctly understand the
       systems architecture envisaged by the other SDO.  This is much
       preferable to a situation where another SDO presents the IANA and the
       IETF with a 'fait accompli.'

       Vendors that identify a requirement for an extension are strongly
       recommended to start informal discussion in the IETF and to publish a
       preliminary Internet Draft describing the requirements.  This will
       allow the vendor, and the community, to evaluate whether there is
       community interest and whether there are any major or fundamental
       issues.  However, in the case of a vendor that identifies a
       requirement for a proprietary extension that does not generate
       interest in the IETF (or IRTF) communities, an Independent Submission
       to the RFC Editor is strongly recommended in preference to publishing
       a proprietary document.  Not only does this bring the draft to the

    Bradner, et al.          Best Current Practice                  [Page 8]

    RFC 4775           Procedures for Protocol Extensions      December 2006

       attention of the community, but it also ensures a minimum of review
       [RFC3932], and (if published as an RFC) makes the proprietary
       extension available to the whole community.

       If, despite these recommendations, a vendor or SDO does choose to
       publish its own specification for an extension to an IETF protocol,
       the following guidance applies:

       o  Extensions to IETF protocols should be well, and publicly,
          documented, and reviewed at an early stage by the IETF community
          to be sure that the extension does not undermine basic assumptions
          and safeguards designed into the protocol (such as security
          functions) or its architectural integrity.

       o  Vendors and other SDOs are formally requested to submit any such
          proposed publications for IETF review, and are invited to actively
          participate in the IETF process.  Submission may be by an
          established liaison channel if it exists, or by direct
          communication with the relevant WG or the IESG.  This should be
          done at an early stage, before a large investment of effort has
          taken place, in case basic problems are revealed.  When there is a
          formal liaison in place between the other SDO and the IETF, the
          liaison channel should be used to ensure that review takes place,
          both by relevant experts and by established review teams or
          Directorates within the IETF.  If there is no formal liaison, the
          other SDO or vendor should ask the IESG (or a relevant Area
          Director) to obtain such reviews.  Note that general aspects such
          as security, internationalization, and management may need review,
          as well as the protocol as such.

       o  In the case of extensions involving only routine IANA parameter
          assignments, for which there is an underlying IETF specification
          containing clear IANA Considerations, this request is satisfied as
          long as those considerations are satisfied (see [RFC2434]).
          Anything beyond this requires an explicit protocol review by
          experts within the IETF.

       o  Note that, like IETF specifications, such proposed publications
          must include an IANA Considerations section to ensure that
          protocol parameter assignments that are needed to deploy
          extensions are not made until after a proposed extension has
          received adequate review, and then to ensure that IANA has precise
          guidance on how to make those assignments.

    Bradner, et al.          Best Current Practice                  [Page 9]

    RFC 4775           Procedures for Protocol Extensions      December 2006

    5.  Some Specific Issues

       It is relatively common for MIB modules, which are all, in effect,
       extensions of the SMI data model, to be defined or extended outside
       the IETF.  BCP 111 [RFC4181] offers detailed guidance for authors and
       reviewers.

       A number of protocols have foreseen experimental values for certain
       IANA parameters, so that experimental usages and extensions may be
       tested without need for a special parameter assignment.  It must be
       stressed that such values are not intended for production use or as a
       way to evade the type of technical review described in this document.
       See [RFC3692] and [RFC4727].

       RADIUS [RFC2865] is designed to carry attributes and allow definition
       of new attributes.  But it is important that discussion of new
       attributes involve the IETF community of experts knowledgeable about
       the protocol's architecture and existing usage in order to fully
       understand the implications of a proposed extension.  Adding new
       attributes without such discussion creates a high risk of
       interoperability or functionality failure.  For this reason among
       others, the IETF has an active RADIUS Extensions WG at the time of
       writing.

       There are certain documents that specify a change process for
       specific IETF protocols, such as:
          The SIP change process [RFC3427]
          The (G)MPLS change process [CHANGEPROC]

       This document does not override such specific change processes.

    6.  Intellectual Property

       All IETF documents fall under the IETF's intellectual property rules,
       BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended.  In particular,
       there are restrictions on the production of derivative works, and
       there are rights that remain with the original authors.  Anybody
       outside the IETF considering an extension based on an IETF document
       must bear these legal restrictions and rights in mind.

    7.  Security Considerations

       An extension must not introduce new security risks without also
       providing an adequate counter-measure, and in particular it must not
       inadvertently defeat security measures in the unextended protocol.
       This aspect must always be considered during IETF review.

    Bradner, et al.          Best Current Practice                 [Page 10]

    RFC 4775           Procedures for Protocol Extensions      December 2006

    8.  IANA Considerations

       The IETF requests IANA to pay attention to the requirements of this
       document when requested to make protocol parameter assignments for
       vendors or other SDOs, i.e., to respect the IANA Considerations of
       all RFCs that contain them, and the general considerations of BCP 26
       [RFC2434].

    9.  Acknowledgements

       This document is heavily based on an earlier draft under a different
       title by Scott Bradner and Thomas Narten.

       That earlier draft stated: The initial version of this document was
       put together by the IESG in 2002.  Since then, it has been reworked
       in response to feedback from John Loughney, Henrik Levkowetz, Mark
       Townsley, Randy Bush, Bernard Aboba, and others.

       Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson,
       Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn
       Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments
       on this document.

       Sam Hartman contributed the section on interoperability.

       This document was produced using the xml2rfc tool [RFC2629].

    10.  References

    10.1.  Normative References

       [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                    3", BCP 9, RFC 2026, October 1996.

       [RFC2434]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
                    IANA Considerations Section in RFCs", BCP 26, RFC 2434,
                    October 1998.

       [RFC3427]    Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
                    and B. Rosen, "Change Process for the Session Initiation
                    Protocol (SIP)", BCP 67, RFC 3427, December 2002.

       [RFC3692]    Narten, T., "Assigning Experimental and Testing Numbers
                    Considered Useful", BCP 82, RFC 3692, January 2004.

       [RFC3932]    Alvestrand, H., "The IESG and RFC Editor Documents:
                    Procedures", BCP 92, RFC 3932, October 2004.

    Bradner, et al.          Best Current Practice                 [Page 11]

    RFC 4775           Procedures for Protocol Extensions      December 2006

       [RFC3935]    Alvestrand, H., "A Mission Statement for the IETF",
                    BCP 95, RFC 3935, October 2004.

       [RFC3978]    Bradner, S., "IETF Rights in Contributions", BCP 78,
                    RFC 3978, March 2005.

       [RFC3979]    Bradner, S., "Intellectual Property Rights in IETF
                    Technology", BCP 79, RFC 3979, March 2005.

       [RFC4052]    Daigle, L. and Internet Architecture Board, "IAB
                    Processes for Management of IETF Liaison Relationships",
                    BCP 102, RFC 4052, April 2005.

       [RFC4053]    Trowbridge, S., Bradner, S., and F.  Baker, "Procedures
                    for Handling Liaison Statements to and from the IETF",
                    BCP 103, RFC 4053, April 2005.

       [RFC4181]    Heard, C., "Guidelines for Authors and Reviewers of MIB
                    Documents", BCP 111, RFC 4181, September 2005.

       [RFC4727]    Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
                    ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.

    10.2.  Informative References

       [CHANGEPROC] Andersson, L. and A. Farrel, "Change Process for
                    Multiprotocol Label Switching (MPLS) and Generalized
                    MPLS  (GMPLS) Protocols and Procedures", Work in
                    Progress, October 2006.

       [RFC2629]    Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
                    June 1999.

       [RFC2865]    Rigney, C., Willens, S., Rubens, A., and W. Simpson,
                    "Remote Authentication Dial In User Service (RADIUS)",
                    RFC 2865, June 2000.

       [RFC4691]    Andersson, L., "Guidelines for Acting as an IETF Liaison
                    to Another Organization", RFC 4691, October 2006.

    Bradner, et al.          Best Current Practice                 [Page 12]

    RFC 4775           Procedures for Protocol Extensions      December 2006

    Authors' Addresses

       Scott Bradner
       Harvard University
       29 Oxford St.
       Cambridge, MA  02138
       US

       EMail: sob@harvard.edu

       Brian Carpenter, Ed.
       IBM
       8 Chemin de Blandonnet
       1214 Vernier
       Switzerland

       EMail: brc@zurich.ibm.com

       Thomas Narten
       IBM
       3039 Cornwallis Ave.
       PO Box 12195 - BRQA/502
       Research Triangle Park, NC  27709-2195
       US

       EMail: narten@us.ibm.com

    Bradner, et al.          Best Current Practice                 [Page 13]

    RFC 4775           Procedures for Protocol Extensions      December 2006

    Full Copyright Statement

       Copyright (C) The IETF Trust (2006).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

       This document and the information contained herein are provided on an
       "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
       OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
       AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
       EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
       THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
       IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
       PURPOSE.

    Intellectual Property

       The IETF takes no position regarding the validity or scope of any
       Intellectual Property Rights or other rights that might be claimed to
       pertain to the implementation or use of the technology described in
       this document or the extent to which any license under such rights
       might or might not be available; nor does it represent that it has
       made any independent effort to identify any such rights.  Information
       on the procedures with respect to rights in RFC documents can be
       found in BCP 78 and BCP 79.

       Copies of IPR disclosures made to the IETF Secretariat and any
       assurances of licenses to be made available, or the result of an
       attempt made to obtain a general license or permission for the use of
       such proprietary rights by implementers or users of this
       specification can be obtained from the IETF on-line IPR repository at
       http://www.ietf.org/ipr.

       The IETF invites any interested party to bring to its attention any
       copyrights, patents or patent applications, or other proprietary
       rights that may cover technology that may be required to implement
       this standard.  Please address the information to the IETF at
       ietf-ipr@ietf.org.

    Acknowledgement

       Funding for the RFC Editor function is currently provided by the
       Internet Society.

    Bradner, et al.          Best Current Practice                 [Page 14]