doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc1310.txt b/doc/rfc/rfc1310.txt
new file mode 100644
index 0000000..6ae94c1
--- /dev/null
+++ b/doc/rfc/rfc1310.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Network Working Group                          Internet Activities Board
+Request for Comments: 1310                           Lyman Chapin, Chair
+                                                              March 1992
+
+
+                     The Internet Standards Process
+
+Status of this Memo
+
+   This informational memo presents the current procedures for creating
+   and documenting Internet Standards.  Distribution of this memo is
+   unlimited.
+
+TABLE OF CONTENTS
+
+   1.  INTRODUCTION .................................................  2
+      1.1. Internet Standards .......................................  2
+      1.2. Organization .............................................  3
+   2.  THE INTERNET STANDARDS PROCESS ...............................  4
+      2.1. Introduction .............................................  4
+      2.2. The Internet Standards Track .............................  5
+      2.3. Requests for Comments (RFCs) .............................  5
+      2.4. Internet Drafts ..........................................  6
+      2.5. Internet Assigned Number Authority (IANA) ................  7
+      2.6. Review and Approval ......................................  8
+      2.7. Entering the Standards Track .............................  9
+      2.8. Advancing in the Standards Track .........................  9
+      2.9. Revising a Standard ...................................... 10
+   3.  NOMENCLATURE ................................................. 10
+      3.1  Types of Specifications .................................. 10
+      3.2  Standards Track Maturity Levels .......................... 12
+      3.3  Non-Standards Track Maturity Levels ...................... 13
+      3.4  Requirement Levels ....................................... 14
+   4.  EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 15
+   5.  INTELLECTUAL PROPERTY RIGHTS ................................. 17
+   6.  PATENT POLICY ................................................ 17
+      6.1  Statement from Patent Holder ............................. 18
+      6.2  Record of Statement ...................................... 18
+      6.3  Notice ................................................... 18
+      6.4  Identifying Patents ...................................... 19
+   7.  ACKNOWLEDGMENTS AND REFERENCES ............................... 19
+   APPENDIX A: GLOSSARY ............................................. 20
+   APPENDIX B: UNRESOLVED ISSUES .................................... 21
+   Security Considerations .......................................... 23
+   Author's Address ................................................. 23
+
+
+
+
+
+
+IAB                                                             [Page 1]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+1.  INTRODUCTION
+
+   1.1  Internet Standards
+
+      This memo documents the process currently used for the
+      standardization of Internet protocols and procedures.
+
+      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 internets, i.e., sets of interconnected networks, that
+      are not connected to the Internet but use the Internet Standards.
+      The architecture and technical specifications of the Internet are
+      the result of numerous research and development activities
+      conducted over a period of two decades, performed by the network
+      R&D community, by service and equipment vendors, and by government
+      agencies around the world.
+
+      In general, an Internet Standard is a specification that is stable
+      and well-understood, is technically competent, has multiple,
+      independent, and interoperable implementations with operational
+      experience, enjoys significant public support, and is recognizably
+      useful in some or all parts of the Internet.
+
+      The principal set of Internet Standards is commonly known as the
+      "TCP/IP protocol suite".  As the Internet evolves, new protocols
+      and services, in particular those for Open Systems Interconnection
+      (OSI), have been and will be deployed in traditional TCP/IP
+      environments, leading to an Internet that supports multiple
+      protocol suites.  This document concerns all protocols,
+      procedures, and conventions used in the Internet, not just the
+      TCP/IP protocols.
+
+      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
+      perhaps revision based upon experience, is adopted as a Standard
+      by the appropriate body (see below), and is published.
+
+      In practice, the process is somewhat more complicated, due to (1)
+      the number and type of possible sources for specifications; (2)
+      the need to prepare and revise a specification in a manner that
+      preserves the interests of all of the affected parties;  (3) the
+      importance of establishing widespread community agreement on its
+      technical content; and (4) the difficulty of evaluating the
+      utility of a particular specification for the Internet community.
+
+
+
+
+IAB                                                             [Page 2]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      Some specifications that are candidates for Internet
+      standardization are the result of organized efforts directly
+      within the Internet community; others are the result of work that
+      was not originally organized as an Internet effort, but which was
+      later adopted by the Internet community.
+
+      From its inception, the Internet has been, and is expected to
+      remain, an evolving system whose participants regularly factor new
+      requirements and technology into the design and implementation of
+      the global Internet.  Users of the Internet and providers of the
+      equipment, software, and services that support it should
+      anticipate and embrace this adaptability as a major tenet of
+      Internet philosophy.
+
+      The procedures described in this document are the result of three
+      years of evolution, driven both by the needs of the growing and
+      increasingly diverse Internet community, and by experience.
+      Comments and suggestions are invited for improvement in these
+      procedures.
+
+   1.2  Organization
+
+      The Internet Activities Board (IAB) is the primary coordinating
+      committee for Internet design, engineering, and management [1].
+      The IAB has delegated to its Internet Engineering Task Force
+      (IETF) the primary responsibility for the development and review
+      of potential Internet Standards from all sources.  The IETF forms
+      Working Groups to pursue specific technical issues, frequently
+      resulting in the development of one or more specifications that
+      are proposed for adoption as Internet Standards.
+
+      Final decisions on Internet standardization are made by the IAB,
+      based upon recommendations from the Internet Engineering Steering
+      Group (IESG), the leadership body of the IETF.  IETF Working
+      Groups are organized into areas, and each area is coordinated by
+      an Area Director.  The Area Directors and the IETF Chairman are
+      included in the IESG.
+
+      Any member of the Internet community with the time and interest is
+      urged to attend IETF meetings and to participate actively in one
+      or more IETF Working Groups.  Participation is by individual
+      technical contributors, rather than formal representatives of
+      organizations.  The process works because the IETF Working Groups
+      display a spirit of cooperation as well as a high degree of
+      technical maturity; most IETF members agree that the greatest
+      benefit for all members of the Internet community results from
+      cooperative development of technically superior protocols and
+      services.
+
+
+
+IAB                                                             [Page 3]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      A second body under the IAB, the Internet Research Task Force
+      (IRTF), investigates topics considered to be too uncertain, too
+      advanced, or insufficiently well-understood to be the subject of
+      Internet standardization.  When an IRTF activity generates a
+      specification that is sufficiently stable to be considered for
+      Internet standardization, it is processed through the IETF.
+
+      Section 2 of this document describes the process and rules for
+      Internet standardization.  Section 3 presents the nomenclature for
+      different kinds and levels of Internet standard technical
+      specifications and their applicability.  Section 4 defines how
+      relevant externally-sponsored specifications and practices that
+      are developed and controlled by other bodies or by vendors are
+      handled in the Internet standardization process.  Section 5
+      presents the requirement for prior disclosure of the existence of
+      intellectual property rights.  Section 6 describes the rules for
+      Internet Standards that involve patents.
+
+2.  THE INTERNET STANDARDS PROCESS
+
+   2.1. Introduction
+
+      The procedures described in this document are intended to provide
+      a clear, open, and objective basis for developing, evaluating, and
+      adopting Internet Standards for protocols and services.  The
+      procedures provide ample opportunity for participation and comment
+      by all interested parties.  Before an Internet Standard is
+      adopted, it is repeatedly discussed (and perhaps debated) in open
+      open meetings and/or public electronic mailing lists, and it is
+      available for review via world-wide on-line directories.
+
+      These procedures are explicitly aimed at developing and adopting
+      generally-accepted practices.  Thus, a candidate for Internet
+      standardization is 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.
+
+      The procedures that are described here provide a great deal of
+      flexibility to adapt to the wide variety of circumstances that
+      occur in the Internet standardization process.  Experience has
+      shown this flexibility to be vital in achieving the following
+      goals for Internet standardization:
+
+
+
+
+
+
+
+
+IAB                                                             [Page 4]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+
+      *    high quality,
+
+      *    prior implementation and testing,
+
+      *    openness and fairness, and
+
+      *    timeliness.
+
+   2.2.  The Internet Standards Track
+
+      Specifications that are destined 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 below in
+      Section 3.2.
+
+      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 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 3.3 to
+      cover these and other "off-track" specifications.
+
+   2.3.  Requests for Comments (RFCs)
+
+      Each distinct version of a specification is published as part of
+      the "Request for Comments" (RFC) document series.
+
+      RFCs form a series of publications of networking technical
+      documents, begun in 1969 as part of the original DARPA wide-area
+      networking (ARPANET) project (see Appendix A for glossary of
+      acronyms).  RFCs cover a wide range of topics, from early
+      discussion of new research concepts to status memos about the
+      Internet.  The IAB views the RFC publication process to be
+      sufficiently important to warrant including the RFC Editor in the
+      IAB membership.
+
+      The status of specifications on the Internet standards track is
+      summarized periodically in a summary RFC entitled "IAB Official
+      Protocol Standards" [2].  This RFC shows the level of maturity and
+      other helpful information for each Internet protocol or service
+      specification.
+
+
+
+
+
+
+IAB                                                             [Page 5]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+             ********************************************************
+             *   The "IAB Official Protocol Standards" RFC is the   *
+             *   authoritative statement of the status of any       *
+             *   particular Internet specification,                 *
+             ********************************************************
+
+      and it is the "Publication of Record" with respect to Internet
+      standardization.
+
+      The STD documents form a subseries of the RFC series.  When a
+      specification has been adopted as a Standard, its RFC is labeled
+      with a STDxxx number [9] in addition to its RFC number.
+
+      Not all specifications of protocols or services for the Internet
+      should or will become Internet Standards.  Such non-standards
+      track specifications are not subject to the rules for Internet
+      standardization; generally, they will be published directly as
+      RFCs at the discretion of the RFC editor.  These RFCs will be
+      marked as "Experimental" or "Informational" (see section 3.3).
+
+             ********************************************************
+             *   It is important to remember that not all RFCs      *
+             *   are standards track documents, and that not all    *
+             *   standards track documents reach the level of       *
+             *   Standard.                                          *
+             ********************************************************
+
+   2.4.  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.
+
+      After completion to the satisfaction of its author and the
+      cognizant Working Group, a document that is expected to enter or
+      advance in the Internet standardization process shall be made
+      available as an Internet Draft.  It shall remain as an Internet
+      Draft for a period of time that permits useful community review,
+      at least two weeks, before submission to the IESG.
+
+      An Internet Draft that is published as an RFC is removed from the
+      Internet Draft directory.  A document 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 Draft directory.  At any time, an
+
+
+
+IAB                                                             [Page 6]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      Internet Draft may be replace 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 next section.  Internet Drafts have no formal status, and
+      are not part of the permanent archival record of Internet
+      activity, and they 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.
+
+   2.5.  Internet Assigned Number Authority (IANA)
+
+      Many protocol specifications include numbers, keywords, and other
+      parameters that must be uniquely assigned.  Examples include
+      version numbers, protocol numbers, port numbers, and MIB numbers.
+      The IAB has delegated to the Internet Assigned Numbers Authority
+      (IANA) the task of assigning such protocol parameters for the
+      Internet.  The IANA publishes tables of all currently assigned
+      numbers and parameters in RFCs titled "Assigned Numbers" [8].
+
+      Each category of assigned numbers typically arises from some
+      protocol that is on the standards track or is an Internet
+      Standard.  For example, TCP port numbers are assigned because TCP
+      is a Standard.  A particular value within a category may be
+      assigned in a variety of circumstances; the specification
+      requiring the parameter may be in the standards track, it may be
+      Experimental, or it may be private.
+
+      Chaos could result from accidental conflicts of parameter values,
+      so we urge that every protocol parameter, for either public or
+      private usage, be explicitly assigned by the IANA.  Private
+      protocols often become public.  Programmers are often tempted to
+      choose a "random" value, or guess the next unassigned value of a
+      parameter; both are hazardous.
+
+      The IANA is tasked to avoid frivolous assignments and to
+      distinguish different assignments uniquely.  The IANA accomplishes
+      both goals by requiring a technical description of each protocol
+      or service to which a value is to be assigned.  Judgment on the
+      adequacy of the description resides with the IANA.  In the case of
+      a standards track or Experimental protocol, the corresponding
+      technical specifications provide the required documentation for
+      IANA.  For a proprietary protocol, the IANA will keep confidential
+      any writeup that is supplied, but at least a short (2 page)
+      writeup is still required for an assignment.
+
+      To contact the IANA for information or to request a number,
+
+
+
+IAB                                                             [Page 7]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      keyword or parameter assignment send an email message to
+      "iana@isi.edu".
+
+   2.6.  Review and Approval
+
+      A standards action -- entering a particular specification into, or
+      advancing it within, the standards track -- shall be recommended
+      to the appropriate IETF Area Director, or to the Chairman of the
+      IETF, by the individual or group that is responsible for the
+      specification.  Usually, the recommendation will come from an IETF
+      Working Group.  The Area Director or IETF chairman, in
+      consultation with the IESG, shall determine if an independent
+      technical review of the specification is required, and shall
+      commission one if necessary.
+
+      When a specification is sufficiently important in terms of its
+      potential impact on the Internet or on the suite of Internet
+      protocols, the IESG shall form a special review and analysis
+      committee to prepare an evaluation of the specification.  Such a
+      committee is commissioned to provide an objective basis for
+      agreement within the Internet community that the specification is
+      ready for advancement.  Furthermore, when the criteria for
+      advancement along the standards track for an important class of
+      specifications (e.g., routing protocols [6]) are not universally
+      recognized, the IESG shall commission the development and
+      publication of category-specific acceptance criteria.
+
+      The IESG shall determine whether a specification satisfies the
+      applicable criteria for the recommended action (see Sections 3.2
+      and 3.3 of this document) and shall communicate its findings to
+      the IETF to permit a final review by the general Internet
+      community.  This IETF notification shall be via electronic mail to
+      the IETF mailing list; in addition, there will often be a
+      presentation or statement by the appropriate working group or Area
+      Director during an IETF plenary meeting.  Any significant issues
+      that have not been resolved satisfactorily during the development
+      of the specification may be raised at this time for final
+      resolution by the IESG.
+
+      The IESG shall communicate to the IAB its recommendation for
+      action, with a citation to the most current version of the
+      document.  The IETF shall be notified by email of any such
+      recommendation.  If the IAB finds a significant problem, or needs
+      clarification on a particular point, it shall resolve the matter
+      with the Working Group and its chairperson and/or the document
+      author, with the assistance and concurrence of the IESG and the
+      relevant IETF Area Director.
+
+
+
+
+IAB                                                             [Page 8]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      Following IAB approval and any necessary editorial work, the RFC
+      Editor shall publish the specification as an RFC.  The
+      specification shall then be removed from the Internet Drafts
+      directory.
+
+   2.7.  Entering the Standards Track
+
+      A specification that is potentially an Internet Standard may
+      originate from:
+
+      (a)  an IAB-sponsored effort (typically an IETF Working Group),
+
+      (b)  independent activity by individuals, or
+
+      (c)  an external organization.
+
+      In cases (b) and (c), the work might be tightly integrated with
+      the work of an existing IETF Working Group, or it might be offered
+      for standardization without prior IETF involvement.  In most
+      cases, a specification resulting from an effort that took place
+      outside of an IETF Working Group context will be submitted to an
+      appropriate Working Group for evaluation and refinement; if
+      necessary, an appropriate Working Group will be created.
+
+      For externally-developed specifications that are well-integrated
+      with existing Working Group efforts, a Working Group is assumed to
+      afford adequate community review of the accuracy and applicability
+      of the specification.  If a Working Group is unable to resolve all
+      technical and usage questions, additional independent review may
+      be necessary.  Such reviews may be done within a Working Group
+      context, or by an ad hoc review committee established specifically
+      for that purpose.  It is the responsibility of the appropriate
+      IETF Area Director to determine what, if any, review of an
+      external specification is needed and how it shall be conducted.
+
+   2.8.  Advancing in the Standards Track
+
+      A specification shall remain at the Proposed Standard level for at
+      least 6 months and at the Draft Standard level for at least 4
+      months.
+
+      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, and they will
+      not affect advancement through the standards track.  A significant
+      revision may require that the specification accumulate more
+
+
+
+IAB                                                             [Page 9]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      experience at its current maturity level before progressing.
+      Finally, if the specification has been changed very significantly,
+      the IESG may decide to treat the revision as if it were a new
+      document, re-entering the standards track at the beginning.
+
+      A specification that has not reached the maturity level of
+      Standard within twenty-four months of first becoming a Proposed
+      Standard shall be reviewed for viability by the IESG, which shall
+      recommend either termination or continuation of the development
+      effort to the IAB.  Such a recommendation shall be communicated to
+      the IETF via electronic mail to the IETF mailing list, to allow
+      the Internet community an opportunity to comment.  This provision
+      is not intended to threaten legitimate and active Working Group
+      efforts, but rather to provide an administrative mechanism for
+      terminating a moribund effort.
+
+   2.9.  Revising a Standard
+
+      A recommendation to revise an established Internet Standard shall
+      be evaluated by the IESG with respect to the operational impact of
+      introducing a new version while the previous version is still in
+      use.  If the IESG accepts the recommendation, the new version 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 may
+      immediately replace the previous version.  In some cases, both
+      versions may remain as Internet Standards to honor the
+      requirements of an installed base; however, 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.1.2).
+
+3.  NOMENCLATURE
+
+   3.1.  Types of Specifications
+
+      The specifications subject to the Internet standardization process
+      fall into two categories:  Technical Specifications (TS) and
+      Applicability Statements (AS).
+
+      3.1.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
+
+
+
+IAB                                                            [Page 10]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+         from other specifications by reference to other documents
+         (which may or may 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, is
+         defined by an Applicability Statement.
+
+      3.1.2.  Applicability Statement (AS)
+
+         An Applicability Statement specifies how, and under what
+         circumstances, one or more TSs are to be applied to support a
+         particular Internet capability. An AS may specify uses for TSs
+         that are not Internet Standards, as discussed in Section 4.
+
+         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.
+
+         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 [3,4,5], such as Internet
+         routers or Internet hosts.
+
+         An AS may not have a higher maturity level in the standards
+         track than any TS to which the AS applies.  For example, a TS
+         at Draft Standard level may be referenced by an AS at the
+         Proposed Standard or Draft Standard level, but not an AS at the
+         Standard level.  Like a TS, an AS does not come into effect
+         until it reaches Standard level.
+
+      Although TSs and ASs are conceptually separate, in practice an
+      Internet Standard RFC may include elements of both an AS and one
+      or more TSs in a single document.  For example, Technical
+      Specifications that are developed specifically and exclusively for
+      some particular domain of applicability, e.g., for mail server
+
+
+
+IAB                                                            [Page 11]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      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.
+
+   3.2.  Standards Track Maturity Levels
+
+      ASs and TSs 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.  The general
+      procedures for developing a specification and processing it
+      through the maturity levels along the standards track were
+      discussed in Section 2 above.
+
+      3.2.1. Proposed Standard
+
+         The entry-level maturity for the standards track is "Proposed
+         Standard".  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.
+
+         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.  Furthermore, the IAB 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.
+         Typically, such a specification will be published initially in
+         the Experimental state (see below), which is not part of the
+         standards track, and moved to the standards track only after
+         sufficient implementation or operational experience has been
+         obtained.
+
+         A Proposed Standard should have no known technical omissions
+         with respect to the requirements placed upon it.  In some
+         cases, the IESG may recommend that the requirements be
+         explicitly reduced in order to allow a protocol to advance into
+
+
+
+IAB                                                            [Page 12]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+         the Proposed Standard state.  This can happen if the
+         specification is considered to be useful and necessary (and
+         timely), even absent the missing features.  For example, some
+         protocols have been advanced by explicitly deciding to omit
+         security features at the Proposed Standard level, since an
+         overall security architecture was still under development.
+
+      3.2.2. Draft Standard
+
+         A specification from which at least two independent and
+         interoperable implementations have been developed, and for
+         which adequate operational experience has been obtained, may be
+         elevated to the "Draft Standard" level.  This is a major
+         advance in status, indicating a strong belief that the
+         specification is mature and will be useful.
+
+         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.
+
+      3.2.3. Standard
+
+         A specification for which significant implementation and
+         operational experience has been obtained may be elevated to the
+         Standard level.  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.
+
+   3.3. Non-Standards Track Maturity Levels
+
+      Not every TS or AS is on the standards track.  A TS 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 TS or AS may have been superseded by more recent
+      Internet Standards, or have otherwise fallen into disuse or
+      disfavor.  Such specifications are labeled with one of three
+      "non-standards track" maturity levels: "Historic", "Experimental",
+      and "Informational".
+
+      3.3.1. Historic
+
+         A TS or AS that has been superseded by a more recent
+         specification or is for any other reason considered to be
+
+
+
+IAB                                                            [Page 13]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+         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.)
+
+      3.3.2. Experimental
+
+         The "Experimental" designation on a TS permits widespread
+         dissemination (through publication according to the procedures
+         defined by this document) with explicit caveats:  it may
+         specify behavior that has not been thoroughly analyzed or is
+         poorly understood;  it may be subject to considerable change;
+         it may never be a candidate for the formal standards track;
+         and it may be discarded in favor of some other proposal.
+
+         Any TS that is not an immediate candidate for Internet
+         standardization is appropriate for publication as Experimental.
+         Interested parties are thereby given the opportunity to gain
+         experience with implementations and to report their findings to
+         the community of interest, but the specification is explicitly
+         not recommended for general production use.
+
+      3.3.3. Informational
+
+         An "Informational" specification is published for the general
+         information of the Internet community, and does not represent
+         an Internet community consensus or recommendation.
+
+         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 4 may be published
+         as Informational RFCs, with the permission of the owner.  Such
+         a document is not an Internet Standard in any sense.
+
+   3.4.  Requirement Levels
+
+      An AS may 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
+
+
+
+IAB                                                            [Page 14]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+           protocols of Recommended TSs in their products, and should
+           omit them only if the omission is justified by some special
+           circumstance.
+
+      (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.
+
+      As noted in Section 2.5, 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
+      such TSs:
+
+      (d)  Limited Use:  The TS is considered 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.
+
+      The "IAB Official Protocol Standards" RFC lists a general
+      requirement level for each TS, using the nomenclature defined in
+      this section.  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.  EXTERNAL STANDARDS AND SPECIFICATIONS
+
+   Many de facto and de jure standards groups other than the IAB/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
+
+        Accredited national and international standards bodies, such as
+
+
+
+IAB                                                            [Page 15]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+        ANSI, ISO, IEEE, and CCITT, develop a variety of protocol and
+        service specifications that are similar to Technical
+        Specifications (see glossary in Appendix A).  These
+        specifications are generally de jure standards.  Similarly,
+        national and international groups publish "implementors'
+        agreements" that are analogous to Applicability Statements,
+        capturing a body of implementation-specific detail concerned
+        with the practical application of their standards.
+
+   (2)  Vendor Specifications
+
+        A vendor-specific specification that has come to be widely used
+        in the Internet may be treated by the Internet community as a de
+        facto "standard".  Such a specification is not generally
+        developed in an open fashion, is typically proprietary, and is
+        controlled by the vendor or vendors that produced it.
+
+   To avoid conflict between competing versions of a specification, the
+   Internet community will not standardize a TS or AS that is simply an
+   "Internet version" of an existing external specification, unless an
+   explicit cooperative arrangement to do so has been made.  There are,
+   however, 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:
+
+   (a)  Incorporation of an Open Standard
+
+        An Internet Standard TS or AS may incorporate an open external
+        standard by reference.  The reference must be to a specific
+        version of the external standard, e.g., by publication date or
+        by edition number, according to the prevailing convention of the
+        organization that is responsible for the specification.
+
+        For example, many Internet Standards incorporate by reference
+        the ANSI standard character set "ASCII" [7].
+
+   (b)  Incorporation of a Vendor Specification
+
+        Vendor-proprietary specifications may also be incorporated, by
+        reference to a specific version of the vendor standard.  If the
+        vendor-proprietary specification is not widely and readily
+        available, the IAB may request that it be published as an
+        Informational RFC.
+
+        In order for a vendor-proprietary specification to be
+        incorporated within the Internet standards process, the
+        proprietor must agree in writing to the IAB that "right to use"
+        licenses will be available on a non-discriminatory basis and at
+
+
+
+IAB                                                            [Page 16]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+        a reasonable cost.  See also Sections 5 and 6.
+
+        In addition, the IAB/IETF will generally not favor a particular
+        vendor's proprietary specification over the technically
+        equivalent and competing specifications of other vendors by
+        making it "required" or "recommended".
+
+   (c)  Assumption
+
+        An IETF Working Group may start with a vendor's (or other
+        body's) voluntarily contributed specification, and independently
+        evolve the specification into a TS or AS.  Here "independently"
+        means that the IETF work is not constrained by conditions
+        imposed by the owner of the original specification;  however,
+        the continued participation of the original owner in the IETF
+        work is likely to be valuable, and is encouraged.  The IAB must
+        receive a formal delegation of responsibility from the original
+        owner that gives the IAB/IETF responsibility for evolution of
+        the specification.
+
+   As provided by section 3.1.2, an AS that specifies how an external
+   technical specification should be applied in the Internet,
+   incorporating the external specification by reference, may become an
+   Internet Standard.
+
+5.  INTELLECTUAL PROPERTY RIGHTS
+
+   Prior to the approval of a specification as a Proposed Standard, all
+   interested parties are required to disclose to the IAB the existence
+   of any intellectual property right claims known to them that might
+   apply to any aspect of the Proposed Standard.
+
+   This requirement refers specifically to disclosure of the *existence*
+   of a current or anticipated claim of an intellectual property right,
+   not the details of the asserted right itself.
+
+6.  PATENT POLICY
+
+   This section is tentative, subject to legal review.
+
+   There is no objection in principle to drafting an Internet Standard
+   in terms that include an item or items subject to patent rights that
+   may have been asserted in one or more countries, if it is considered
+   that technical reasons justify this approach.  In such cases the
+   procedure described in this section shall be followed.
+
+
+
+
+
+
+IAB                                                            [Page 17]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+   6.1 Statement from Patent Holder
+
+      Prior to approval of the specification as a Proposed Standard, the
+      IAB shall receive from the known patent holders, in a form
+      acceptable to and approved by the IAB, either (a) assurance in the
+      form of a general disclaimer to the effect that the patent holder
+      does not hold and does not anticipate holding any right that would
+      be violated as a consequence of conformance to the standard, or
+      (b) assurance that
+
+      (1)  a license will be made available without compensation to all
+           applicants desiring to utilize the patented items for the
+           purpose of implementing the standard, or
+
+      (2)  a license will be made available to applicants under
+           specified reasonable terms and conditions that are, to the
+           satisfaction of the IAB, demonstrably free of any unfair
+           discrimination.
+
+      The terms and conditions of any license falling under (1) or (2)
+      shall be submitted to the IAB for review, together with a
+      statement of the number of independent licenses, if any, that have
+      accepted or indicated their acceptance of the terms and conditions
+      of the license.
+
+      In addition, the letter to the IAB must contain (c) assurance that
+      the patent holder does have the right to grant the license, and
+      (d) a notification of any other patent licenses that are required,
+      or else the assurance that no other licenses are required.
+
+   6.2  Record of Statement
+
+      A record of the patent holder's statement (and a statement from
+      the IAB of the basis for considering such terms and conditions to
+      be free of any unfair discrimination) shall be placed and retained
+      in the files of the IAB.
+
+   6.3  Notice
+
+      When the IAB receives from a patent holder the assurance set forth
+      in section 5.1(1) or 5.1(2), the corresponding Internet Standard
+      shall include a note as follows:
+
+      "NOTE:  The user's attention is called to the possibility that
+      compliance with this standard may require the use of an invention
+      or work covered by patent claims.
+
+      "By publication of this standard, no position is taken with
+
+
+
+IAB                                                            [Page 18]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+      respect to the validity of this claim or of any patent rights in
+      connection therewith.  The patent holder has, however, filed a
+      statement of willingness to grant a license under these rights, on
+      reasonable and nondiscriminatory terms and conditions, to
+      applicants desiring to obtain such a license.  Details may be
+      obtained from the IAB."
+
+   6.4  Identifying Patents
+
+      The IAB shall not be responsible for identifying all patents for
+      which a license may be required by an Internet Standard, nor for
+      conducting inquiries into the legal validity or scope of those
+      patents that are brought to its attention.
+
+7.  ACKNOWLEDGMENTS AND REFERENCES
+
+   This document represents the combined output of the Internet
+   Activities Board and the Internet Engineering Steering Group, the
+   groups charged with managing the processes described in this
+   document.  Major contributions to the text were made by Bob Braden,
+   Vint Cerf, Lyman Chapin, Dave Crocker, and Barry Leiner.  Helpful
+   comments and suggestions were made by a number of IETF members.
+
+   [1]  Cerf, V., "The Internet Activities Board", RFC 1160, IAB, May
+        1990.
+
+   [2]  Postel, J., "IAB Official Protocol Standards", RFC 1280, IAB,
+        March 1992.
+
+   [3]  Braden, R., Editor, "Requirements for Internet Hosts --
+        Communication Layers", RFC 1122, IETF, October 1989.
+
+   [4]  Braden, R., Editor, "Requirements for Internet Hosts --
+        Application and Support", RFC 1123, IETF, October 1989.
+
+   [5]  Almquist, P., Editor, "Requirements for IP Routers", in
+        preparation.
+
+   [6]  Hinden, R., "Internet Engineering Task Force Internet Routing
+        Protocol Standardization Criteria", RFC 1264, BBN, October 1991.
+
+   [7]  ANSI, Coded Character Set -- 7-Bit American Standard Code for
+        Information Interchange, ANSI X3.4-1986.
+
+   [8]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, ISI,
+        March 1990.
+
+
+
+
+
+IAB                                                            [Page 19]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+   [9]  Postel, J., "Introduction to the STD Notes", RFC 1311, ISI,
+        March 1992.
+
+APPENDIX A: GLOSSARY
+
+   ANSI:  American National Standards Institute
+
+   CCITT: Consultative Committee for International Telephone and
+             Telegraphy.
+
+             A part of the UN Treaty Organization: the International
+             Telecommunications Union (ITU).
+
+   DARPA: (U.S.) Defense Advanced Research Projects Agency
+
+   ISO:   International Organization for Standardization
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                                                            [Page 20]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+APPENDIX B: FUTURE ISSUES
+
+   This memo resulted from an effort to document the current standards
+   procedures in the Internet community.  At the time of publication,
+   Sections 5 and 6 are still undergoing legal review.  In addition,
+   there are important issues under consideration of how to handle
+   copyrights and other issues of intellectual property.  This memo is
+   being published with these matters unresolved, due to its importance.
+
+   Pre-publication review of this document resulted in a number of
+   useful suggestions from members of the Internet community, and opened
+   up several new issues.  The IAB and IESG will continue to consider
+   these questions and attempt to resolve these issues; the results will
+   be be incorporated in future versions of this memo.
+
+   For future reference, this appendix records the outstanding
+   suggestions and issues.
+
+   It has been suggested that additional procedures in the following
+   areas should be considered.
+
+   o    Appeals Procedure
+
+        Should there be some formal appeals procedure for correcting
+        abuses or procedural failures, at each decision point in the
+        process?
+
+   o    Tracking Procedure
+
+        Should there be a formal procedure for tracking problems and
+        change requests, as a specification moves through the standards
+        track?  Such a procedure might include written responses, which
+        were cataloged and disseminated, or simply a database that
+        listed changes between versions.
+
+   o    Rationale Documentation
+
+        Should the procedures require written documentation of the
+        rationale for the design decisions behind each specification at
+        the Draft Standard and Standard levels?
+
+   o    Application-Layer Standards
+
+        Should there be some way to "standardize" application-layer
+        protocols that are not going to become Internet Standards?
+
+   There were suggestions for fine-tuning of the existing procedures:
+
+
+
+
+IAB                                                            [Page 21]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+   o    Increase minimum time in Internet Draft directory from 2 weeks
+        to 1 month.
+
+   o    Place explicit time limit, on IESG and IAB action on suggested
+        standards changes.  Limits suggested: three months.
+
+        If it were necessary to extend the time for some reason, the
+        IETF would have to be explicitly notified.
+
+   o    Change minimum time at Draft Standard from 4 to 5 months, to
+        ensure that an IETF meeting will intervene.
+
+   o    There were differing suggestions on how to balance between early
+        implementation of specifications available only as Internet
+        Drafts, and ensuring that everyone is clear that such an
+        Internet Draft has no official status and is subject to change
+        at any time.  One suggestion was that vendors should not claim
+        compliance with an Internet Draft.
+
+   Finally, there were suggestions for improvements in the documentation
+   of the standards procedures.
+
+   o    Discuss the impact, if any, of export control laws on the
+        Internet standardization process.
+
+        It was observed that the Requirements RFCs contain "negative"
+        requirement levels: MUST NOT and SHOULD NOT.  Such levels are
+        not recognized in this Procedures document.
+
+   o    Document needs to more clearly explain the criteria for choosing
+        the Experimental vs. Informational category for an off-track
+        specification.  Ref. sections 3.3.2, 3.3.4.
+
+   o    Develop recommended wording for citations to Internet Drafts,
+        which makes clear the provisional, unofficial nature of that
+        document.
+
+   o    Consider changing the name attached to a fully-adopted standard
+        from "Standard" to some qualified term like "Full Standard".
+
+   o    It has been suggested that the document should more strongly
+        encourage the use of specifications from other standards bodies,
+        with Internet-specific changes to be made only for compelling
+        reasons.  Further, the justification of the compelling
+        requirement would be subject to special review.
+
+
+
+
+
+
+IAB                                                            [Page 22]
+
+RFC 1310               Internet Standards Process             March 1992
+
+
+Security Considerations
+
+   Security issues are not substantially discussed in this memo.
+
+Author's Address
+
+   A. Lyman Chapin
+   BBN Communications Corporation
+   150 Cambridge Park Drive
+   Cambridge, MA  02140
+
+   Phone: 617-873-3133
+   Fax:   617-873-4086
+
+   Email: Lyman@BBN.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                                                            [Page 23]
+
\ No newline at end of file