summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1602.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1602.txt')
-rw-r--r--doc/rfc/rfc1602.txt2001
1 files changed, 2001 insertions, 0 deletions
diff --git a/doc/rfc/rfc1602.txt b/doc/rfc/rfc1602.txt
new file mode 100644
index 0000000..004b7b7
--- /dev/null
+++ b/doc/rfc/rfc1602.txt
@@ -0,0 +1,2001 @@
+
+
+
+
+
+
+Network Working Group Internet Architecture Board and
+Request for Comments: 1602 Internet Engineering Steering Group
+Obsoletes: 1310 March 1994
+Category: Informational
+
+
+ The Internet Standards Process -- Revision 2
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Notice
+
+ This informational memo presents the current procedures for creating
+ and documenting Internet Standards. This document is provisional,
+ pending legal review and concurrence of the Internet Society
+ Trustees. It is being published in this form to keep the Internet
+ Community informed as to the current status of policies and
+ procedures for Internet Standards work.
+
+Abstract
+
+ This document is a revision of RFC 1310, which defined the official
+ procedures for creating and documenting Internet Standards.
+
+ This revision (revision 2) includes the following major changes:
+
+ (a) The new management structure arising from the POISED Working
+ Group is reflected. These changes were agreed to by the IETF
+ plenary and by the IAB and IESG in November 1992 and accepted by
+ the ISOC Board of Trustees at their December 1992 meeting.
+
+ (b) Prototype status is added to the non-standards track maturity
+ levels (Section 2.4.1).
+
+ (c) The Intellectual Property Rights section is completely revised,
+ in accordance with legal advice. Section 5 of this document
+ replaces Sections 5 and 6 of RFC-1310. The new section 5 has
+ been reviewed by legal counsel to the Internet Society.
+
+
+
+
+
+
+
+IAB - IESG [Page 1]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ (d) An appeals procedure is added (Section 3.6).
+
+ (e) The wording of sections 1 and 1.2 has been changed to clarify
+ the relationships that exist between the Internet Society and
+ the IAB, the IESG, the IETF, and the Internet Standards process.
+
+ (f) An Appendix B has been added, listing the contact points for the
+ RFC editor, the IANA, the IESG, the IAB and the ISOC. The
+ "future issues" are now listed in Appendix C.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB - IESG [Page 2]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+TABLE OF CONTENTS
+
+ 1. INTRODUCTION ................................................. 3
+ 1.1 Internet Standards. ...................................... 4
+ 1.2 Organizations ............................................ 6
+ 1.3 Standards-Related Publications ........................... 8
+ 1.4 Internet Assigned Number Authority (IANA) ................ 10
+ 2. NOMENCLATURE ................................................. 11
+ 2.1 The Internet Standards Track ............................. 11
+ 2.2 Types of Specifications .................................. 12
+ 2.3 Standards Track Maturity Levels .......................... 13
+ 2.4 Non-Standards Track Maturity Levels ...................... 15
+ 2.5 Requirement Levels ....................................... 17
+ 3. THE INTERNET STANDARDS PROCESS ............................... 19
+ 3.1 Review and Approval ...................................... 19
+ 3.2 Entering the Standards Track ............................. 20
+ 3.3 Advancing in the Standards Track ......................... 21
+ 3.4 Revising a Standard ...................................... 22
+ 3.5 Retiring a Standard ...................................... 22
+ 3.6 Conflict Resolution and Appeals .......................... 23
+ 4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 24
+ 5. INTELLECTUAL PROPERTY RIGHTS ................................. 26
+ 5.1. General Policy .......................................... 26
+ 5.2. Definitions ............................................. 26
+ 5.3 Trade Secret Rights ...................................... 27
+ 5.4. Rights and Permissions .................................. 27
+ 5.5. Notices ................................................. 30
+ 5.6. Assurances .............................................. 31
+ 6. REFERENCES ................................................... 34
+ APPENDIX A: GLOSSARY OF ACRONYMS ................................. 35
+ APPENDIX B: CONTACT POINTS ....................................... 35
+ APPENDIX C: FUTURE ISSUES ........................................ 36
+ Security Considerations .......................................... 37
+ Authors' Addresses ............................................... 37
+
+1. INTRODUCTION
+
+ This memo documents the process currently used by the Internet
+ community for the standardization of protocols and procedures. The
+ Internet Standards process is an activity of the Internet Society
+ that is organized and managed on behalf of the Internet community by
+ the Internet Architecture Board (IAB) and the Internet Engineering
+ Steering Group.
+
+
+
+
+
+
+IAB - IESG [Page 3]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ 1.1 Internet Standards
+
+ The Internet, a loosely-organized international collaboration of
+ autonomous, interconnected networks, supports host-to-host
+ communication through voluntary adherence to open protocols and
+ procedures defined by Internet Standards. There are also many
+ isolated internets, i.e., sets of interconnected networks, which
+ are not connected to the Internet but use the Internet Standards.
+
+ Internet Standards were once limited to those protocols composing
+ what has been commonly known as the "TCP/IP protocol suite".
+ However, the Internet has been evolving towards the support of
+ multiple protocol suites, especially the Open Systems
+ Interconnection (OSI) suite. The Internet Standards process
+ described in this document is concerned with all protocols,
+ procedures, and conventions that are used in or by the Internet,
+ whether or not they are part of the TCP/IP protocol suite. In the
+ case of protocols developed and/or standardized by non-Internet
+ organizations, however, the Internet Standards process may apply
+ only to the application of the protocol or procedure in the
+ Internet context, not to the specification of the protocol itself.
+
+ In general, an Internet Standard is a specification that is stable
+ and well-understood, is technically competent, has multiple,
+ independent, and interoperable implementations with substantial
+ operational experience, enjoys significant public support, and is
+ recognizably useful in some or all parts of the Internet.
+
+ The procedures described in this document are designed to be fair,
+ open and objective; to reflect existing (proven) practice; and to
+ be flexible.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB - IESG [Page 4]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ o These procedures are intended to provide a fair, open, and
+ objective basis for developing, evaluating, and adopting
+ Internet Standards. They provide ample opportunity for
+ participation and comment by all interested parties. At each
+ stage of the standardization process, a specification is
+ repeatedly discussed and its merits debated in open meetings
+ and/or public electronic mailing lists, and it is made
+ available for review via world-wide on-line directories.
+
+ o These procedures are explicitly aimed at recognizing and
+ adopting generally-accepted practices. Thus, a candidate
+ specification 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.
+
+ o These procedures provide a great deal of flexibility to adapt
+ to the wide variety of circumstances that occur in the
+ standardization process. Experience has shown this
+ flexibility to be vital in achieving the goals listed above.
+
+ The goal of technical competence, the requirement for prior
+ implementation and testing, and the need to allow all interested
+ parties to comment, all require significant time and effort. On
+ the other hand, today's rapid development of networking technology
+ places an urgency on timely development of standards. The
+ Internet standardization rules described here are intended to
+ balance these conflicting goals. The process is believed to be as
+ short and simple as possible without undue sacrifice of technical
+ competence, prior testing, or openness and fairness.
+
+ In summary, the goals for the Internet standards process are:
+
+ * technical excellence;
+
+ * prior implementation and testing;
+
+ * clear, short, and easily understandable documentation;
+
+ * openness and fairness; and
+
+ * timeliness.
+
+ 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
+
+
+
+IAB - IESG [Page 5]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ revision based upon experience, is adopted as a Standard by the
+ appropriate body (see below), and is published. In practice, the
+ process is more complicated, due to (1) the difficulty of creating
+ specifications of high technical quality; (2) the need to consider
+ the interests of all of the affected parties; (3) the importance
+ of establishing widespread community consensus; and (4) the
+ difficulty of evaluating the utility of a particular specification
+ for the Internet community.
+
+ From its inception, the Internet has been, and is expected to
+ remain, an evolving system whose participants regularly factor new
+ requirements and technology into its design and implementation.
+ Users of the Internet and providers of the equipment, software,
+ and services that support it should anticipate and embrace this
+ evolution as a major tenet of Internet philosophy.
+
+ 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 improving these
+ procedures.
+
+ The remainder of this section describes the organizations and
+ publications involved in Internet standardization. Section 2
+ presents the nomenclature for different kinds and levels of
+ Internet standard technical specifications and their
+ applicability. Section 3 describes the process and rules for
+ Internet standardization. Section 4 defines how relevant
+ externally-sponsored specifications and practices, developed and
+ controlled by other standards bodies or by vendors, are handled in
+ the Internet standardization process. Section 5 presents the
+ rules that are required to protect intellectual property rights
+ and to assure unrestricted ability for all interested parties to
+ practice Internet Standards.
+
+ 1.2 Organizations
+
+ The following organizations are involved in the Internet standards
+ process.
+
+ * IETF
+
+ The Internet Engineering Task Force (IETF) is a loosely self-
+ organized group of people who make technical and other
+ contributions to the engineering and evolution of the
+ Internet and its technologies. It is the principal body
+
+
+
+IAB - IESG [Page 6]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ engaged in the development of new Internet Standard
+ specifications, although it is not itself a part of the
+ Internet Society. The IETF is composed of individual Working
+ Groups, which are grouped into Areas, each of which is
+ coordinated by one or more Area Directors. Nominations to
+ the Internet Architecture Board and the Internet Engineering
+ Steering Group are made by a nominating committee selected at
+ random from the ranks of regular IETF meeting attendees who
+ have volunteered to serve as nominating committee members.
+
+ * ISOC
+
+ Internet standardization is an organized activity of the
+ Internet Society (ISOC). The ISOC is a professional society
+ that is concerned with the growth and evolution of the
+ worldwide Internet, with the way in which the Internet is and
+ can be used, and with the social, political, and technical
+ issues that arise as a result. The ISOC Board of Trustees is
+ responsible for approving appointments to the Internet
+ Architecture Board from among the nominees submitted by the
+ IETF nominating committee.
+
+ * IESG
+
+ The Internet Engineering Steering Group (IESG) is responsible
+ for technical management of IETF activities and the Internet
+ Standards process. As part of the Internet Society, it
+ administers the Internet Standards process according to the
+ rules and procedures given in this document, which have been
+ accepted and ratified by the Internet Society Trustees. The
+ IESG is directly responsible for the actions associated with
+ entry into and movement along the "standards track", as
+ described in section 3 of this document, including final
+ approval of specifications as Internet Standards. The IESG
+ is composed of the IETF Area Directors and the chairperson of
+ the IETF, who also serves as the chairperson of the IESG.
+
+ * IAB
+
+ The Internet Architecture Board (IAB) is a technical advisory
+ group of the Internet Society. It is chartered by the
+ Internet Society Trustees to provide oversight of the
+ architecture of the Internet and its protocols, and to serve
+ in the context of the Internet Standards process as a body to
+ which the decisions of the IESG may be appealed (as described
+ in section 3.6 of this document). The IAB is responsible for
+
+
+
+IAB - IESG [Page 7]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ approving appointments to the IESG from among the nominees
+ submitted by the IETF nominating committee.
+
+ Any member of the Internet community with the time and interest is
+ urged to participate actively in one or more IETF Working Groups
+ and to attend IETF meetings. In many cases, active Working Group
+ participation is possible through email alone; furthermore,
+ Internet video conferencing is being used experimentally to allow
+ remote participation. 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;
+ IETF participants recognize that the greatest benefit for all
+ members of the Internet community results from cooperative
+ development of technically superior protocols and services.
+
+ Members of the IESG and IAB are nominated for two-year terms by a
+ committee that is drawn from the roll of recent participation in
+ the IETF and chartered by the ISOC Board of Trustees. The
+ appointment of IESG and of IAB members are made from these
+ nominations by the IAB and by the ISOC Board of Trustees,
+ respectively.
+
+ The Internet Research Task Force (IRTF) is not directly part of
+ the standards process. It 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, the specification is
+ processed through the IETF using the rules in this document.
+
+ 1.3 Standards-Related Publications
+
+ 1.3.1 Requests for Comments (RFCs)
+
+ Each distinct version of a specification is published as part
+ of the "Request for Comments" (RFC) document series. This
+ archival series is the official publication channel for
+ Internet standards documents and other publications of the
+ IESG, IAB, and Internet community. RFCs are available for
+ anonymous FTP from a number of Internet hosts.
+
+ The RFC series of documents on networking began in 1969 as part
+ of the original ARPA wide-area networking (ARPANET) project
+ (see Appendix A for glossary of acronyms). RFCs cover a wide
+ range of topics, from early discussion of new research concepts
+
+
+
+IAB - IESG [Page 8]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ to status memos about the Internet. RFC publication is the
+ direct responsibility of the RFC Editor, under the general
+ direction of the IAB.
+
+ The rules for formatting and submitting an RFC are defined in
+ reference [5]. Every RFC is available in ASCII text, but some
+ RFCs are also available in PostScript. The PostScript version
+ of an RFC may contain material (such as diagrams and figures)
+ that is not present in the ASCII version, and it may be
+ formatted differently.
+
+ *********************************************************
+ * A stricter requirement applies to standards-track *
+ * specifications: the ASCII text version is the *
+ * definitive reference, and therefore it must be a *
+ * complete and accurate specification of the standard, *
+ * including all necessary diagrams and illustrations. *
+ * *
+ *********************************************************
+
+ The status of Internet protocol and service specifications is
+ summarized periodically in an RFC entitled "Internet Official
+ Protocol Standards" [1]. This RFC shows the level of maturity
+ and other helpful information for each Internet protocol or
+ service specification. See Section 3.1.3 below.
+
+ Some RFCs document Internet standards. These RFCs form the
+ 'STD' subseries of the RFC series [4]. When a specification
+ has been adopted as an Internet Standard, it is given the
+ additional label "STDxxxx", but it keeps its RFC number and its
+ place in the RFC series.
+
+ 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 and the
+ IESG. These RFCs will be marked "Prototype", "Experimental" or
+ "Informational" as appropriate (see section 2.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 *
+ * Internet Standard. *
+ ********************************************************
+
+
+
+IAB - IESG [Page 9]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ 1.3.2 Internet Drafts
+
+ During the development of a specification, draft versions of
+ the document are made available for informal review and comment
+ by placing them in the IETF's "Internet Drafts" directory,
+ which is replicated on a number of Internet hosts. This makes
+ an evolving working document readily available to a wide
+ audience, facilitating the process of review and revision.
+
+ An Internet Draft that is published as an RFC, or that has
+ remained unchanged in the Internet Drafts directory for more
+ than six months without being recommended by the IESG for
+ publication as an RFC, is simply removed from the Internet
+ Draft directory. At any time, an Internet Draft may be
+ replaced by a more recent version of the same specification,
+ restarting the six-month timeout period.
+
+ An Internet Draft is NOT a means of "publishing" a
+ specification; specifications are published through the RFC
+ mechanism described in the previous section. Internet Drafts
+ have no formal status, are not part of the permanent archival
+ record of Internet activity, and are subject to change or
+ removal at any time.
+
+ ********************************************************
+ * Under no circumstances should an Internet Draft *
+ * be referenced by any paper, report, or Request-for-*
+ * Proposal, nor should a vendor claim compliance *
+ * with an Internet-Draft. *
+ ********************************************************
+
+ Note: It is acceptable to reference a standards-track
+ specification that may reasonably be expected to be published
+ as an RFC using the phrase "Work in Progress", without
+ referencing an Internet Draft.
+
+ 1.4 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" [3].
+
+
+
+
+IAB - IESG [Page 10]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ 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. Note that assignment of a
+ number to a protocol is independent of, and does not imply,
+ acceptance of that protocol as a standard.
+
+ 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 to guess the next unassigned value of a
+ parameter; both are hazardous.
+
+ The IANA is expected 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.
+
+2. NOMENCLATURE
+
+ 2.1 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.
+
+
+
+IAB - IESG [Page 11]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ 2.2 Types of Specifications
+
+ Specifications subject to the Internet standardization process
+ fall into two categories: Technical Specifications (TS) and
+ Applicability Statements (AS).
+
+ 2.2.1 Technical Specification (TS)
+
+ A Technical Specification is any description of a protocol,
+ service, procedure, convention, or format. It may completely
+ describe all of the relevant aspects of its subject, or it may
+ leave one or more parameters or options unspecified. A TS may
+ be completely self-contained, or it may incorporate material
+ from other specifications by reference to other documents
+ (which 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.
+
+ 2.2.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
+
+
+
+IAB - IESG [Page 12]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ particular class of Internet systems, such as Internet routers
+ or Internet hosts.
+
+ An AS may not have a higher maturity level in the standards
+ track than any standards-track TS 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 by
+ an AS at the Standard level.
+
+ An AS may refer to a TS that is either a standards-track speci-
+ fication or is "Informational", but not to a TS with a maturity
+ level of "Prototype", "Experimental", or "Historic" (see
+ section 2.4).
+
+ Although TSs and ASs are conceptually separate, in practice a
+ standards-track document may combine an AS and one or more related
+ TSs. For example, Technical Specifications that are developed
+ specifically and exclusively for some particular domain of
+ applicability, e.g., for mail server hosts, often contain within a
+ single specification all of the relevant AS and TS information.
+ In such cases, no useful purpose would be served by deliberately
+ distributing the information among several documents just to
+ preserve the formal AS/TS distinction. However, a TS that is
+ likely to apply to more than one domain of applicability should be
+ developed in a modular fashion, to facilitate its incorporation by
+ multiple ASs.
+
+ 2.3 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.
+
+ 2.3.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. However, further experience might result in a change
+ or even retraction of the specification before it advances.
+
+
+
+
+IAB - IESG [Page 13]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ Usually, neither implementation nor operational experience is
+ required for the designation of a specification as a Proposed
+ Standard. However, such experience is highly desirable, and
+ will usually represent a strong argument in favor of a Proposed
+ Standard designation.
+
+ The IESG may require implementation and/or operational
+ experience prior to granting Proposed Standard status to a
+ specification that materially affects the core Internet
+ protocols or that specifies behavior that may have significant
+ operational impact on the Internet. Typically, such a
+ specification will be published initially with Experimental or
+ Prototype status (see below), 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. However, the
+ IESG may recommend that this requirement be explicitly reduced
+ in order to allow a protocol to advance into the Proposed
+ Standard state, when a specification is considered to be useful
+ and necessary (and timely), even absent the missing features.
+
+ Implementors should treat Proposed Standards as immature
+ specifications. It is desirable to implement them in order to
+ gain experience and to validate, test, and clarify the
+ specification. However, since the content of Proposed
+ Standards may be changed if problems are found or better
+ solutions are identified, deploying implementations of such
+ standards into a disruption-sensitive customer base is not
+ normally advisable.
+
+ 2.3.2 Draft Standard
+
+ A specification from which at least two independent and
+ interoperable implementations have been developed, and for
+ which sufficient successful 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
+
+
+
+IAB - IESG [Page 14]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ demonstrate unforeseen behavior when subjected to large-scale
+ use in production environments.
+
+ 2.3.3 Internet Standard
+
+ A specification for which significant implementation and
+ successful operational experience has been obtained may be
+ elevated to the Internet Standard level. An Internet Standard
+ (which may simply be referred to as a Standard) is
+ characterized by a high degree of technical maturity and by a
+ generally held belief that the specified protocol or service
+ provides significant benefit to the Internet community.
+
+ A Draft Standard is normally considered to be a final
+ specification, and changes are likely to be made only to solve
+ specific problems encountered. In most circumstances, it is
+ reasonable for vendors to deploy implementations of draft
+ standards into the customer base.
+
+ 2.4 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.
+
+ Specifications not on the standards track are labeled with one of
+ four off-track maturity levels: "Prototype, "Experimental",
+ "Informational", and "Historic". There are no time limits
+ associated with these non-standard track labels, and the documents
+ bearing these labels are not Internet standards in any sense. As
+ the Internet grows, there is a growing amount of credible
+ technical work being submitted directly to the RFC Editor without
+ having been gone through the IETF. It is possible that such
+ outside submissions may overlap or even conflict with ongoing IETF
+ activities. In order for the best technical result to emerge for
+ the community, we believe that the such outside submissions should
+ be given the opportunity to work within IETF to gain the broadest
+ possible consensus.
+
+ It is also possible that supporters of a view different from the
+ IETF may wish to publish their divergent view. For this reason,
+ it is important that, ultimately, authors should have the
+ opportunity to publish Informational and Experimental RFCs should
+
+
+
+IAB - IESG [Page 15]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ they wish to. However, it is also possible that this could open a
+ loophole in which developers could try to bypass the IETF
+ consensus process completely by publishing an Informational RFC
+ (and relying on the prestige of the RFC series to gain community
+ support for their document).
+
+ For all these reasons, the IESG and the RFC Editor have agreed to
+ the following policy for publishing Info and Exp RFCs:
+
+ 1. The RFC Editor will bring to the attention of the IESG all
+ Informational and Experimental submissions that the RFC
+ Editor feels may be related to, or of interest to, the IETF
+ community.
+
+ 2. The IESG will review all such referrals within a fixed length
+ of time and make a recommendation on whether to publish, or
+ to suggest that the author bring their work within the IETF.
+
+ 3. If the IESG recommends that the work be brought within the
+ IETF, but the author declines the invitation, the IESG may
+ add disclaimer text into the standard boilerplate material
+ added by the RFC Editor (e.g., "Status of this memo").
+
+ 2.4.1 Prototype
+
+ For new protocols which affect core services of the
+ Internet or for which the interactions with existing
+ protocols are too complex to fully assimilate from the
+ written specification, the IESG may request that
+ operational experience be obtained prior to advancement to
+ Proposed Standard status. In these cases, the IESG will
+ designate an otherwise complete specification as
+ "Prototype". This status permits it to be published as an
+ RFC before it is entered onto the standards track. In
+ this respect, "Prototype" is similar to "Experimental",
+ except that it indicates the protocol is specifically
+ being developed to become a standard, while "Experimental"
+ generally indicates a more exploratory phase of
+ development.
+
+ 2.4.2 Experimental
+
+ The "Experimental" designation on a TS typically denotes a
+ specification that is part of some research or development
+ effort. Such a specification is published for the general
+ information of the Internet technical community and as an
+
+
+
+IAB - IESG [Page 16]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ archival record of the work. An Experimental
+ specification may be the output of an organized Internet
+ research effort (e.g., a Research Group of the IRTF), or
+ it may be an individual contribution.
+
+ Documents intended for Experimental status should be
+ submitted directly to the RFC Editor for publication. The
+ procedure is intended to expedite the publication of any
+ responsible Experimental specification, subject only to
+ editorial considerations, and to verification that there
+ has been adequate coordination with the standards process.
+
+ 2.4.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. The Informational designation is intended
+ to provide for the timely publication of a very broad
+ range of responsible informational documents from many
+ sources, subject only to editorial considerations and to
+ verification that there has been adequate coordination
+ with the standards process.
+
+ 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.
+
+ 2.4.4 Historic
+
+ A TS or AS that has been superseded by a more recent
+ specification or is for any other reason considered to be
+ obsolete is assigned to the "Historic" level. (Purists
+ have suggested that the word should be "Historical";
+ however, at this point the use of "Historic" is
+ historical.)
+
+ 2.5 Requirement Levels
+
+ An AS may apply one of the following "requirement levels" to
+ each of the TSs to which it refers:
+
+
+
+
+
+
+IAB - IESG [Page 17]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ (a) Required: Implementation of the referenced TS, as specified
+ by the AS, is required to achieve minimal conformance. For
+ example, IP and ICMP must be implemented by all Internet
+ systems using the TCP/IP Protocol Suite.
+
+ (b) Recommended: Implementation of the referenced TS is not
+ required for minimal conformance, but experience and/or
+ generally accepted technical wisdom suggest its desirability
+ in the domain of applicability of the AS. Vendors are
+ strongly encouraged to include the functions, features, and
+ protocols of Recommended TSs in their products, and should
+ omit them only if the omission is justified by some special
+ circumstance.
+
+ (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.4, 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 "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.
+
+
+
+
+
+
+IAB - IESG [Page 18]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+3. THE INTERNET STANDARDS PROCESS
+
+ 3.1 Review and Approval
+
+ A "standards action" -- entering a particular specification into,
+ advancing it within, or removing it from, the standards track --
+ must be approved by the IESG.
+
+ 3.1.1 Initiation of Action
+
+ Typically, a standards action is initiated by a recommendation
+ to the appropriate IETF Area Director by the individual or
+ group that is responsible for the specification, usually an
+ IETF Working Group.
+
+ 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 with a recommendation for action.
+
+ 3.1.2 IESG Review and Approval
+
+ 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).
+
+ The IESG shall determine if an independent technical review of
+ the specification is required, and shall commission one when
+ necessary. This may require creating a new Working Group, or
+ an existing group may agree to take responsibility for
+ reviewing the specification. 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 an independent technical 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.
+
+ The IESG shall communicate its findings to the IETF to permit a
+ final review by the general Internet community. This "last-
+ call" notification shall be via electronic mail to the IETF
+ mailing list. In addition, for important specifications there
+
+
+
+IAB - IESG [Page 19]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ shall 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.
+
+ In a timely fashion, but no sooner than two weeks after issuing
+ the last-call notification to the IETF mailing list, the IESG
+ shall make its final determination on whether or not to approve
+ the standards action, and shall notify the IETF of its decision
+ via email.
+
+ 3.1.3 Publication
+
+ Following IESG 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.
+
+ An official summary of standards actions completed and pending
+ shall appear in each issue of the Internet Society Newsletter.
+ This shall constitute the "journal of record" for Internet
+ standards actions. In addition, the IESG shall publish a
+ monthly summary of standards actions completed and pending in
+ the Internet Monthly Report, which is distributed to all
+ members of the IETF mailing list.
+
+ Finally, the IAB shall publish quarterly an "Internet Official
+ Protocol Standards" RFC, summarizing the status of all Internet
+ protocol and service specifications, both within and outside
+ the standards track.
+
+ 3.2 Entering the Standards Track
+
+ A specification that is potentially an Internet Standard may
+ originate from:
+
+ (a) an ISOC-sponsored effort (typically an IETF Working Group),
+
+ (b) independent activity by individuals, or
+
+ (c) an external organization.
+
+ Case (a) accounts for the great majority of specifications that
+ enter the standards track. In cases (b) and (c), the work might
+ be tightly integrated with the work of an existing IETF Working
+
+
+
+IAB - IESG [Page 20]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ 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 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. Ad hoc review committees may also be convened
+ in other circumstances when the nature of review required is too
+ small to require the formality of Working Group creation. 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.
+
+ 3.3 Advancing in the Standards Track
+
+ A specification shall remain at the Proposed Standard level for at
+ least six (6) months.
+
+ A specification shall remain at the Draft Standard level for at
+ least four (4) months, or until at least one IETF meeting has
+ occurred, whichever comes later.
+
+ These minimum periods are intended to ensure adequate opportunity
+ for community review without severely impacting timeliness. These
+ intervals shall be measured from the date of publication of the
+ corresponding RFC(s), or, if the action does not result in RFC
+ publication, the date of IESG approval of the action.
+
+ A specification may be (indeed, is likely to be) revised as it
+ advances through the standards track. At each stage, the IESG
+ shall determine the scope and significance of the revision to the
+ specification, and, if necessary and appropriate, modify the
+ recommended action. Minor revisions are expected, but a
+ significant revision may require that the specification accumulate
+ more experience at its current maturity level before progressing.
+ Finally, if the specification has been changed very significantly,
+ the IESG may recommend that the revision be treated as a new
+ document, re-entering the standards track at the beginning.
+
+
+
+IAB - IESG [Page 21]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ Change of status shall result in republication of the
+ specification as an RFC, except in the rare case that there have
+ been no changes at all in the specification since the last
+ publication. Generally, desired changes will be "batched" for
+ incorporation at the next level in the standards track. However,
+ deferral of changes to the next standards action on the
+ specification will not always be possible or desirable; for
+ example, an important typographical error, or a technical error
+ that does not represent a change in overall function of the
+ specification, may need to be corrected immediately. In such
+ cases, the IESG or RFC Editor may be asked to republish the RFC
+ with corrections, and this will not reset the minimum time-at-
+ level clock.
+
+ When a standards-track specification has not reached the Internet
+ Standard level but has remained at the same status level for
+ twenty-four (24) months, and every twelve (12) months thereafter
+ until the status is changed, the IESG shall review the viability
+ of the standardization effort responsible for that specification.
+ Following each such review, the IESG shall approve termination or
+ continuation of the development. This decision 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 a legitimate and active
+ Working Group effort, but rather to provide an administrative
+ mechanism for terminating a moribund effort.
+
+ 3.4 Revising a Standard
+
+ A new version of an established Internet Standard must progress
+ through the full Internet standardization process as if it were a
+ completely new specification. Once the new version has reached
+ the Standard level, it will usually replace the previous version,
+ which will move to Historic status. However, in some cases both
+ versions may remain as Internet Standards to honor the
+ requirements of an installed base. In this situation, the
+ relationship between the previous and the new versions must be
+ explicitly stated in the text of the new version or in another
+ appropriate document (e.g., an Applicability Statement; see
+ Section 2.2.2).
+
+ 3.5 Retiring a Standard
+
+ As the technology changes and matures, it is possible for a new
+ Standard specification to be so clearly superior technically that
+ one or more existing Internet Standards for the same function
+
+
+
+IAB - IESG [Page 22]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ should be retired. In this case, the IESG shall approve a change
+ of status of the superseded specification(s) from Standard to
+ Historic. This recommendation shall be issued with the same
+ Last-Call and notification procedures used for any other standards
+ action.
+
+ 3.6 Conflict Resolution and Appeals
+
+ IETF Working Groups are generally able to reach consensus, which
+ sometimes requires difficult compromises between differing
+ technical solutions. However, there are times when even
+ reasonable and knowledgeable people are unable to agree. To
+ achieve the goals of openness and fairness, such conflicts must be
+ resolved with a process of open review and discussion.
+ Participants in a Working Group may disagree with Working Group
+ decisions, based either upon the belief that their own views are
+ not being adequately considered or the belief that the Working
+ Group made a technical choice which essentially will not work.
+ The first issue is a difficulty with Working Group process, and
+ the latter is an assertion of technical error. These two kinds of
+ disagreements may have different kinds of final outcome, but the
+ resolution process is the same for both cases.
+
+ Working Group participants always should first attempt to discuss
+ their concerns with the Working Group chair. If this proves
+ unsatisfactory, they should raise their concerns with an IESG Area
+ Director or other IESG member. In most cases, issues raised to
+ the level of the IESG will receive consideration by the entire
+ IESG, with the relevant Area Director or the IETF Chair being
+ tasked with communicating results of the discussion.
+
+ For the general community as well as Working Group participants
+ seeking a larger audience for their concerns, there are two
+ opportunities for explicit comment. (1) When appropriate, a
+ specification that is being suggested for advancement along the
+ standards track will be presented during an IETF plenary. At that
+ time, IETF participants may choose to raise issues with the
+ plenary or to pursue their issues privately, with any of the
+ relevant IETF/IESG management personnel. (2) Specifications that
+ are to be considered by the IESG are publicly announced to the
+ IETF mailing list, with a request for comments.
+
+ Finally, if a problem persists, the IAB may be asked to adjudicate
+ the dispute.
+
+
+
+
+
+IAB - IESG [Page 23]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ * If a concern involves questions of adequate Working Group
+ discussion, the IAB will attempt to determine the actual
+ nature and extent of discussion that took place within the
+ Working Group, based upon the Working Group's written record
+ and upon comments of other Working Group participants.
+
+ * If a concern involves questions of technical adequacy, the
+ IAB may convene an appropriate review panel, which may then
+ recommend that the IESG and Working Group re-consider an
+ alternate technical choice.
+
+ * If a concern involves a reasonable difference in technical
+ approach, but does not substantiate a claim that the Working
+ Group decision will fail to perform adequately, the Working
+ Group participant may wish to pursue formation of a separate
+ Working Group. The IESG and IAB encourage alternative points
+ of view and the development of technical options, allowing
+ the general Internet community to show preference by making
+ its own choices, rather than by having legislated decisions.
+
+
+4. EXTERNAL STANDARDS AND SPECIFICATIONS
+
+ Many standards groups other than the IETF create and publish
+ standards documents for network protocols and services. When these
+ external specifications play an important role in the Internet, it is
+ desirable to reach common agreements on their usage -- i.e., to
+ establish Internet Standards relating to these external
+ specifications.
+
+ There are two categories of external specifications:
+
+ (1) Open Standards
+
+ Accredited national and international standards bodies, such as
+ ANSI, ISO, IEEE, and ITU-TS, develop a variety of protocol and
+ service specifications that are similar to Technical
+ Specifications defined here. National and international groups
+ also publish "implementors' agreements" that are analogous to
+ Applicability Statements, capturing a body of implementation-
+ specific detail concerned with the practical application of
+ their standards.
+
+
+
+
+
+
+
+IAB - IESG [Page 24]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ (2) Vendor Specifications
+
+ A vendor-proprietary specification that has come to be widely
+ used in the Internet may be treated by the Internet community as
+ if it were a "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. However,
+ there are several ways in which an external specification that is
+ important for the operation and/or evolution of the Internet may be
+ adopted for Internet use.
+
+ (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" [2]. Whenever possible,
+ the referenced specification shall be made available online.
+
+ (b) Incorporation of a Vendor Specification
+
+ Vendor-proprietary specifications may be incorporated by
+ reference to a specific version of the vendor standard. If the
+ vendor-proprietary specification is not widely and readily
+ available, the IESG may request that it be published as an
+ Informational RFC.
+
+ For a vendor-proprietary specification to be incorporated within
+ the Internet standards process, the proprietor must meet the
+ requirements of section 5 below, and in general the
+ specification shall be made available online.
+
+ The IESG shall not favor a particular vendor's proprietary
+ specification over the technically equivalent and competing
+ specifications of other vendors by making it "required" or
+ "recommended".
+
+
+
+
+IAB - IESG [Page 25]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ (c) Assumption
+
+ An IETF Working Group may start from an external specification
+ and develop it into an Internet TS or AS. This is acceptable if
+ (1) the specification is provided to the Working Group in
+ compliance with the requirements of section 5 below, and (2)
+ change control has been conveyed to IETF by the original
+ developer of the specification. Continued participation in the
+ IETF work by the original owner is likely to be valuable, and is
+ encouraged.
+
+ The following sample text illustrates how a vendor might convey
+ change control to the Internet Society:
+
+ "XXXX Organization asserts that it has the right to transfer to
+ the Internet Society responsibility for further evolution of the
+ YYYY protocol documented in References (1-n) below. XXXX
+ Organization hereby transfers to the Internet Society
+ responsibility for all future modification and development of
+ the YYYY protocol, without reservation or condition."
+
+
+5. INTELLECTUAL PROPERTY RIGHTS
+
+ 5.1. General Policy
+
+ In all matters of intellectual property rights and procedures, the
+ intention is to benefit the Internet community and the public at
+ large, while respecting the legitimate rights of others.
+
+ 5.2. Definitions
+
+ As used in this section, the following terms have the indicated
+ meanings:
+
+ o "Trade secrets" are confidential, proprietary information.
+
+ o "Contribution" means any disclosure of information or ideas,
+ whether in oral, written, or other form of expression, by an
+ individual or entity ("Contributor").
+
+ o "Standards track documents" are specifications and other
+ documents that have been elevated to the Internet standards
+ track in accordance with the Internet Standards Process.
+
+
+
+
+
+IAB - IESG [Page 26]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ o "Copyrights" are purportedly valid claims to copyright in all
+ or part of a contribution to standards work, whether or not
+ the contribution becomes a standards track document,
+ including but not limited to any works by third parties that
+ the contribution is based on or incorporates.
+
+ o "ISOC" refers to the Internet Society and its trustees,
+ officers, employees, contractors, and agents, as well as the
+ IAB, IETF, IESG, IRTF, IRSG, and other task forces,
+ committees, and groups coordinated by the Internet Society.
+
+ o "Standards work" is work involved in the creation, testing,
+ development, revision, adoption, or maintenance of an
+ Internet standard that is carried out under the auspices of
+ ISOC.
+
+ o "Internet community" refers to the entire set of persons,
+ whether individuals or entities, including but not limited to
+ technology developers, service vendors, and researchers, who
+ use the Internet, either directly or indirectly, and users of
+ any other networks which implement and use Internet
+ Standards.
+
+ 5.3 Trade Secret Rights
+
+ Except as otherwise provided under this section, ISOC will not
+ accept, in connection with standards work, any idea, technology,
+ information, document, specification, work, or other contribution,
+ whether written or oral, that is a trade secret or otherwise
+ subject to any commitment, understanding, or agreement to keep it
+ confidential or otherwise restrict its use or dissemination; and,
+ specifically, ISOC does not assume any confidentiality obligation
+ with respect to any such contribution.
+
+ 5.4. Rights and Permissions
+
+ In the course of standards work, ISOC receives contributions in
+ various forms and from many persons. To facilitate the wide
+ dissemination of these contributions, it is necessary to establish
+ specific understandings concerning any copyrights, patents, patent
+ applications, or other rights in the contribution. The procedures
+ set forth in this section apply to contributions submitted after 1
+ April 1994. For Internet standards documents published before
+ this date (the RFC series has been published continuously since
+ April 1969), information on rights and permissions must be sought
+ directly from persons claiming rights therein.
+
+
+
+IAB - IESG [Page 27]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ 5.4.1. All Contributions
+
+ By submission of a contribution to ISOC, and in consideration
+ of possible dissemination of the contribution to the Internet
+ community, a contributor is deemed to agree to the following
+ terms and conditions:
+
+ l. Contributor agrees to grant, and does grant to ISOC, a
+ perpetual, non-exclusive, royalty-free, world-wide right
+ and license under any copyrights in the contribution to
+ reproduce, distribute, perform or display publicly and
+ prepare derivative works that are based on or incorporate
+ all or part of the contribution, and to reproduce,
+ distribute and perform or display publicly any such
+ derivative works, in any form and in all languages, and to
+ authorize others to do so.
+
+ 2. Contributor acknowledges that ISOC has no duty to publish
+ or otherwise use or disseminate every contribution.
+
+ 3. Contributor grants ISOC permission to reference the
+ name(s) and address(s) of the contributor as well as other
+ persons who are named as contributors.
+
+ 4. Where the contribution was prepared jointly with others,
+ or is a work for hire, the contributor represents and
+ warrants that the other owner(s) of rights have been
+ informed of the rights and permissions granted to ISOC and
+ that any required authorizations have been obtained.
+ Copies of any such required authorizations will be
+ furnished to ISOC, upon request.
+
+ 5. Contributor acknowledges and agrees that ISOC assumes no
+ obligation to maintain any confidentiality with respect to
+ any aspect of the contribution, and warrants that the the
+ contribution does not violate the rights of others.
+
+ 6. All material objects in which contributions are submitted
+ to ISOC become the property of ISOC and need not be
+ returned to the contributor.
+
+ Where appropriate, written confirmation of the above terms and
+ conditions will be obtained in writing by ISOC, usually by
+ electronic mail; however, a decision not to obtain such
+ confirmation in a given case shall not act to revoke the prior
+ grant of rights and permissions with respect to the
+
+
+
+IAB - IESG [Page 28]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ contribution as provided herein. Except as provided below, the
+ Executive Director of the IETF Secretariat, or a person
+ designated by the Executive Director, will be responsible for
+ obtaining written confirmations.
+
+ In the case of IETF Working Groups, the responsibility for
+ identifying the principal contributor(s) for purposes of
+ obtaining written confirmation of the above rights and
+ permissions will be assumed by the Editor or Chair of the
+ particular Group. While only those persons named as principal
+ contributor(s) will generally be requested to provide written
+ confirmation, it is the responsibility of all contributors to
+ standards work to inform the IETF Secretariat of any
+ proprietary claims in any contributions and to furnish the
+ Secretariat with any required confirmation.
+
+ Where any person participating in standards work asserts any
+ proprietary right in a contribution, it is the responsibility
+ of such person to so inform the Editor or Chair of the group,
+ promptly, in writing. The Editor or Chair will then determine
+ whether to list the person as a principal contributor, or to
+ revise the document to omit the particular contribution in
+ question.
+
+ 5.4.2. Standards Track Documents
+
+
+ (A) ISOC will not propose, adopt, or continue to maintain any
+ standards, including but not limited to standards labelled
+ Proposed, Draft or Internet Standards, which can only be
+ practiced using technology or works that are subject to
+ known copyrights, patents or patent applications, or other
+ rights, except with the prior written assurance of the
+ owner of rights that:
+
+ l. ISOC may, without cost, freely implement and use the
+ technology or works in its standards work;
+
+ 2. upon adoption and during maintenance of an Internet
+ Standard, any party will be able to obtain the right
+ to implement and use the technology or works under
+ specified, reasonable, non-discriminatory terms; and
+
+ 3. the party giving the assurance has the right and
+ power to grant the licenses and knows of no other
+ copyrights, patents, patent applications, or other
+
+
+
+IAB - IESG [Page 29]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ rights that may prevent ISOC and members of the
+ Internet community from implementing and operating
+ under the standard.
+
+ (B) ISOC disclaims any responsibility for identifying the
+ existence of or for evaluating any copyrights, patents,
+ patent applications, or other rights, on behalf of or for
+ the benefit of any member of the Internet community, and
+ ISOC takes no position on the validity or scope of any
+ such rights. Further, ISOC will take no position on the
+ ownership of inventions made during standards work, except
+ for inventions of which an employee or agent of the
+ Internet Society is a joint inventor. In the latter case,
+ the Internet Society will make its rights available under
+ license to anyone in the Internet community in accordance
+ with the written assurances set forth below.
+
+ 5.5. Notices
+
+ (A) When a written assurance has been obtained as set forth
+ below, the relevant standards track documents shall include
+ the following notice:
+
+ "__________(name of rights' owner) has provided written
+ assurance to the Internet Society that any party will be
+ able to obtain, under reasonable, nondiscriminatory
+ terms, the right to use the technology covered
+ by__________(list copyrights, patents, patent
+ applications, and other rights) to practice the
+ standard. A copy of this assurance may be obtained from
+ the Executive Director of the IETF Secretariat. The
+ Internet Society takes no position on the validity or
+ scope of the copyrights, patents, patent applications,
+ or other rights, or on the appropriateness of the terms
+ and conditions of the assurances. The Internet Society
+ does not make any representation there are no other
+ rights which may apply to the practice of this standard,
+ nor that it has made any effort to identify any such
+ rights. For further information on the Internet
+ Society's procedures with respect to rights in standards
+ and standards-related documentation, see RFC_____,
+ dated________."
+
+ (B) ISOC encourages all interested parties to bring to its
+ attention, at the earliest possible time, the existence of
+ any copyrights, patents, patent applications, or other rights
+
+
+
+IAB - IESG [Page 30]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ pertaining to Internet Standards. For this purpose, each
+ standards document will include the following invitation:
+
+ "The Internet Society invites any interested party to
+ bring to its attention any copyrights, patents or patent
+ applications, or other proprietary rights which purport
+ to cover technology or works that may be required to
+ practice this standard. Please address the information
+ to the Executive Director of the Internet Engineering
+ Task Force Secretariat."
+
+ (C) When applicable, the following sentence will be included in
+ the notice:
+
+ "As of __________, no information about any copyrights,
+ patents or patent applications, or other proprietary
+ rights has been received."
+
+ (D) The following copyright notice and disclaimer will be
+ included in all ISOC standards-related documentation:
+
+ "Copyright (c) ISOC (year date). Permission is granted
+ to reproduce, distribute, transmit and otherwise
+ communicate to the public any material subject to
+ copyright by ISOC, provided that credit is given to the
+ source. For information concerning required
+ permissions, please contact the Executive Director of
+ the Internet Engineering Task Force Secretariat."
+
+ ISOC hereby informs the Internet community and other
+ persons that any standards, whether or not elevated to
+ the Internet Standard level of maturity, or any
+ standards-related documentation made available under the
+ auspices of ISOC are provided on an "AS IS" basis and
+ ISOC DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTY OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, OR
+ THAT ANY STANDARD OR DOCUMENTATION DOES NOT VIOLATE THE
+ RIGHTS OF OTHERS.
+
+ 5.6. Assurances
+
+ The agreement on assurances set forth below will normally be
+ entered into between the owner of rights and ISOC at the time a
+ standards track document in which proprietary rights are claimed
+ reaches the "Proposed Standard" stage of maturity:
+
+
+
+IAB - IESG [Page 31]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ This is an agreement between ______________(hereinafter
+ called "Rights Holder") and the Internet Society on behalf of
+ itself and its trustees, officers, employees, contractors and
+ agents, the Internet Architecture Board, Internet Engineering
+ Steering Group, Internet Engineering Task Force, and other task
+ forces, committees and groups coordinated by the Internet Society
+ (hereinafter called "ISOC"), and for the benefit of all users of
+ the Internet and users of any other networks which implement and
+ use Internet Standards (hereinafter together with ISOC called
+ "Internet community"). This agreement takes effect when signed on
+ behalf of the Rights Holder and the Internet Society.
+
+ The Rights Holder represents that it has or will have rights
+ in patent applications, patents, copyrights, trade secrets, and
+ other proprietary rights in various countries (hereinafter called
+ "Rights") which may block or impede the ability of the Internet
+ community to implement and operate under the standards set forth
+ in ISOC standards document ____,____, and ____(the listed
+ standards and any similar or related standards now existing or
+ later developed are together hereinafter called "Standards"). The
+ Rights as they presently exist are listed on attached Schedule A.
+ The Rights Holder further agrees to review the Rights listed in
+ Schedule A from time to time, and, in particular, immediately
+ prior to the elevation of the Standards to the Internet Standard
+ level of maturity in accordance with the Internet Standards
+ Process, and to inform the Executive Director of the Internet
+ Engineering Task Force Secretariat promptly upon learning of any
+ new Rights in the Standards that should be added to the list in
+ Schedule A.
+
+ The Rights Holder believes and affirms that it will derive
+ benefits by permitting ISOC and the Internet community to
+ implement and operate under the Standards without interference of
+ any of the Rights. The policy of ISOC is not to propose, adopt,
+ or continue to maintain the Standards unless written assurances
+ are given by the Rights Holder with respect to proprietary rights.
+ Accordingly, in consideration of the benefits noted above and
+ other good and valuable consideration, the Rights Holder makes the
+ assurances set forth herein.
+
+ The Rights Holder grants to ISOC a cost-free, perpetual,
+ non-exclusive, world-wide license under the Rights with respect to
+ implementing and operating under the Standards. The license
+ extends to all activities of ISOC involving the Standards without
+ limit, including the rights to reproduce, distribute, propose,
+ test, develop, analyze, enhance, revise, adopt, maintain,
+
+
+
+IAB - IESG [Page 32]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ withdraw, perform and display publicly, and prepare derivative
+ works in any form whatsoever and in all languages, and to
+ authorize others to do so. The Rights Holder also grants ISOC
+ permission to use the name and address of Rights Holder in
+ connection with the Standards.
+
+ The Rights Holder relinquishes any right or claim in any
+ trade secret which is part of the Rights, and makes the trade
+ secrets available without restriction to the Internet community.
+ The Rights Holder hereby acknowledges that ISOC assumes no
+ obligation to maintain any confidentiality with respect to any
+ aspect of the Standards, and warrants that the Standards do not
+ violate the rights of others.
+
+ The Rights Holder assures ISOC that the Rights Holder shall
+ grant to any member of the Internet community, as a beneficiary of
+ this agreement, a non-exclusive, perpetual, world-wide license
+ under the Rights, with respect to operating under the Standards
+ for a reasonable royalty and under other terms which are
+ reasonable considering the objective of ISOC to assure that all
+ members of the Internet community will be able to operate under
+ the Standards at a minimal cost. The license discussed in this
+ paragraph shall permit the licensee to make, have made, test,
+ enhance, implement, and use methods, works, computer programs, and
+ hardware as needed or desirable for operating under the Standards.
+ Every license shall include a clause automatically modifying the
+ terms of the license to be as favorable as the terms of any other
+ license under the Rights previously or later granted by the Rights
+ Holder.
+
+ A form of the license shall always be publicly accessible on
+ the Internet, and shall become effective immediately when the
+ member of the Internet community executes it and posts it for
+ delivery to the Rights Holder either by mail or electronically.
+ The initial version of the license shall be in the form attached
+ as Schedule B.
+
+ The Rights Holder represents and warrants that its rights are
+ sufficient to permit it to grant the licenses and give the other
+ assurances recited in this agreement. The Rights Holder further
+ represents and warrants that it does not know of any rights of any
+ other party in any country which would block or impede the ability
+ of ISOC and the Internet community to implement or operate under
+ the Standards, or that would prevent the Rights Holder from
+ granting the licenses and other assurances in this agreement.
+
+
+
+
+IAB - IESG [Page 33]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+ This agreement shall not be construed to obligate the ISOC to
+ propose, adopt, develop, or maintain any of the Standards or any
+ other standard.
+
+6. REFERENCES
+
+ [1] Postel, J., "Internet Official Protocol Standards", STD 1, RFC
+ 1600, USC/Information Sciences Institute, March 1994.
+
+ [2] ANSI, Coded Character Set -- 7-Bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+ 1340, USC/Information Sciences Institute, July 1992.
+
+ [4] Postel, J., "Introduction to the STD Notes", RFC 1311,
+ USC/Information Sciences Institute, March 1992.
+
+ [5] Postel, J., "Instructions to RFC Authors", RFC 1543,
+ USC/Information Sciences Institute, October 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB - IESG [Page 34]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+APPENDIX A: GLOSSARY OF ACRONYMS
+
+ANSI: American National Standards Institute
+ARPA: (U.S.) Advanced Research Projects Agency
+AS: Applicability Statement
+ASCII: American Standard Code for Information Interchange
+ITU-T: Telecommunications Standardization sector of the International
+ Telecommunications Union (ITU), a UN treaty organization;
+ ITU-T was formerly called CCITT.
+IAB: Internet Architecture Board
+IANA: Internet Assigned Numbers Authority
+IEEE: Institute of Electrical and Electronics Engineers
+ICMP: Internet Control Message Protocol
+IESG: Internet Engineering Steering Group
+IETF: Internet Engineering Task Force
+IP: Internet Protocol
+IRTF: Internet Research Task Force
+ISO: International Organization for Standardization
+ISOC: Internet Society
+MIB: Management Information Base
+OSI: Open Systems Interconnection
+RFC: Request for Comments
+TCP: Transmission Control Protocol
+TS: Technical Specification
+
+
+APPENDIX B: CONTACT POINTS
+
+To contact the RFC Editor, send an email message to: "rfc-
+editor@isi.edu".
+
+To contact the IANA for information or to request a number, keyword or
+parameter assignment send an email message to: "iana@isi.edu".
+
+To contact the IESG, send an email message to: "iesg@cnri.reston.va.us".
+
+To contact the IAB, send an email message to: "iab-contact@isi.edu".
+
+To contact the Executive Director of the ISOC, send an email message to
+"amr@isoc.org".
+
+
+
+
+
+
+
+
+
+IAB - IESG [Page 35]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+APPENDIX C: FUTURE ISSUES
+
+It has been suggested that additional procedures in the following areas
+should be considered.
+
+o Policy Recommendations and Operational Guidelines
+
+ Internet standards have generally been concerned with the technical
+ specifications for hardware and software required for computer
+ communication across interconnected networks. The Internet itself
+ is composed of networks operated by a great variety of
+ organizations, with diverse goals and rules. However, good user
+ service requires that the operators and administrators of the
+ Internet follow some common guidelines for policies and operations.
+ While these guidelines are generally different in scope and style
+ from protocol standards, their establishment needs a similar
+ process for consensus building. Specific rules for establishing
+ policy recommendations and operational guidelines for the Internet
+ in an open and fair fashion should be developed, published, and
+ adopted by the Internet community.
+
+o Industry Consortia
+
+ The rules presented in Section 4 for external standards should be
+ expanded to handle industry consortia.
+
+o Tracking Procedure
+
+ It has been suggested that there should 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. At the present
+ time, there are not sufficient resources to administer such a
+ procedure.
+
+ A simpler proposal is to keep a change log for documents.
+
+
+
+
+
+
+
+
+
+
+
+
+IAB - IESG [Page 36]
+
+RFC 1602 Internet Standards Process March 1994
+
+
+o Time Limit
+
+ An explicit time limit (e.g., 3 months) has been suggested for IESG
+ resolution concerning a standards action under the rules of Section
+ 3.1.2. If it were necessary to extend the time for some reason,
+ the IETF would have to be explicitly notified.
+
+o Bug Reporting
+
+ There is no documented mechanism for an individual community member
+ to use to report a problem or bug with a standards-track
+ specification. One suggestion was that every standards RFC should
+ include an email list for the responsible Working Group.
+
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Authors' Addresses
+
+ Christian Huitema, IAB Chairman
+ INRIA, Sophia-Antipolis
+ 2004 Route des Lucioles
+ BP 109
+ F-06561 Valbonne Cedex
+ France
+
+ Phone: +33 93 65 77 15
+
+ EMail: Christian.Huitema@MIRSA.INRIA.FR
+
+
+ Phill Gross, IESG Chairman
+ Director of Broadband Engineering
+ MCI Data Services Division
+ 2100 Reston Parkway, Room 6001
+ Reston, VA 22091
+
+ Phone: +1 703 715 7432
+ Fax: +1 703 715 7436
+ EMail: 0006423401@mcimail.com
+
+
+
+
+
+
+
+IAB - IESG [Page 37]
+