summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1310.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1310.txt')
-rw-r--r--doc/rfc/rfc1310.txt1291
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