From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1310.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc1310.txt (limited to 'doc/rfc/rfc1310.txt') 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 -- cgit v1.2.3