doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc2026.txt b/doc/rfc/rfc2026.txt
new file mode 100644
index 0000000..1c9c59a
--- /dev/null
+++ b/doc/rfc/rfc2026.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 2026                            Harvard University
+BCP: 9                                                      October 1996
+Obsoletes: 1602
+Category: Best Current Practice
+
+
+              The Internet Standards Process -- Revision 3
+
+
+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.
+
+Abstract
+
+   This memo documents the process used by the Internet community for
+   the standardization of protocols and procedures.  It defines the
+   stages in the standardization process, the requirements for moving a
+   document between stages and the types of documents used during this
+   process.  It also addresses the intellectual property rights and
+   copyright issues associated with the standards process.
+
+Table of Contents
+
+   1.  INTRODUCTION....................................................2
+     1.1  Internet Standards...........................................3
+     1.2  The Internet Standards Process...............................3
+     1.3  Organization of This Document................................5
+   2.  INTERNET STANDARDS-RELATED PUBLICATIONS.........................5
+     2.1  Requests for Comments (RFCs).................................5
+     2.2  Internet-Drafts..............................................7
+   3.  INTERNET STANDARD SPECIFICATIONS................................8
+     3.1  Technical Specification (TS).................................8
+     3.2  Applicability Statement (AS).................................8
+     3.3  Requirement Levels...........................................9
+   4.  THE INTERNET STANDARDS TRACK...................................10
+     4.1  Standards Track Maturity Levels.............................11
+       4.1.1  Proposed Standard.......................................11
+       4.1.2  Draft Standard..........................................12
+       4.1.3  Internet Standard.......................................13
+     4.2  Non-Standards Track Maturity Levels.........................13
+       4.2.1  Experimental............................................13
+       4.2.2  Informational...........................................14
+       4.2.3  Procedures for Experimental and Informational RFCs......14
+       4.2.4  Historic................................................15
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   5.  Best Current Practice (BCP) RFCs...............................15
+     5.1  BCP Review Process..........................................16
+   6.  THE INTERNET STANDARDS PROCESS.................................17
+     6.1  Standards Actions...........................................17
+       6.1.1  Initiation of Action....................................17
+       6.1.2  IESG Review and Approval................................17
+       6.1.3  Publication.............................................18
+     6.2  Advancing in the Standards Track............................19
+     6.3  Revising a Standard.........................................20
+     6.4  Retiring a Standard.........................................20
+     6.5  Conflict Resolution and Appeals.............................21
+       6.5.1 Working Group Disputes...................................21
+       6.5.2 Process Failures.........................................22
+       6.5.3 Questions of Applicable Procedure........................22
+       6.5.4 Appeals Procedure........................................23
+   7.  EXTERNAL STANDARDS AND SPECIFICATIONS..........................23
+     7.1  Use of External Specifications..............................24
+       7.1.1  Incorporation of an Open Standard.......................24
+       7.1.2  Incorporation of a Other Specifications.................24
+       7.1.3  Assumption..............................................25
+   8. NOTICES AND RECORD KEEPING......................................25
+   9. VARYING THE PROCESS.............................................26
+     9.1 The Variance Procedure.......................................26
+     9.2 Exclusions...................................................27
+   10.  INTELLECTUAL PROPERTY RIGHTS..................................27
+     10.1.  General Policy............................................27
+     10.2   Confidentiality Obligations...............................28
+     10.3.  Rights and Permissions....................................28
+       10.3.1. All Contributions......................................28
+       10.3.2. Standards Track Documents..............................29
+       10.3.3  Determination of Reasonable and
+              Non-discriminatory Terms................................30
+     10.4.  Notices...................................................30
+   11. ACKNOWLEDGMENTS................................................32
+   12. SECURITY CONSIDERATIONS........................................32
+   13. REFERENCES.....................................................33
+   14. DEFINITIONS OF TERMS...........................................33
+   15. AUTHOR'S ADDRESS...............................................34
+   APPENDIX A: GLOSSARY OF ACRONYMS...................................35
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+1.  INTRODUCTION
+
+   This memo documents the process currently used by the Internet
+   community for the standardization of protocols and procedures.  The
+   Internet Standards process is an activity of the Internet Society
+   that is organized and managed on behalf of the Internet community by
+   the Internet Architecture Board (IAB) and the Internet Engineering
+   Steering Group (IESG).
+
+1.1  Internet Standards
+
+   The Internet, a loosely-organized international collaboration of
+   autonomous, interconnected networks, supports host-to-host
+   communication through voluntary adherence to open protocols and
+   procedures defined by Internet Standards.  There are also many
+   isolated interconnected networks, which are not connected to the
+   global Internet but use the Internet Standards.
+
+   The Internet Standards Process described in this document is
+   concerned with all protocols, procedures, and conventions that are
+   used in or by the Internet, whether or not they are part of the
+   TCP/IP protocol suite.  In the case of protocols developed and/or
+   standardized by non-Internet organizations, however, the Internet
+   Standards Process normally applies to the application of the protocol
+   or procedure in the Internet context, not to the specification of the
+   protocol itself.
+
+   In general, an Internet Standard is a specification that is stable
+   and well-understood, is technically competent, has multiple,
+   independent, and interoperable implementations with substantial
+   operational experience, enjoys significant public support, and is
+   recognizably useful in some or all parts of the Internet.
+
+1.2  The Internet Standards Process
+
+   In outline, the process of creating an Internet Standard is
+   straightforward:  a specification undergoes a period of development
+   and several iterations of review by the Internet community and
+   revision based upon experience, is adopted as a Standard by the
+   appropriate body (see below), and is published.  In practice, the
+   process is more complicated, due to (1) the difficulty of creating
+   specifications of high technical quality;  (2) the need to consider
+   the interests of all of the affected parties;  (3) the importance of
+   establishing widespread community consensus;  and (4) the difficulty
+   of evaluating the utility of a particular specification for the
+   Internet community.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   The goals of the Internet Standards Process are:
+   o  technical excellence;
+   o  prior implementation and testing;
+   o  clear, concise, and easily understood documentation;
+   o  openness and fairness;  and
+   o  timeliness.
+
+   The procedures described in this document are designed to be fair,
+   open, and objective;  to reflect existing (proven) practice;  and to
+   be flexible.
+
+   o  These procedures are intended to provide a fair, open, and
+      objective basis for developing, evaluating, and adopting Internet
+      Standards.  They provide ample opportunity for participation and
+      comment by all interested parties.  At each stage of the
+      standardization process, a specification is repeatedly discussed
+      and its merits debated in open meetings and/or public electronic
+      mailing lists, and it is made available for review via world-wide
+      on-line directories.
+
+   o  These procedures are explicitly aimed at recognizing and adopting
+      generally-accepted practices.  Thus, a candidate specification
+      must be implemented and tested for correct operation and
+      interoperability by multiple independent parties and utilized in
+      increasingly demanding environments, before it can be adopted as
+      an Internet Standard.
+
+   o  These procedures provide a great deal of flexibility to adapt to
+      the wide variety of circumstances that occur in the
+      standardization process.  Experience has shown this flexibility to
+      be vital in achieving the goals listed above.
+
+   The goal of technical competence, the requirement for prior
+   implementation and testing, and the need to allow all interested
+   parties to comment all require significant time and effort.  On the
+   other hand, today's rapid development of networking technology
+   demands timely development of standards.  The Internet Standards
+   Process is intended to balance these conflicting goals.  The process
+   is believed to be as short and simple as possible without sacrificing
+   technical excellence, thorough testing before adoption of a standard,
+   or openness and fairness.
+
+   From its inception, the Internet has been, and is expected to remain,
+   an evolving system whose participants regularly factor new
+   requirements and technology into its design and implementation. Users
+   of the Internet and providers of the equipment, software, and
+   services that support it should anticipate and embrace this evolution
+   as a major tenet of Internet philosophy.
+
+
+
+Bradner                  Best Current Practice                  [Page 4]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   The procedures described in this document are the result of a number
+   of years of evolution, driven both by the needs of the growing and
+   increasingly diverse Internet community, and by experience.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 5]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+1.3  Organization of This Document
+
+   Section 2 describes the publications and archives of the Internet
+   Standards Process.  Section 3 describes the types of Internet
+   standard specifications.  Section 4 describes the Internet standards
+   specifications track.  Section 5 describes Best Current Practice
+   RFCs.  Section 6 describes the process and rules for Internet
+   standardization.  Section 7 specifies the way in which externally-
+   sponsored specifications and practices, developed and controlled by
+   other standards bodies or by others, are handled within the Internet
+   Standards Process.  Section 8 describes the requirements for notices
+   and record keeping  Section 9 defines a variance process to allow
+   one-time exceptions to some of the requirements in this document
+   Section 10 presents the rules that are required to protect
+   intellectual property rights in the context of the development and
+   use of Internet Standards.  Section 11 includes acknowledgments of
+   some of the people involved in creation of this document.  Section 12
+   notes that security issues are not dealt with by this document.
+   Section 13 contains a list of numbered references.  Section 14
+   contains definitions of some of the terms used in this document.
+   Section 15 lists the author's email and postal addresses.  Appendix A
+   contains a list of frequently-used acronyms.
+
+2.  INTERNET STANDARDS-RELATED PUBLICATIONS
+
+2.1  Requests for Comments (RFCs)
+
+   Each distinct version of an Internet standards-related specification
+   is published as part of the "Request for Comments" (RFC) document
+   series.  This archival series is the official publication channel for
+   Internet standards documents and other publications of the IESG, IAB,
+   and Internet community.  RFCs can be obtained from a number of
+   Internet hosts using anonymous FTP, gopher, World Wide Web, and other
+   Internet document-retrieval systems.
+
+   The RFC series of documents on networking began in 1969 as part of
+   the original ARPA wide-area networking (ARPANET) project (see
+   Appendix A for glossary of acronyms).  RFCs cover a wide range of
+   topics in addition to Internet Standards, from early discussion of
+   new research concepts to status memos about the Internet.  RFC
+   publication is the direct responsibility of the RFC Editor, under the
+   general direction of the IAB.
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 6]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   The rules for formatting and submitting an RFC are defined in [5].
+   Every RFC is available in ASCII text.  Some RFCs are also available
+   in other formats.  The other versions of an RFC may contain material
+   (such as diagrams and figures) that is not present in the ASCII
+   version, and it may be formatted differently.
+
+      *********************************************************
+      *                                                       *
+      *  A stricter requirement applies to standards-track    *
+      *  specifications:  the ASCII text version is the       *
+      *  definitive reference, and therefore it must be a     *
+      *  complete and accurate specification of the standard, *
+      *  including all necessary diagrams and illustrations.  *
+      *                                                       *
+      *********************************************************
+
+   The status of Internet protocol and service specifications is
+   summarized periodically in an RFC entitled "Internet Official
+   Protocol Standards" [1].  This RFC shows the level of maturity and
+   other helpful information for each Internet protocol or service
+   specification (see section 3).
+
+   Some RFCs document Internet Standards.  These RFCs form the 'STD'
+   subseries of the RFC series [4].  When a specification has been
+   adopted as an Internet Standard, it is given the additional label
+   "STDxxx", but it keeps its RFC number and its place in the RFC
+   series. (see section 4.1.3)
+
+   Some RFCs standardize the results of community deliberations about
+   statements of principle or conclusions about what is the best way to
+   perform some operations or IETF process function.  These RFCs form
+   the specification has been adopted as a BCP, it is given the
+   additional label "BCPxxx", but it keeps its RFC number and its place
+   in the RFC series. (see section 5)
+
+   Not all specifications of protocols or services for the Internet
+   should or will become Internet Standards or BCPs.  Such non-standards
+   track specifications are not subject to the rules for Internet
+   standardization.  Non-standards track specifications may be published
+   directly as "Experimental" or "Informational" RFCs at the discretion
+   of the RFC Editor in consultation with the IESG (see section 4.2).
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 7]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+      ********************************************************
+      *                                                      *
+      *   It is important to remember that not all RFCs      *
+      *   are standards track documents, and that not all    *
+      *   standards track documents reach the level of       *
+      *   Internet Standard. In the same way, not all RFCs   *
+      *   which describe current practices have been given   *
+      *   the review and approval to become BCPs. See        *
+      *   RFC-1796 [6] for further information.              *
+      *                                                      *
+      ********************************************************
+
+2.2  Internet-Drafts
+
+   During the development of a specification, draft versions of the
+   document are made available for informal review and comment by
+   placing them in the IETF's "Internet-Drafts" directory, which is
+   replicated on a number of Internet hosts.  This makes an evolving
+   working document readily available to a wide audience, facilitating
+   the process of review and revision.
+
+   An Internet-Draft that is published as an RFC, or that has remained
+   unchanged in the Internet-Drafts directory for more than six months
+   without being recommended by the IESG for publication as an RFC, is
+   simply removed from the Internet-Drafts directory.  At any time, an
+   Internet-Draft may be replaced by a more recent version of the same
+   specification, restarting the six-month timeout period.
+
+   An Internet-Draft is NOT a means of "publishing" a specification;
+   specifications are published through the RFC mechanism described in
+   the previous section.  Internet-Drafts have no formal status, and are
+   subject to change or removal at any time.
+
+      ********************************************************
+      *                                                      *
+      *   Under no circumstances should an Internet-Draft    *
+      *   be referenced by any paper, report, or Request-    *
+      *   for-Proposal, nor should a vendor claim compliance *
+      *   with an Internet-Draft.                            *
+      *                                                      *
+      ********************************************************
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 8]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   Note: It is acceptable to reference a standards-track specification
+   that may reasonably be expected to be published as an RFC using the
+   phrase "Work in Progress"  without referencing an Internet-Draft.
+   This may also be done in a standards track document itself  as long
+   as the specification in which the reference is made would stand as a
+   complete and understandable document with or without the reference to
+   the "Work in Progress".
+
+3.  INTERNET STANDARD SPECIFICATIONS
+
+   Specifications subject to the Internet Standards Process fall into
+   one of two categories:  Technical Specification (TS) and
+   Applicability Statement (AS).
+
+3.1  Technical Specification (TS)
+
+   A Technical Specification is any description of a protocol, service,
+   procedure, convention, or format.  It may completely describe all of
+   the relevant aspects of its subject, or it may leave one or more
+   parameters or options unspecified.  A TS may be completely self-
+   contained, or it may incorporate material from other specifications
+   by reference to other documents (which might or might not be Internet
+   Standards).
+
+   A TS shall include a statement of its scope and the general intent
+   for its use (domain of applicability).  Thus, a TS that is inherently
+   specific to a particular context shall contain a statement to that
+   effect.  However, a TS does not specify requirements for its use
+   within the Internet;  these requirements, which depend on the
+   particular context in which the TS is incorporated by different
+   system configurations, are defined by an Applicability Statement.
+
+3.2  Applicability Statement (AS)
+
+   An Applicability Statement specifies how, and under what
+   circumstances, one or more TSs may be applied to support a particular
+   Internet capability.  An AS may specify uses for TSs that are not
+   Internet Standards, as discussed in Section 7.
+
+   An AS identifies the relevant TSs and the specific way in which they
+   are to be combined, and may also specify particular values or ranges
+   of TS parameters or subfunctions of a TS protocol that must be
+   implemented.  An AS also specifies the circumstances in which the use
+   of a particular TS is required, recommended, or elective (see section
+   3.3).
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 9]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   An AS may describe particular methods of using a TS in a restricted
+   "domain of applicability", such as Internet routers, terminal
+   servers, Internet systems that interface to Ethernets, or datagram-
+   based database servers.
+
+   The broadest type of AS is a comprehensive conformance specification,
+   commonly called a "requirements document", for a particular class of
+   Internet systems, such as Internet routers or Internet hosts.
+
+   An AS may not have a higher maturity level in the standards track
+   than any standards-track TS on which the AS relies (see section 4.1).
+   For example, a TS at Draft Standard level may be referenced by an AS
+   at the Proposed Standard or Draft Standard level, but not by an AS at
+   the Standard level.
+
+3.3  Requirement Levels
+
+   An AS shall apply one of the following "requirement levels" to each
+   of the TSs to which it refers:
+
+   (a)  Required:  Implementation of the referenced TS, as specified by
+      the AS, is required to achieve minimal conformance.  For example,
+      IP and ICMP must be implemented by all Internet systems using the
+      TCP/IP Protocol Suite.
+
+   (b)  Recommended:  Implementation of the referenced TS is not
+      required for minimal conformance, but experience and/or generally
+      accepted technical wisdom suggest its desirability in the domain
+      of applicability of the AS.  Vendors are strongly encouraged to
+      include the functions, features, and protocols of Recommended TSs
+      in their products, and should omit them only if the omission is
+      justified by some special circumstance. For example, the TELNET
+      protocol should be implemented by all systems that would benefit
+      from remote access.
+
+   (c)  Elective:  Implementation of the referenced TS is optional
+      within the domain of applicability of the AS;  that is, the AS
+      creates no explicit necessity to apply the TS.  However, a
+      particular vendor may decide to implement it, or a particular user
+      may decide that it is a necessity in a specific environment.  For
+      example, the DECNET MIB could be seen as valuable in an
+      environment where the DECNET protocol is used.
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 10]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+      As noted in section 4.1, there are TSs that are not in the
+      standards track or that have been retired from the standards
+      track, and are therefore not required, recommended, or elective.
+      Two additional "requirement level" designations are available for
+      these TSs:
+
+   (d)  Limited Use:  The TS is considered to be appropriate for use
+      only in limited or unique circumstances.  For example, the usage
+      of a protocol with the "Experimental" designation should generally
+      be limited to those actively involved with the experiment.
+
+   (e)  Not Recommended:  A TS that is considered to be inappropriate
+      for general use is labeled "Not Recommended". This may be because
+      of its limited functionality, specialized nature, or historic
+      status.
+
+   Although TSs and ASs are conceptually separate, in practice a
+   standards-track document may combine an AS and one or more related
+   TSs.  For example, Technical Specifications that are developed
+   specifically and exclusively for some particular domain of
+   applicability, e.g., for mail server hosts, often contain within a
+   single specification all of the relevant AS and TS information. In
+   such cases, no useful purpose would be served by deliberately
+   distributing the information among several documents just to preserve
+   the formal AS/TS distinction.  However, a TS that is likely to apply
+   to more than one domain of applicability should be developed in a
+   modular fashion, to facilitate its incorporation by multiple ASs.
+
+   The "Official Protocol Standards" RFC (STD1) lists a general
+   requirement level for each TS, using the nomenclature defined in this
+   section. This RFC is updated periodically.  In many cases, more
+   detailed descriptions of the requirement levels of particular
+   protocols and of individual features of the protocols will be found
+   in appropriate ASs.
+
+4.  THE INTERNET STANDARDS TRACK
+
+   Specifications that are intended to become Internet Standards evolve
+   through a set of maturity levels known as the "standards track".
+   These maturity levels -- "Proposed Standard", "Draft Standard", and
+   "Standard" -- are defined and discussed in section 4.1.  The way in
+   which specifications move along the standards track is described in
+   section 6.
+
+   Even after a specification has been adopted as an Internet Standard,
+   further evolution often occurs based on experience and the
+   recognition of new requirements.  The nomenclature and procedures of
+   Internet standardization provide for the replacement of old Internet
+
+
+
+Bradner                  Best Current Practice                 [Page 11]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   Standards with new ones, and the assignment of descriptive labels to
+   indicate the status of "retired" Internet Standards.  A set of
+   maturity levels is defined in section 4.2 to cover these and other
+   specifications that are not considered to be on the standards track.
+
+4.1  Standards Track Maturity Levels
+
+   Internet specifications go through stages of development, testing,
+   and acceptance.  Within the Internet Standards Process, these stages
+   are formally labeled "maturity levels".
+
+   This section describes the maturity levels and the expected
+   characteristics of specifications at each level.
+
+4.1.1  Proposed Standard
+
+   The entry-level maturity for the standards track is "Proposed
+   Standard".  A specific action by the IESG is required to move a
+   specification onto the standards track at the "Proposed Standard"
+   level.
+
+   A Proposed Standard specification is generally stable, has resolved
+   known design choices, is believed to be well-understood, has received
+   significant community review, and appears to enjoy enough community
+   interest to be considered valuable.  However, further experience
+   might result in a change or even retraction of the specification
+   before it advances.
+
+   Usually, neither implementation nor operational experience is
+   required for the designation of a specification as a Proposed
+   Standard.  However, such experience is highly desirable, and will
+   usually represent a strong argument in favor of a Proposed Standard
+   designation.
+
+   The IESG may require implementation and/or operational experience
+   prior to granting Proposed Standard status to a specification that
+   materially affects the core Internet protocols or that specifies
+   behavior that may have significant operational impact on the
+   Internet.
+
+   A Proposed Standard should have no known technical omissions with
+   respect to the requirements placed upon it.  However, the IESG may
+   waive this requirement in order to allow a specification to advance
+   to the Proposed Standard state when it is considered to be useful and
+   necessary (and timely) even with known technical omissions.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 12]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   Implementors should treat Proposed Standards as immature
+   specifications.  It is desirable to implement them in order to gain
+   experience and to validate, test, and clarify the specification.
+   However, since the content of Proposed Standards may be changed if
+   problems are found or better solutions are identified, deploying
+   implementations of such standards into a disruption-sensitive
+   environment is not recommended.
+
+4.1.2  Draft Standard
+
+   A specification from which at least two independent and interoperable
+   implementations from different code bases have been developed, and
+   for which sufficient successful operational experience has been
+   obtained, may be elevated to the "Draft Standard" level.  For the
+   purposes of this section, "interoperable" means to be functionally
+   equivalent or interchangeable components of the system or process in
+   which they are used.  If patented or otherwise controlled technology
+   is required for implementation, the separate implementations must
+   also have resulted from separate exercise of the licensing process.
+   Elevation to Draft Standard is a major advance in status, indicating
+   a strong belief that the specification is mature and will be useful.
+
+   The requirement for at least two independent and interoperable
+   implementations applies to all of the options and features of the
+   specification.  In cases in which one or more options or features
+   have not been demonstrated in at least two interoperable
+   implementations, the specification may advance to the Draft Standard
+   level only if those options or features are removed.
+
+   The Working Group chair is responsible for documenting the specific
+   implementations which qualify the specification for Draft or Internet
+   Standard status along with documentation about testing of the
+   interoperation of these implementations.  The documentation must
+   include information about the support of each of the individual
+   options and features.  This documentation should be submitted to the
+   Area Director with the protocol action request. (see Section 6)
+
+   A Draft Standard must be well-understood and known to be quite
+   stable, both in its semantics and as a basis for developing an
+   implementation.  A Draft Standard may still require additional or
+   more widespread field experience, since it is possible for
+   implementations based on Draft Standard specifications to demonstrate
+   unforeseen behavior when subjected to large-scale use in production
+   environments.
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 13]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   A Draft Standard is normally considered to be a final specification,
+   and changes are likely to be made only to solve specific problems
+   encountered.  In most circumstances, it is reasonable for vendors to
+   deploy implementations of Draft Standards into a disruption sensitive
+   environment.
+
+4.1.3  Internet Standard
+
+   A specification for which significant implementation and successful
+   operational experience has been obtained may be elevated to the
+   Internet Standard level.  An Internet Standard (which may simply be
+   referred to as a Standard) is characterized by a high degree of
+   technical maturity and by a generally held belief that the specified
+   protocol or service provides significant benefit to the Internet
+   community.
+
+   A specification that reaches the status of Standard is assigned a
+   number in the STD series while retaining its RFC number.
+
+4.2  Non-Standards Track Maturity Levels
+
+   Not every specification is on the standards track.  A specification
+   may not be intended to be an Internet Standard, or it may be intended
+   for eventual standardization but not yet ready to enter the standards
+   track.  A specification may have been superseded by a more recent
+   Internet Standard, or have otherwise fallen into disuse or disfavor.
+
+   Specifications that are not on the standards track are labeled with
+   one of three "off-track" maturity levels:  "Experimental",
+   "Informational", or "Historic".  The documents bearing these labels
+   are not Internet Standards in any sense.
+
+4.2.1  Experimental
+
+   The "Experimental" designation typically denotes a specification that
+   is part of some research or development effort.  Such a specification
+   is published for the general information of the Internet technical
+   community and as an archival record of the work, subject only to
+   editorial considerations and to verification that there has been
+   adequate coordination with the standards process (see below).  An
+   Experimental specification may be the output of an organized Internet
+   research effort (e.g., a Research Group of the IRTF), an IETF Working
+   Group, or it may be an individual contribution.
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 14]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+4.2.2  Informational
+
+   An "Informational" specification is published for the general
+   information of the Internet community, and does not represent an
+   Internet community consensus or recommendation.  The Informational
+   designation is intended to provide for the timely publication of a
+   very broad range of responsible informational documents from many
+   sources, subject only to editorial considerations and to verification
+   that there has been adequate coordination with the standards process
+   (see section 4.2.3).
+
+   Specifications that have been prepared outside of the Internet
+   community and are not incorporated into the Internet Standards
+   Process by any of the provisions of section 10 may be published as
+   Informational RFCs, with the permission of the owner and the
+   concurrence of the RFC Editor.
+
+4.2.3  Procedures for Experimental and Informational RFCs
+
+   Unless they are the result of IETF Working Group action, documents
+   intended to be published with Experimental or Informational status
+   should be submitted directly to the RFC Editor.  The RFC Editor will
+   publish any such documents as Internet-Drafts which have not already
+   been so published.  In order to differentiate these Internet-Drafts
+   they will be labeled or grouped in the I-D directory so they are
+   easily recognizable.  The RFC Editor will wait two weeks after this
+   publication for comments before proceeding further.  The RFC Editor
+   is expected to exercise his or her judgment concerning the editorial
+   suitability of a document for publication with Experimental or
+   Informational status, and may refuse to publish a document which, in
+   the expert opinion of the RFC Editor, is unrelated to Internet
+   activity or falls below the technical and/or editorial standard for
+   RFCs.
+
+   To ensure that the non-standards track Experimental and Informational
+   designations are not misused to circumvent the Internet Standards
+   Process, the IESG and the RFC Editor have agreed that the RFC Editor
+   will refer to the IESG any document submitted for Experimental or
+   Informational publication which, in the opinion of the RFC Editor,
+   may be related to work being done, or expected to be done, within the
+   IETF community.  The IESG shall review such a referred document
+   within a reasonable period of time, and recommend either that it be
+   published as originally submitted or referred to the IETF as a
+   contribution to the Internet Standards Process.
+
+   If (a) the IESG recommends that the document be brought within the
+   IETF and progressed within the IETF context, but the author declines
+   to do so, or (b) the IESG considers that the document proposes
+
+
+
+Bradner                  Best Current Practice                 [Page 15]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   something that conflicts with, or is actually inimical to, an
+   established IETF effort, the document may still be published as an
+   Experimental or Informational RFC.  In these cases, however, the IESG
+   may insert appropriate "disclaimer" text into the RFC either in or
+   immediately following the "Status of this Memo" section in order to
+   make the circumstances of its publication clear to readers.
+
+   Documents proposed for Experimental and Informational RFCs by IETF
+   Working Groups go through IESG review.  The review is initiated using
+   the process described in section 6.1.1.
+
+4.2.4  Historic
+
+   A specification that has been superseded by a more recent
+   specification or is for any other reason considered to be obsolete is
+   assigned to the "Historic" level.  (Purists have suggested that the
+   word should be "Historical"; however, at this point the use of
+   "Historic" is historical.)
+
+   Note: Standards track specifications normally must not depend on
+   other standards track specifications which are at a lower maturity
+   level or on non standards track specifications other than referenced
+   specifications from other standards bodies.  (See Section 7.)
+
+5.  BEST CURRENT PRACTICE (BCP) RFCs
+
+   The BCP subseries of the RFC series is designed to be a way to
+   standardize practices and the results of community deliberations.  A
+   BCP document is subject to the same basic set of procedures as
+   standards track documents and thus is a vehicle by which the IETF
+   community can define and ratify the community's best current thinking
+   on a statement of principle or on what is believed to be the best way
+   to perform some operations or IETF process function.
+
+   Historically Internet standards have generally been concerned with
+   the technical specifications for hardware and software required for
+   computer communication across interconnected networks.  However,
+   since the Internet itself is composed of networks operated by a great
+   variety of organizations, with diverse goals and rules, good user
+   service requires that the operators and administrators of the
+   Internet follow some common guidelines for policies and operations.
+   While these guidelines are generally different in scope and style
+   from protocol standards, their establishment needs a similar process
+   for consensus building.
+
+   While it is recognized that entities such as the IAB and IESG are
+   composed of individuals who may participate, as individuals, in the
+   technical work of the IETF, it is also recognized that the entities
+
+
+
+Bradner                  Best Current Practice                 [Page 16]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   themselves have an existence as leaders in the community.  As leaders
+   in the Internet technical community, these entities should have an
+   outlet to propose ideas to stimulate work in a particular area, to
+   raise the community's sensitivity to a certain issue, to make a
+   statement of architectural principle, or to communicate their
+   thoughts on other matters.  The BCP subseries creates a smoothly
+   structured way for these management entities to insert proposals into
+   the consensus-building machinery of the IETF while gauging the
+   community's view of that issue.
+
+   Finally, the BCP series may be used to document the operation of the
+   IETF itself.  For example, this document defines the IETF Standards
+   Process and is published as a BCP.
+
+5.1 BCP Review Process
+
+   Unlike standards-track documents, the mechanisms described in BCPs
+   are not well suited to the phased roll-in nature of the three stage
+   standards track and instead generally only make sense for full and
+   immediate instantiation.
+
+   The BCP process is similar to that for proposed standards.  The BCP
+   is submitted to the IESG for review, (see section 6.1.1) and the
+   existing review process applies, including a Last-Call on the IETF
+   Announce mailing list.  However, once the IESG has approved the
+   document, the process ends and the document is published.  The
+   resulting document is viewed as having the technical approval of the
+   IETF.
+
+   Specifically, a document to be considered for the status of BCP must
+   undergo the procedures outlined in sections 6.1, and 6.4 of this
+   document. The BCP process may be appealed according to the procedures
+   in section 6.5.
+
+   Because BCPs are meant to express community consensus but are arrived
+   at more quickly than standards, BCPs require particular care.
+   Specifically, BCPs should not be viewed simply as stronger
+   Informational RFCs, but rather should be viewed as documents suitable
+   for a content different from Informational RFCs.
+
+   A specification, or group of specifications, that has, or have been
+   approved as a BCP is assigned a number in the BCP series while
+   retaining its RFC number(s).
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 17]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+6.  THE INTERNET STANDARDS PROCESS
+
+   The mechanics of the Internet Standards Process involve decisions of
+   the IESG concerning the elevation of a specification onto the
+   standards track or the movement of a standards-track specification
+   from one maturity level to another.  Although a number of reasonably
+   objective criteria (described below and in section 4) are available
+   to guide the IESG in making a decision to move a specification onto,
+   along, or off the standards track, there is no algorithmic guarantee
+   of elevation to or progression along the standards track for any
+   specification.  The experienced collective judgment of the IESG
+   concerning the technical quality of a specification proposed for
+   elevation to or advancement in the standards track is an essential
+   component of the decision-making process.
+
+6.1  Standards Actions
+
+   A "standards action" -- entering a particular specification into,
+   advancing it within, or removing it from, the standards track -- must
+   be approved by the IESG.
+
+6.1.1  Initiation of Action
+
+   A specification that is intended to enter or advance in the Internet
+   standards track shall first be posted as an Internet-Draft (see
+   section 2.2) unless it has not changed since publication as an RFC.
+   It shall remain as an Internet-Draft for a period of time, not less
+   than two weeks, that permits useful community review, after which a
+   recommendation for action may be initiated.
+
+   A standards action is initiated by a recommendation by the IETF
+   Working group responsible for a specification to its Area Director,
+   copied to the IETF Secretariat or, in the case of a specification not
+   associated with a Working Group, a recommendation by an individual to
+   the IESG.
+
+6.1.2  IESG Review and Approval
+
+   The IESG shall determine whether or not a specification submitted to
+   it according to section 6.1.1 satisfies the applicable criteria for
+   the recommended action (see sections 4.1 and 4.2), and shall in
+   addition determine whether or not the technical quality and clarity
+   of the specification is consistent with that expected for the
+   maturity level to which the specification is recommended.
+
+   In order to obtain all of the information necessary to make these
+   determinations, particularly when the specification is considered by
+   the IESG to be extremely important in terms of its potential impact
+
+
+
+Bradner                  Best Current Practice                 [Page 18]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   on the Internet or on the suite of Internet protocols, the IESG may,
+   at its discretion, commission an independent technical review of the
+   specification.
+
+   The IESG will send notice to the IETF of the pending IESG
+   consideration of the document(s) to permit a final review by the
+   general Internet community.  This "Last-Call" notification shall be
+   via electronic mail to the IETF Announce mailing list.  Comments on a
+   Last-Call shall be accepted from anyone, and should be sent as
+   directed in the Last-Call announcement.
+
+   The Last-Call period shall be no shorter than two weeks except in
+   those cases where the proposed standards action was not initiated by
+   an IETF Working Group, in which case the Last-Call period shall be no
+   shorter than four weeks.  If the IESG believes that the community
+   interest would be served by allowing more time for comment, it may
+   decide on a longer Last-Call period or to explicitly lengthen a
+   current Last-Call period.
+
+   The IESG is not bound by the action recommended when the
+   specification was submitted.  For example, the IESG may decide to
+   consider the specification for publication in a different category
+   than that requested.  If the IESG determines this before the Last-
+   Call is issued then the Last-Call should reflect the IESG's view.
+   The IESG could also decide to change the publication category based
+   on the response to a Last-Call. If this decision would result in a
+   specification being published at a "higher" level than the original
+   Last-Call was for, a new Last-Call should be issued indicating the
+   IESG recommendation. In addition, the IESG may decide to recommend
+   the formation of a new Working Group in the case of significant
+   controversy in response to a Last-Call for specification not
+   originating from an IETF Working Group.
+
+   In a timely fashion after the expiration of the Last-Call period, the
+   IESG shall make its final determination of whether or not to approve
+   the standards action, and shall notify the IETF of its decision via
+   electronic mail to the IETF Announce mailing list.
+
+6.1.3  Publication
+
+   If a standards action is approved, notification is sent to the RFC
+   Editor and copied to the IETF with instructions to publish the
+   specification as an RFC.  The specification shall at that point be
+   removed from the Internet-Drafts directory.
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 19]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   An official summary of standards actions completed and pending shall
+   appear in each issue of the Internet Society's newsletter.  This
+   shall constitute the "publication of record" for Internet standards
+   actions.
+
+   The RFC Editor shall publish periodically an "Internet Official
+   Protocol Standards" RFC [1], summarizing the status of all Internet
+   protocol and service specifications.
+
+6.2  Advancing in the Standards Track
+
+   The procedure described in section 6.1 is followed for each action
+   that attends the advancement of a specification along the standards
+   track.
+
+   A specification shall remain at the Proposed Standard level for at
+   least six (6) months.
+
+   A specification shall remain at the Draft Standard level for at least
+   four (4) months, or until at least one IETF meeting has occurred,
+   whichever comes later.
+
+   These minimum periods are intended to ensure adequate opportunity for
+   community review without severely impacting timeliness.  These
+   intervals shall be measured from the date of publication of the
+   corresponding RFC(s), or, if the action does not result in RFC
+   publication, the date of the announcement of the IESG approval of the
+   action.
+
+   A specification may be (indeed, is likely to be) revised as it
+   advances through the standards track.  At each stage, the IESG shall
+   determine the scope and significance of the revision to the
+   specification, and, if necessary and appropriate, modify the
+   recommended action.  Minor revisions are expected, but a significant
+   revision may require that the specification accumulate more
+   experience at its current maturity level before progressing. Finally,
+   if the specification has been changed very significantly, the IESG
+   may recommend that the revision be treated as a new document, re-
+   entering the standards track at the beginning.
+
+   Change of status shall result in republication of the specification
+   as an RFC, except in the rare case that there have been no changes at
+   all in the specification since the last publication.  Generally,
+   desired changes will be "batched" for incorporation at the next level
+   in the standards track.  However, deferral of changes to the next
+   standards action on the specification will not always be possible or
+   desirable; for example, an important typographical error, or a
+   technical error that does not represent a change in overall function
+
+
+
+Bradner                  Best Current Practice                 [Page 20]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   of the specification, may need to be corrected immediately.  In such
+   cases, the IESG or RFC Editor may be asked to republish the RFC (with
+   a new number) with corrections, and this will not reset the minimum
+   time-at-level clock.
+
+   When a standards-track specification has not reached the Internet
+   Standard level but has remained at the same maturity level for
+   twenty-four (24) months, and every twelve (12) months thereafter
+   until the status is changed, the IESG shall review the viability of
+   the standardization effort responsible for that specification and the
+   usefulness of the technology. Following each such review, the IESG
+   shall approve termination or continuation of the development effort,
+   at the same time the IESG shall decide to maintain the specification
+   at the same maturity level or to move it to Historic status.  This
+   decision shall be communicated to the IETF by electronic mail to the
+   IETF Announce mailing list to allow the Internet community an
+   opportunity to comment. This provision is not intended to threaten a
+   legitimate and active Working Group effort, but rather to provide an
+   administrative mechanism for terminating a moribund effort.
+
+6.3  Revising a Standard
+
+   A new version of an established Internet Standard must progress
+   through the full Internet standardization process as if it were a
+   completely new specification.  Once the new version has reached the
+   Standard level, it will usually replace the previous version, which
+   will be moved to Historic status.  However, in some cases both
+   versions may remain as Internet Standards to honor the requirements
+   of an installed base.  In this situation, the relationship between
+   the previous and the new versions must be explicitly stated in the
+   text of the new version or in another appropriate document (e.g., an
+   Applicability Statement; see section 3.2).
+
+6.4  Retiring a Standard
+
+   As the technology changes and matures, it is possible for a new
+   Standard specification to be so clearly superior technically that one
+   or more existing standards track specifications for the same function
+   should be retired.  In this case, or when it is felt for some other
+   reason that an existing standards track specification should be
+   retired, the IESG shall approve a change of status of the old
+   specification(s) to Historic.  This recommendation shall be issued
+   with the same Last-Call and notification procedures used for any
+   other standards action.  A request to retire an existing standard can
+   originate from a Working Group, an Area Director or some other
+   interested party.
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 21]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+6.5  Conflict Resolution and Appeals
+
+   Disputes are possible at various stages during the IETF process. As
+   much as possible the process is designed so that compromises can be
+   made, and genuine consensus achieved, however there are times when
+   even the most reasonable and knowledgeable people are unable to
+   agree. To achieve the goals of openness and fairness, such conflicts
+   must be resolved by a process of open review and discussion. This
+   section specifies the procedures that shall be followed to deal with
+   Internet standards issues that cannot be resolved through the normal
+   processes whereby IETF Working Groups and other Internet Standards
+   Process participants ordinarily reach consensus.
+
+6.5.1 Working Group Disputes
+
+   An individual (whether a participant in the relevant Working Group or
+   not) may disagree with a Working Group recommendation based on his or
+   her belief that either (a) his or her own views have not been
+   adequately considered by the Working Group, or (b) the Working Group
+   has made an incorrect technical choice which places the quality
+   and/or integrity of the Working Group's product(s) in significant
+   jeopardy.  The first issue is a difficulty with Working Group
+   process;  the latter is an assertion of technical error.  These two
+   types of disagreement are quite different, but both are handled by
+   the same process of review.
+
+   A person who disagrees with a Working Group recommendation shall
+   always first discuss the matter with the Working Group's chair(s),
+   who may involve other members of the Working Group (or the Working
+   Group as a whole) in the discussion.
+
+   If the disagreement cannot be resolved in this way, any of the
+   parties involved may bring it to the attention of the Area
+   Director(s) for the area in which the Working Group is chartered.
+   The Area Director(s) shall attempt to resolve the dispute.
+
+   If the disagreement cannot be resolved by the Area Director(s) any of
+   the parties involved may then appeal to the IESG as a whole.  The
+   IESG shall then review the situation and attempt to resolve it in a
+   manner of its own choosing.
+
+   If the disagreement is not resolved to the satisfaction of the
+   parties at the IESG level, any of the parties involved may appeal the
+   decision to the IAB.  The IAB shall then review the situation and
+   attempt to resolve it in a manner of its own choosing.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 22]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   The IAB decision is final with respect to the question of whether or
+   not the Internet standards procedures have been followed and with
+   respect to all questions of technical merit.
+
+6.5.2 Process Failures
+
+   This document sets forward procedures required to be followed to
+   ensure openness and fairness of the Internet Standards Process, and
+   the technical viability of the standards created. The IESG is the
+   principal agent of the IETF for this purpose, and it is the IESG that
+   is charged with ensuring that the required procedures have been
+   followed, and that any necessary prerequisites to a standards action
+   have been met.
+
+   If an individual should disagree with an action taken by the IESG in
+   this process, that person should first discuss the issue with the
+   ISEG Chair. If the IESG Chair is unable to satisfy the complainant
+   then the IESG as a whole should re-examine the action taken, along
+   with input from the complainant, and determine whether any further
+   action is needed.  The IESG shall issue a report on its review of the
+   complaint to the IETF.
+
+   Should the complainant not be satisfied with the outcome of the IESG
+   review, an appeal may be lodged to the IAB. The IAB shall then review
+   the situation and attempt to resolve it in a manner of its own
+   choosing and report to the IETF on the outcome of its review.
+
+   If circumstances warrant, the IAB may direct that an IESG decision be
+   annulled, and the situation shall then be as it was before the IESG
+   decision was taken. The IAB may also recommend an action to the IESG,
+   or make such other recommendations as it deems fit. The IAB may not,
+   however, pre-empt the role of the IESG by issuing a decision which
+   only the IESG is empowered to make.
+
+   The IAB decision is final with respect to the question of whether or
+   not the Internet standards procedures have been followed.
+
+6.5.3 Questions of Applicable Procedure
+
+   Further recourse is available only in cases in which the procedures
+   themselves (i.e., the procedures described in this document) are
+   claimed to be inadequate or insufficient to the protection of the
+   rights of all parties in a fair and open Internet Standards Process.
+   Claims on this basis may be made to the Internet Society Board of
+   Trustees.  The President of the Internet Society shall acknowledge
+   such an appeal within two weeks, and shall at the time of
+   acknowledgment advise the petitioner of the expected duration of the
+   Trustees' review of the appeal.  The Trustees shall review the
+
+
+
+Bradner                  Best Current Practice                 [Page 23]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   situation in a manner of its own choosing and report to the IETF on
+   the outcome of its review.
+
+   The Trustees' decision upon completion of their review shall be final
+   with respect to all aspects of the dispute.
+
+6.5.4 Appeals Procedure
+
+   All appeals must include a detailed and specific description of the
+   facts of the dispute.
+
+   All appeals must be initiated within two months of the public
+   knowledge of the action or decision to be challenged.
+
+   At all stages of the appeals process, the individuals or bodies
+   responsible for making the decisions have the discretion to define
+   the specific procedures they will follow in the process of making
+   their decision.
+
+   In all cases a decision concerning the disposition of the dispute,
+   and the communication of that decision to the parties involved, must
+   be accomplished within a reasonable period of time.
+
+   [NOTE:  These procedures intentionally and explicitly do not
+   establish a fixed maximum time period that shall be considered
+   "reasonable" in all cases.  The Internet Standards Process places a
+   premium on consensus and efforts to achieve it, and deliberately
+   foregoes deterministically swift execution of procedures in favor of
+   a latitude within which more genuine technical agreements may be
+   reached.]
+
+7.  EXTERNAL STANDARDS AND SPECIFICATIONS
+
+   Many standards groups other than the IETF create and publish
+   standards documents for network protocols and services.  When these
+   external specifications play an important role in the Internet, it is
+   desirable to reach common agreements on their usage -- i.e., to
+   establish Internet Standards relating to these external
+   specifications.
+
+   There are two categories of external specifications:
+
+   (1)  Open Standards
+
+      Various national and international standards bodies, such as ANSI,
+      ISO, IEEE, and ITU-T, develop a variety of protocol and service
+      specifications that are similar to Technical Specifications
+      defined here.  National and international groups also publish
+
+
+
+Bradner                  Best Current Practice                 [Page 24]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+      "implementors' agreements" that are analogous to Applicability
+      Statements, capturing a body of implementation-specific detail
+      concerned with the practical application of their standards.  All
+      of these are considered to be "open external standards" for the
+      purposes of the Internet Standards Process.
+
+   (2)  Other Specifications
+
+      Other proprietary specifications that have come to be widely used
+      in the Internet may be treated by the Internet community as if
+      they were a "standards".  Such a specification is not generally
+      developed in an open fashion, is typically proprietary, and is
+      controlled by the vendor, vendors, or organization that produced
+      it.
+
+7.1  Use of External Specifications
+
+   To avoid conflict between competing versions of a specification, the
+   Internet community will not standardize a specification that is
+   simply an "Internet version" of an existing external specification
+   unless an explicit cooperative arrangement to do so has been made.
+   However, there are several ways in which an external specification
+   that is important for the operation and/or evolution of the Internet
+   may be adopted for Internet use.
+
+7.1.1  Incorporation of an Open Standard
+
+   An Internet Standard TS or AS may incorporate an open external
+   standard by reference.  For example, many Internet Standards
+   incorporate by reference the ANSI standard character set "ASCII" [2].
+   Whenever possible, the referenced specification shall be available
+   online.
+
+7.1.2  Incorporation of Other Specifications
+
+   Other proprietary specifications may be incorporated by reference to
+   a version of the specification as long as the proprietor meets the
+   requirements of section 10.  If the other proprietary specification
+   is not widely and readily available, the IESG may request that it be
+   published as an Informational RFC.
+
+   The IESG generally should not favor a particular proprietary
+   specification over technically equivalent and competing
+   specification(s) by making any incorporated vendor specification
+   "required" or "recommended".
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 25]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+7.1.3  Assumption
+
+   An IETF Working Group may start from an external specification and
+   develop it into an Internet specification.  This is acceptable if (1)
+   the specification is provided to the Working Group in compliance with
+   the requirements of section 10, and (2) change control has been
+   conveyed to IETF by the original developer of the specification for
+   the specification or for specifications derived from the original
+   specification.
+
+8.  NOTICES AND RECORD KEEPING
+
+   Each of the organizations involved in the development and approval of
+   Internet Standards shall publicly announce, and shall maintain a
+   publicly accessible record of, every activity in which it engages, to
+   the extent that the activity represents the prosecution of any part
+   of the Internet Standards Process.  For purposes of this section, the
+   organizations involved in the development and approval of Internet
+   Standards includes the IETF, the IESG, the IAB, all IETF Working
+   Groups, and the Internet Society Board of Trustees.
+
+   For IETF and Working Group meetings announcements shall be made by
+   electronic mail to the IETF Announce mailing list and shall be made
+   sufficiently far in advance of the activity to permit all interested
+   parties to effectively participate.  The announcement shall contain
+   (or provide pointers to) all of the information that is necessary to
+   support the participation of any interested individual.  In the case
+   of a meeting, for example, the announcement shall include an agenda
+   that specifies the standards- related issues that will be discussed.
+
+   The formal record of an organization's standards-related activity
+   shall include at least the following:
+
+   o  the charter of the organization (or a defining document equivalent
+      to a charter);
+   o  complete and accurate minutes of meetings;
+   o  the archives of Working Group electronic mail mailing lists;  and
+   o  all written contributions from participants that pertain to the
+      organization's standards-related activity.
+
+   As a practical matter, the formal record of all Internet Standards
+   Process activities is maintained by the IETF Secretariat, and is the
+   responsibility of the IETF Secretariat except that each IETF Working
+   Group is expected to maintain their own email list archive and must
+   make a best effort to ensure that all traffic is captured and
+   included in the archives.  Also, the Working Group chair is
+   responsible for providing the IETF Secretariat with complete and
+   accurate minutes of all Working Group meetings.  Internet-Drafts that
+
+
+
+Bradner                  Best Current Practice                 [Page 26]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   have been removed (for any reason) from the Internet-Drafts
+   directories shall be archived by the IETF Secretariat for the sole
+   purpose of preserving an historical record of Internet standards
+   activity and thus are not retrievable except in special
+   circumstances.
+
+9.  VARYING THE PROCESS
+
+   This document, which sets out the rules and procedures by which
+   Internet Standards and related documents are made is itself a product
+   of the Internet Standards Process (as a BCP, as described in section
+   5). It replaces a previous version, and in time, is likely itself to
+   be replaced.
+
+   While, when published, this document represents the community's view
+   of the proper and correct process to follow, and requirements to be
+   met, to allow for the best possible Internet Standards and BCPs, it
+   cannot be assumed that this will always remain the case. From time to
+   time there may be a desire to update it, by replacing it with a new
+   version.  Updating this document uses the same open procedures as are
+   used for any other BCP.
+
+   In addition, there may be situations where following the procedures
+   leads to a deadlock about a specific specification, or there may be
+   situations where the procedures provide no guidance.  In these cases
+   it may be appropriate to invoke the variance procedure described
+   below.
+
+9.1 The Variance Procedure
+
+   Upon the recommendation of the responsible IETF Working Group (or, if
+   no Working Group is constituted, upon the recommendation of an ad hoc
+   committee), the IESG may enter a particular specification into, or
+   advance it within, the standards track even though some of the
+   requirements of this document have not or will not be met. The IESG
+   may approve such a variance, however, only if it first determines
+   that the likely benefits to the Internet community are likely to
+   outweigh any costs to the Internet community that result from
+   noncompliance with the requirements in this document.  In exercising
+   this discretion, the IESG shall at least consider (a) the technical
+   merit of the specification, (b) the possibility of achieving the
+   goals of the Internet Standards Process without granting a variance,
+   (c) alternatives to the granting of a variance, (d) the collateral
+   and precedential effects of granting a variance, and (e) the IESG's
+   ability to craft a variance that is as narrow as possible.  In
+   determining whether to approve a variance, the IESG has discretion to
+   limit the scope of the variance to particular parts of this document
+   and to impose such additional restrictions or limitations as it
+
+
+
+Bradner                  Best Current Practice                 [Page 27]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   determines appropriate to protect the interests of the Internet
+   community.
+
+   The proposed variance must detail the problem perceived, explain the
+   precise provision of this document which is causing the need for a
+   variance, and the results of the IESG's considerations including
+   consideration of points (a) through (d) in the previous paragraph.
+   The proposed variance shall be issued as an Internet Draft.  The IESG
+   shall then issue an extended Last-Call, of no less than 4 weeks, to
+   allow for community comment upon the proposal.
+
+   In a timely fashion after the expiration of the Last-Call period, the
+   IESG shall make its final determination of whether or not to approve
+   the proposed variance, and shall notify the IETF of its decision via
+   electronic mail to the IETF Announce mailing list.  If the variance
+   is approved it shall be forwarded to the RFC Editor with a request
+   that it be published as a BCP.
+
+   This variance procedure is for use when a one-time waving of some
+   provision of this document is felt to be required.  Permanent changes
+   to this document shall be accomplished through the normal BCP
+   process.
+
+   The appeals process in section 6.5 applies to this process.
+
+9.2 Exclusions
+
+   No use of this procedure may lower any specified delays, nor exempt
+   any proposal from the requirements of openness, fairness, or
+   consensus, nor from the need to keep proper records of the meetings
+   and mailing list discussions.
+
+   Specifically, the following sections of this document must not be
+   subject of a variance: 5.1, 6.1, 6.1.1 (first paragraph), 6.1.2, 6.3
+   (first sentence), 6.5 and 9.
+
+10.  INTELLECTUAL PROPERTY RIGHTS
+
+10.1.  General Policy
+
+   In all matters of intellectual property rights and procedures, the
+   intention is to benefit the Internet community and the public at
+   large, while respecting the legitimate rights of others.
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 28]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+10.2  Confidentiality Obligations
+
+   No contribution that is subject to any requirement of confidentiality
+   or any restriction on its dissemination may be considered in any part
+   of the Internet Standards Process, and there must be no assumption of
+   any confidentiality obligation with respect to any such contribution.
+
+10.3.  Rights and Permissions
+
+   In the course of standards work, the IETF receives contributions in
+   various forms and from many persons.  To best facilitate the
+   dissemination of these contributions, it is necessary to understand
+   any intellectual property rights (IPR) relating to the contributions.
+
+10.3.1.  All Contributions
+
+   By submission of a contribution, each person actually submitting the
+   contribution is deemed to agree to the following terms and conditions
+   on his own behalf, on behalf of the organization (if any) he
+   represents and on behalf of the owners of any propriety rights in the
+   contribution..  Where a submission identifies contributors in
+   addition to the contributor(s) who provide the actual submission, the
+   actual submitter(s) represent that each other named contributor was
+   made aware of and agreed to accept the same terms and conditions on
+   his own behalf, on behalf of any organization he may represent and
+   any known owner of any proprietary rights in the contribution.
+
+   l. Some works (e.g. works of the U.S. Government) are not subject to
+      copyright.  However, to the extent that the submission is or may
+      be subject to copyright, the contributor, the organization he
+      represents (if any) and the owners of any proprietary rights in
+      the contribution, grant an unlimited perpetual, non-exclusive,
+      royalty-free, world-wide right and license to the ISOC and the
+      IETF under any copyrights in the contribution.  This license
+      includes the right to copy, publish and distribute the
+      contribution in any way, and to prepare derivative works that are
+      based on or incorporate all or part of the contribution, the
+      license to such derivative works to be of the same scope as the
+      license of the original contribution.
+
+   2. The contributor acknowledges that the ISOC and IETF have no duty
+      to publish or otherwise use or disseminate any contribution.
+
+   3. The contributor grants permission to reference the name(s) and
+      address(es) of the contributor(s) and of the organization(s) he
+      represents (if any).
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 29]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   4. The contributor represents that contribution properly acknowledge
+      major contributors.
+
+   5. The contribuitor, the organization (if any) he represents and the
+      owners of any proprietary rights in the contribution, agree that
+      no information in the contribution is confidential and that the
+      ISOC and its affiliated organizations may freely disclose any
+      information in the contribution.
+
+   6. The contributor represents that he has disclosed the existence of
+      any proprietary or intellectual property rights in the
+      contribution that are reasonably and personally known to the
+      contributor.  The contributor does not represent that he
+      personally knows of all potentially pertinent proprietary and
+      intellectual property rights owned or claimed by the organization
+      he represents (if any) or third parties.
+
+   7. The contributor represents that there are no limits to the
+      contributor's ability to make the grants acknowledgments and
+      agreements above that are reasonably and personally known to the
+      contributor.
+
+      By ratifying this description of the IETF process the Internet
+      Society warrants that it will not inhibit the traditional open and
+      free access to IETF documents for which license and right have
+      been assigned according to the procedures set forth in this
+      section, including Internet-Drafts and RFCs. This warrant is
+      perpetual and will not be revoked by the Internet Society or its
+      successors or assigns.
+
+10.3.2. Standards Track Documents
+
+   (A)  Where any patents, patent applications, or other proprietary
+      rights are known, or claimed, with respect to any specification on
+      the standards track, and brought to the attention of the IESG, the
+      IESG shall not advance the specification without including in the
+      document a note indicating the existence of such rights, or
+      claimed rights.  Where implementations are required before
+      advancement of a specification, only implementations that have, by
+      statement of the implementors, taken adequate steps to comply with
+      any such rights, or claimed rights, shall be considered for the
+      purpose of showing the adequacy of the specification.
+   (B)  The IESG disclaims any responsibility for identifying the
+      existence of or for evaluating the applicability of any claimed
+      copyrights, patents, patent applications, or other rights in the
+      fulfilling of the its obligations under (A), and will take no
+      position on the validity or scope of any such rights.
+
+
+
+
+Bradner                  Best Current Practice                 [Page 30]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   (C)  Where the IESG knows of rights, or claimed rights under (A), the
+      IETF Executive Director shall attempt to obtain from the claimant
+      of such rights, a written assurance that upon approval by the IESG
+      of the relevant Internet standards track specification(s), any
+      party will be able to obtain the right to implement, use and
+      distribute the technology or works when implementing, using or
+      distributing technology based upon the specific specification(s)
+      under openly specified, reasonable, non-discriminatory terms.
+      The Working Group proposing the use of the technology with respect
+      to which the proprietary rights are claimed may assist the IETF
+      Executive Director in this effort.  The results of this procedure
+      shall not affect advancement of a specification along the
+      standards track, except that the IESG may defer approval where a
+      delay may facilitate the obtaining of such assurances.  The
+      results will, however, be recorded by the IETF Executive Director,
+      and made available.  The IESG may also direct that a summary of
+      the results be included in any RFC published containing the
+      specification.
+
+10.3.3  Determination of Reasonable and Non-discriminatory Terms
+
+   The IESG will not make any explicit determination that the assurance
+   of reasonable and non-discriminatory terms for the use of a
+   technology has been fulfilled in practice.  It will instead use the
+   normal requirements for the advancement of Internet Standards to
+   verify that the terms for use are reasonable.  If the two unrelated
+   implementations of the specification that are required to advance
+   from Proposed Standard to Draft Standard have been produced by
+   different organizations or individuals or if the "significant
+   implementation and successful operational experience" required to
+   advance from Draft Standard to Standard has been achieved the
+   assumption is that the terms must be reasonable and to some degree,
+   non-discriminatory.  This assumption may be challenged during the
+   Last-Call period.
+
+10.4.  Notices
+
+   (A)  Standards track documents shall include the following notice:
+
+         "The IETF takes no position regarding the validity or scope of
+         any intellectual property 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; neither does
+         it represent that it has made any effort to identify any such
+         rights.  Information on the IETF's procedures with respect to
+         rights in standards-track and standards-related documentation
+         can be found in BCP-11.  Copies of claims of rights made
+
+
+
+Bradner                  Best Current Practice                 [Page 31]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+         available for publication 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 implementors or users of this
+         specification can be obtained from the IETF Secretariat."
+
+   (B)  The IETF encourages all interested parties to bring to its
+      attention, at the earliest possible time, the existence of any
+      intellectual property rights pertaining to Internet Standards.
+      For this purpose, each standards document shall include the
+      following invitation:
+
+         "The IETF invites any interested party to bring to its
+         attention any copyrights, patents or patent applications, or
+         other proprietary rights which may cover technology that may be
+         required to practice this standard.  Please address the
+         information to the IETF Executive Director."
+
+   (C)  The following copyright notice and disclaimer shall be included
+      in all ISOC standards-related documentation:
+
+         "Copyright (C) The Internet Society (date). All Rights
+         Reserved.
+
+         This document and translations of it may be copied and
+         furnished to others, and derivative works that comment on or
+         otherwise explain it or assist in its implmentation may be
+         prepared, copied, published and distributed, in whole or in
+         part, without restriction of any kind, provided that the above
+         copyright notice and this paragraph are included on all such
+         copies and derivative works.  However, this document itself may
+         not be modified in any way, such as by removing the copyright
+         notice or references to the Internet Society or other Internet
+         organizations, except as needed for the  purpose of developing
+         Internet standards in which case the procedures for copyrights
+         defined in the Internet Standards process must be followed, or
+         as required to translate it into languages other than English.
+
+         The limited permissions granted above are perpetual and will
+         not be revoked by the Internet Society or its successors or
+         assigns.
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 32]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+         This document and the information contained herein is provided
+         on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
+         ENGINEERING TASK FORCE DISCLAIMS 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."
+
+   (D)  Where the IESG is aware at the time of publication of
+      proprietary rights claimed with respect to a standards track
+      document, or the technology described or referenced therein, such
+      document shall contain the following notice:
+
+         "The IETF has been notified of intellectual property rights
+         claimed in regard to some or all of the specification contained
+         in this document.  For more information consult the online list
+         of claimed rights."
+
+11.  ACKNOWLEDGMENTS
+
+   There have been a number of people involved with the development of
+   the documents defining the IETF Standards Process over the years.
+   The process was first described in RFC 1310 then revised in RFC 1602
+   before the current effort (which relies heavily on its predecessors).
+   Specific acknowledgments must be extended to Lyman Chapin, Phill
+   Gross and Christian Huitema as the editors of the previous versions,
+   to Jon Postel and Dave Crocker for their inputs to those versions, to
+   Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their
+   reviews of the legal aspects of the procedures described herein, and
+   to John Stewart, Robert Elz and Steve Coya for their extensive input
+   on the final version.
+
+   In addition much of the credit for the refinement of the details of
+   the IETF processes belongs to the many members of the various
+   incarnations of the POISED Working Group.
+
+12.  SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 33]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+13.  REFERENCES
+
+   [1]  Postel, J., "Internet Official Protocol Standards", STD 1,
+        USC/Information Sciences Institute, March 1996.
+
+   [2]  ANSI, Coded Character Set -- 7-Bit American Standard Code for
+        Information Interchange, ANSI X3.4-1986.
+
+   [3]  Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
+        USC/Information Sciences Institute, October 1994.
+
+   [4]  Postel, J., "Introduction to the STD Notes", RFC 1311,
+        USC/Information Sciences Institute, March 1992.
+
+   [5]  Postel, J., "Instructions to RFC Authors", RFC 1543,
+        USC/Information Sciences Institute, October 1993.
+
+   [6]  Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
+        Standards", RFC 1796, April 1995.
+
+14. DEFINITIONS OF TERMS
+
+   IETF Area - A management division within the IETF.  An Area consists
+      of Working Groups related to a general topic such as routing.  An
+      Area is managed by one or two Area Directors.
+   Area Director - The manager of an IETF Area.  The Area Directors
+      along with the IETF Chair comprise the Internet Engineering
+      Steering Group (IESG).
+   File Transfer Protocol (FTP) - An Internet application used to
+      transfer files in a TCP/IP network.
+   gopher - An Internet application used to interactively select and
+      retrieve files in a TCP/IP network.
+   Internet Architecture Board (IAB) - An appointed group that assists
+      in the management of the IETF standards process.
+   Internet Engineering Steering Group (IESG) - A group comprised of the
+      IETF Area Directors and the IETF Chair.  The IESG is responsible
+      for the management, along with the IAB, of the IETF and is the
+      standards approval board for the IETF.
+   interoperable - For the purposes of this document, "interoperable"
+      means to be able to interoperate over a data communications path.
+   Last-Call - A public comment period used to gage the level of
+      consensus about the reasonableness of a proposed standards action.
+      (see section 6.1.2)
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 34]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+   online - Relating to information made available over the Internet.
+      When referenced in this document material is said to be online
+      when it is retrievable without restriction or undue fee using
+      standard Internet applications such as anonymous FTP, gopher or
+      the WWW.
+   Working Group - A group chartered by the IESG and IAB to work on a
+      specific specification, set of specifications or topic.
+
+15. AUTHOR'S ADDRESS
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 35]
+
+RFC 2026               Internet Standards Process           October 1996
+
+
+APPENDIX A: GLOSSARY OF ACRONYMS
+
+   ANSI:     American National Standards Institute
+   ARPA:     (U.S.) Advanced Research Projects Agency
+   AS:       Applicability Statement
+   FTP:      File Transfer Protocol
+   ASCII:    American Standard Code for Information Interchange
+   ITU-T:    Telecommunications Standardization sector of the
+             International Telecommunication Union (ITU), a UN
+             treaty organization; ITU-T was formerly called CCITT.
+   IAB:      Internet Architecture Board
+   IANA:     Internet Assigned Numbers Authority
+   IEEE:     Institute of Electrical and Electronics Engineers
+   ICMP:     Internet Control Message Protocol
+   IESG:     Internet Engineering Steering Group
+   IETF:     Internet Engineering Task Force
+   IP:       Internet Protocol
+   IRSG      Internet Research Steering Group
+   IRTF:     Internet Research Task Force
+   ISO:      International Organization for Standardization
+   ISOC:     Internet Society
+   MIB:      Management Information Base
+   OSI:      Open Systems Interconnection
+   RFC:      Request for Comments
+   TCP:      Transmission Control Protocol
+   TS:       Technical Specification
+   WWW:      World Wide Web
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 36]
+