< draft-iab-standards-processv2-00.txt   draft-iab-standards-processv2-01.txt >
Internet Draft Internet Architecture Board Internet Draft Internet Architecture Board and
Lyman Chapin, Chair Expires: December 1993 Internet Engineering Steering Group
November 1992 June 1993
Expires: May 1993
Draft revision to RFC-1310 -- The Internet Standards Process -- Revision 2
The Internet Standards Process **DRAFT**
Status of this Memo Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. Internet Drafts are draft working documents as Internet-Drafts.
documents valid for a maximum of six months. Internet Drafts may be
updated, replaced, or obsoleted by other documents at any time. It Internet-Drafts are draft documents valid for a maximum of six
is not appropriate to use Internet Drafts as reference material or to months. Internet-Drafts may be updated, replaced, or obsoleted by
cite them other than as a ``working draft'' or ``work in progress.'' other documents at any time. It is not appropriate to use Internet-
Please check the 1id-abstracts.txt listing contained in the Drafts as reference material or to cite them other than as a
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, ``working draft'' or ``work in progress.''
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
Abstract Abstract
This memo is a draft of the first update to RFC-1310, which documents This document is a draft of the first revision of RFC-1310, which
the current standards procedures in the Internet community. This defines the official procedures for creating and documenting Internet
memo is being distributed for comment from the Internet community. Standards. This draft revision is being distributed to the Internet
community for comments and suggestions.
Major changes in this update include the following: This revision includes the following major changes:
(a) Add Prototype Status (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) Rewrite the Intellectual Property Rights section, to incorporate (b) Prototype status is added to the non-standards track maturity
legal advice. Section 5 of this document replaces Sections 5 levels (Section 2.4.1).
and 6 of RFC-1310.
(c) Describe new procedures, e.g., the IESG "last call". (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. Note however, that the
new Section 5 is still incomplete and that it is awaiting review
by legal counsel.
(d) Incorporate many suggestions made by IETF members. (d) An appeals procedure is added (Section 3.6).
Significant content changes from RFC-1310 are noted with change bars. Finally, the document was reorganized into a more logical and
In addition, there are many stylistic changes and some coherent structure.
reorganization.
TABLE OF CONTENTS TABLE OF CONTENTS
1. INTRODUCTION ................................................. 2 1. INTRODUCTION ................................................. 2
1.1. Internet Standards ....................................... 2 1.1 Internet Standards. ...................................... 2
1.2. Organization ............................................. 4 1.2 Organizations ............................................ 5
1.3. Standards-Related Publications ........................... 5 1.3 Standards-Related Publications ........................... 6
1.3.1. Requests for Comments (RFCs) ........................ 5 1.4 Internet Assigned Number Authority (IANA) ................ 8
1.3.2. Internet Drafts ..................................... 6 2. NOMENCLATURE ................................................. 9
1.4. Internet Assigned Number Authority (IANA) ................ 6 2.1 The Internet Standards Track ............................. 9
2. NOMENCLATURE ................................................. 7 2.2 Types of Specifications .................................. 9
2.1. The Internet Standards Track ............................. 7 2.3 Standards Track Maturity Levels .......................... 11
2.2. Types of Specifications .................................. 7 2.4 Non-Standards Track Maturity Levels ...................... 12
2.3. Standards Track Maturity Levels .......................... 9 2.5 Requirement Levels ....................................... 14
2.4. Non-Standards Track Maturity Levels ...................... 10 3. THE INTERNET STANDARDS PROCESS ............................... 15
2.5. Requirement Levels ....................................... 12 3.1 Review and Approval ...................................... 15
3. THE INTERNET STANDARDS PROCESS ............................... 13 3.3 Advancing in the Standards Track ......................... 17
3.1. Review and Approval ...................................... 13 3.4 Revising a Standard ...................................... 18
3.2. Entering the Standards Track ............................. 15 3.5 Retiring a Standard ...................................... 19
3.3. Advancing in the Standards Track ......................... 15 3.6 Conflict Resolution and Appeals .......................... 19
3.4. Revising a Standard ...................................... 16 4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 20
3.5. Retiring a Standard ...................................... 16 5. INTELLECTUAL PROPERTY RIGHTS ................................. 22
4. EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 15 5.1 Trade Secret Rights ...................................... 23
5. INTELLECTUAL PROPERTY RIGHTS ................................. 18 5.2 Patent Rights ............................................ 23
5.1. Trade Secret Rights ...................................... 19 5.3 Copyright ................................................ 24
5.2. Patent Rights ............................................ 19 5.4 Notices And Agreements ................................... 25
6. ACKNOWLEDGMENTS AND REFERENCES ............................... 21 6. REFERENCES ................................................... 25
APPENDIX A: GLOSSARY ............................................. 22 APPENDIX A: GLOSSARY OF ACRONYMS ................................. 26
APPENDIX B: CONTACT POINTS ....................................... 22 APPENDIX B: CONTACT POINTS ....................................... 26
APPENDIX C: FUTURE ISSUES ........................................ 27
1. INTRODUCTION 1. INTRODUCTION
1.1 Internet Standards. This memo documents the process currently used by the Internet
community for the standardization of protocols and procedures.
This memo documents the process currently used by the Internet | 1.1 Internet Standards.
Society for the standardization of Internet protocols and |
procedures.
The Internet, a loosely-organized international collaboration of The Internet, a loosely-organized international collaboration of
autonomous, interconnected networks, supports host-to-host autonomous, interconnected networks, supports host-to-host
communication through voluntary adherence to open protocols and communication through voluntary adherence to open protocols and
procedures defined by Internet Standards. There are also many procedures defined by Internet Standards. There are also many
isolated internets, i.e., sets of interconnected networks, that isolated internets, i.e., sets of interconnected networks, which
are not connected to the Internet but use the Internet Standards. 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 Internet Standards were once limited to those protocols composing
conducted over a period of two decades, performed by the network what has been commonly known as the "TCP/IP protocol suite".
R&D community, by service and equipment vendors, and by government However, the Internet has been evolving towards the support of
agencies around the world. 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 In general, an Internet Standard is a specification that is stable
and well-understood, is technically competent, has multiple, and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with substantial independent, and interoperable implementations with substantial
operational experience, enjoys significant public support, and is operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet. recognizably useful in some or all parts of the Internet.
The principal set of Internet Standards is commonly known as the The procedures described in this document are designed to be fair,
"TCP/IP protocol suite". As the Internet evolves, new protocols open and objective; to be retrospective; and to be flexible.
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 intended for use in the Internet, not
just the TCP/IP protocols.
The procedures described in this document are intended to provide o These procedures are intended to provide a fair, open, and
a clear, open, and objective basis for developing, evaluating, and objective basis for developing, evaluating, and adopting
adopting Internet Standards for protocols and services. The Internet Standards. They provide ample opportunity for
procedures provide ample opportunity for participation and comment participation and comment by all interested parties. At each
by all interested parties. Before an Internet Standard is stage of the standardization process, a specification is
adopted, it is repeatedly discussed (and perhaps debated) in open repeatedly discussed and its merits debated in open meetings
meetings and/or public electronic mailing lists, and it is and/or public electronic mailing lists, and it is made
available for review via world-wide on-line directories. available for review via world-wide on-line directories.
These procedures are explicitly aimed at developing and adopting o These procedures are explicitly aimed at recognizing and
generally-accepted practices. Thus, a candidate for Internet adopting generally-accepted practices. Thus, a candidate
standardization is implemented and tested for correct operation specification is implemented and tested for correct operation
and interoperability by multiple, independent parties, and and interoperability by multiple independent parties and
utilized in increasingly demanding environments, before it can be utilized in increasingly demanding environments, before it
adopted as an Internet Standard. can be adopted as an Internet Standard.
The procedures that are described here provide a great deal of o These procedures provide a great deal of flexibility to adapt
flexibility to adapt to the wide variety of circumstances that to the wide variety of circumstances that occur in the
occur in the Internet standardization process. Experience has standardization process. Experience has shown this
shown this flexibility to be vital in achieving the following flexibility to be vital in achieving the goals listed above.
goals for Internet standardization:
* high quality, 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.
* prior implementation and testing, In summary, the goals for the Internet standards process are:
* openness and fairness, and * technical excellence;
* prior implementation and testing;
* clear, short, and easily understandable documentation;
* openness and fairness; and
* timeliness. * timeliness.
In outline, the process of creating an Internet Standard is In outline, the process of creating an Internet Standard is
straightforward: a specification undergoes a period of development straightforward: a specification undergoes a period of development
and several iterations of review by the Internet community and and several iterations of review by the Internet community and
revision based upon experience, is adopted as a Standard by the revision based upon experience, is adopted as a Standard by the
appropriate body (see below), and is published. appropriate body (see below), and is published. In practice, the
process is more complicated, due to (1) the difficulty of creating
In practice, the process is more complicated, due to (1) the specifications of high technical quality; (2) the need to consider
number and type of possible sources for specifications; (2) the | the interests of all of the affected parties; (3) the importance
difficulty of creating specifications of high technical quality; of establishing widespread community consensus; and (4) the
(3) the desire to preserve the interests of all of the affected difficulty of evaluating the utility of a particular specification
parties; (4) the importance of establishing widespread community for the Internet community.
consensus; and (5) the difficulty of evaluating the utility of a
particular specification for the Internet community.
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 From its inception, the Internet has been, and is expected to
remain, an evolving system whose participants regularly factor new remain, an evolving system whose participants regularly factor new
requirements and technology into its design and implementation. requirements and technology into its design and implementation.
Users of the Internet and providers of the equipment, software, Users of the Internet and providers of the equipment, software,
and services that support it should anticipate and embrace this and services that support it should anticipate and embrace this
evolution as a major tenet of Internet philosophy. evolution as a major tenet of Internet philosophy.
The procedures described in this document are the result of three The procedures described in this document are the result of three
years of evolution, driven both by the needs of the growing and years of evolution, driven both by the needs of the growing and
increasingly diverse Internet community, and by experience. increasingly diverse Internet community, and by experience.
Comments and suggestions are invited for improvement in these Comments and suggestions are invited for improving these
procedures. procedures.
The remainder of this section describes the organizations and | The remainder of this section describes the organizations and
publications involved in Internet standardization. Section 2 | publications involved in Internet standardization. Section 2
presents the nomenclature for different kinds and levels of | presents the nomenclature for different kinds and levels of
Internet standard technical specifications and their | Internet standard technical specifications and their
applicability. Section 3 describes the process and rules for | applicability. Section 3 describes the process and rules for
Internet standardization. Section 4 defines how relevant | Internet standardization. Section 4 defines how relevant
externally-sponsored specifications and practices, developed and | externally-sponsored specifications and practices, developed and
controlled by other standards bodies or by vendors, are handled in | controlled by other standards bodies or by vendors, are handled in
the Internet standardization process. Section 5 presents the | the Internet standardization process. Section 5 presents the
rules that are required to protect intellectual property rights. rules that are required to protect intellectual property rights
and to assure unrestricted ability for all interested parties to
practice Internet Standards.
1.2 Organization 1.2 Organizations
The Internet Architecture Board (IAB) is the primary coordinating The following organizations are involved in setting Internet
committee for Internet design, engineering, and management [1]. standards.
The The Internet Engineering Task Force (IETF) has 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, * ISOC
based upon recommendations from the Internet Engineering Steering
Group (IESG), the leadership body of the IETF. IETF Working Internet standardization is an organized activity of the
Groups are organized into areas, and each area is coordinated by Internet Society (ISOC). The ISOC is a professional society
an Area Director. The Area Directors and the IETF Chairman are that is concerned with the growth and evolution of the
included in the IESG. 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.
* IETF
The Internet Engineering Task Force (IETF) is the primary
body developing new Internet Standard specifications. The
IETF is composed of many Working Groups, which are organized
into areas, each of which is coordinated by one or more Area
Directors.
* IESG
The Internet Engineering Steering Group (IESG) is responsible
for technical management of IETF activities and the approval
of Internet standards specifications, using the rules given
in later sections of this document. The IESG is composed of
the IETF Area Directors, some at-large members, and the
chairperson of the IESG/IETF.
* IAB
The Internet Architecture Board (IAB) has been chartered by
the Internet Society Board of Trustees to provide quality
control and process appeals for the standards process, as
well as external technical liaison, organizational oversight,
and long-term architectural planning and research.
Any member of the Internet community with the time and interest is Any member of the Internet community with the time and interest is
urged to attend IETF meetings and to participate actively in one urged to participate actively in one or more IETF Working Groups
or more IETF Working Groups. Participation is by individual and to attend IETF meetings. In many cases, active Working Group
technical contributors rather than formal representatives of participation is possible through email alone; furthermore,
organizations. The process works because the IETF Working Groups Internet video conferencing is being used experimentally to allow
display a spirit of cooperation as well as a high degree of remote participation. Participation is by individual technical
technical maturity; IETF members recognize that the greatest contributors rather than formal representatives of organizations.
benefit for all members of the Internet community results from The process works because the IETF Working Groups display a spirit
cooperative development of technically superior protocols and of cooperation as well as a high degree of technical maturity;
services. IETF participants recognize that the greatest benefit for all
members of the Internet community results from cooperative
development of technically superior protocols and services.
A second body, the Internet Research Task Force (IRTF), Members of the IESG and IAB are nominated for two-year terms by a
investigates topics considered to be too uncertain, too advanced, committee that is drawn from the roll of recent participation in
or insufficiently well-understood to be the subject of Internet the IETF and chartered by the ISOC Board of Trustees. The
standardization. When an IRTF activity generates a specification appointment of IESG and of IAB members are made from these
that is sufficiently stable to be considered for Internet nominations by the IAB and by the ISOC Board of Trustees,
standardization, the specification is processed through the using respectively.
the rules in this document.
1.3. Standards-Related Publications 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.1. Requests for Comments (RFCs) 1.3 Standards-Related Publications
1.3.1 Requests for Comments (RFCs)
Each distinct version of a specification is published as part Each distinct version of a specification is published as part
of the "Request for Comments" (RFC) document series. This of the "Request for Comments" (RFC) document series. This
series is the official publication channel for the IAB and its archival series is the official publication channel for
activities, and the RFC Editor is a member of the IAB. Internet standards documents and other publications of the
IESG, IAB, and Internet community. RFCs are available for
anonymous FTP from a nunber of Internet hosts.
RFCs form a series of publications of networking technical The RFC series of documents on networking began in 1969 as part
documents, begun in 1969 as part of the original DARPA wide- of the original ARPA wide-area networking (ARPANET) project
area networking (ARPANET) project (see Appendix A for glossary (see Appendix A for glossary of acronyms). RFCs cover a wide
of acronyms). RFCs cover a wide range of topics, from early range of topics, from early discussion of new research concepts
discussion of new research concepts to status memos about the to status memos about the Internet. RFC publication is the
Internet. direct responsibility of the RFC Editor, under the general
direction of the IAB.
The rules for formatting and submitting an RFC are defined in | The rules for formatting and submitting an RFC are defined in
reference [10]. Every RFC will be available in ASCII text, but | reference [5]. Every RFC is available in ASCII text, but some
some RFCs will also be available in Postscript. For | RFCs are also available in PostScript*. The PostScript version
standards-track specifications, there is a stricter requirement | _________________________
on the publication format: the ASCII version is the reference | *PostScript is a registered trademark of Adobe Systems,
document, and therefore it must be complete and accurate. A | of an RFC may contain material (such as diagrams and figures)
supplemental Postscript versin with more attractive formatting | that is not present in the ASCII version, and it may be
is optional in this case. formatted differently.
The status of specifications on the Internet standards track is *********************************************************
summarized periodically in an RFC entitled "IAB Official * A stricter requirement applies to standards-track *
Protocol Standards" [2]. This RFC shows the level of maturity * specifications: the ASCII text version is the *
and other helpful information for each Internet protocol or * definitive reference, and therefore it must be a *
service specification. * complete and accurate specification of the standard, *
* including all necessary diagrams and illustrations. *
* *
*********************************************************
******************************************************** The status of Internet protocol and service specifications is
* The "IAB Official Protocol Standards" RFC is the * summarized periodically in an RFC entitled "Official Protocol
* authoritative statement of the current status of * Standards" [1]. This RFC shows the level of maturity and other
* any particular Internet specification. * helpful information for each Internet protocol or service
******************************************************** specification. See Section 3.1.3 below.
The STD documents form a subseries of the RFC series. When a Some RFCs document Internet standards. These RFCs form the
specification has been adopted as an Internet Standard, its RFC 'STD' subseries of the RFC series [4]. When a specification
is labeled with a STDxxx number [9] in addition to its RFC has been adopted as an Internet Standard, it is given the
number. 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 Not all specifications of protocols or services for the
Internet should or will become Internet Standards. Such non- Internet should or will become Internet Standards. Such non-
standards track specifications are not subject to the rules for standards track specifications are not subject to the rules for
Internet standardization; generally, they will be published Internet standardization. Generally, they will be published
directly as RFCs at the discretion of the RFC editor and the | directly as RFCs at the discretion of the RFC editor and the
IESG. These RFCs will be marked as "Prototype", "Experimental" | IESG. These RFCs will be marked "Prototype", "Experimental" or
or "Informational" (see section 2.3). "Informational" as appropriate (see section 2.3).
******************************************************** ********************************************************
* It is important to remember that not all RFCs * * It is important to remember that not all RFCs *
* are standards track documents, and that not all * * are standards track documents, and that not all *
* standards track documents reach the level of * * standards track documents reach the level of *
* Internet Standard. * * Internet Standard. *
******************************************************** ********************************************************
1.3.2. Internet Drafts 1.3.2 Internet Drafts
During the development of a specification, draft versions of During the development of a specification, draft versions of
the document are made available for informal review and comment the document are made available for informal review and comment
by placing them in the IETF's "Internet Drafts" directory, by placing them in the IETF's "Internet Drafts" directory,
_________________________
Inc.
which is replicated on a number of Internet hosts. This makes which is replicated on a number of Internet hosts. This makes
an evolving working document readily available to a wide an evolving working document readily available to a wide
audience, facilitating the process of review and revision. audience, facilitating the process of review and revision.
An Internet Draft that is published as an RFC, or that has An Internet Draft that is published as an RFC, or that has
remained unchanged in the Internet Drafts directory for more remained unchanged in the Internet Drafts directory for more
than six months without being recommended by the IESG for than six months without being recommended by the IESG for
publication as an RFC, is simply removed from the Internet publication as an RFC, is simply removed from the Internet
Draft directory. At any time, an Internet Draft may be Draft directory. At any time, an Internet Draft may be
replaced by a more recent version of the same specification, replaced by a more recent version of the same specification,
restarting the six-month timeout period. restarting the six-month timeout period.
An Internet Draft is NOT a means of "publishing" a An Internet Draft is NOT a means of "publishing" a
specification; specifications are published through the RFC specification; specifications are published through the RFC
mechanism described in the next section. Internet Drafts have mechanism described in the previous section. Internet Drafts
no formal status, and are not part of the permanent archival have no formal status, are not part of the permanent archival
record of Internet activity, and they are subject to change or record of Internet activity, and are subject to change or
removal at any time. Under no circumstances should an Internet removal at any time.
Draft be referenced by any paper, report, or Request for
Proposal, nor should a vendor claim compliance with an |
Internet-Draft.
1.4. Internet Assigned Number Authority (IANA) ********************************************************
* 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 be reasonably be expected to be
published as an RFC using the phrase "RFC in preparation",
without referencing an Internet Draft.
1.4 Internet Assigned Number Authority (IANA)
Many protocol specifications include numbers, keywords, and other Many protocol specifications include numbers, keywords, and other
parameters that must be uniquely assigned. Examples include parameters that must be uniquely assigned. Examples include
version numbers, protocol numbers, port numbers, and MIB numbers. version numbers, protocol numbers, port numbers, and MIB numbers.
The IAB has delegated to the Internet Assigned Numbers Authority The IAB has delegated to the Internet Assigned Numbers Authority
(IANA) the task of assigning such protocol parameters for the (IANA) the task of assigning such protocol parameters for the
Internet. The IANA publishes tables of all currently assigned Internet. The IANA publishes tables of all currently assigned
numbers and parameters in RFCs titled "Assigned Numbers" [8]. numbers and parameters in RFCs titled "Assigned Numbers" [3].
Each category of assigned numbers typically arises from some Each category of assigned numbers typically arises from some
protocol that is on the standards track or is an Internet protocol that is on the standards track or is an Internet
Standard. For example, TCP port numbers are assigned because TCP Standard. For example, TCP port numbers are assigned because TCP
is a Standard. A particular value within a category may be is a Standard. A particular value within a category may be
assigned in a variety of circumstances; the specification assigned in a variety of circumstances; the specification
requiring the parameter may be in the standards track, it may be requiring the parameter may be in the standards track, it may be
Experimental, or it may be private. 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, Chaos could result from accidental conflicts of parameter values,
so we urge that every protocol parameter, for either public or so we urge that every protocol parameter, for either public or
private usage, be explicitly assigned by the IANA. Private private usage, be explicitly assigned by the IANA. Private
protocols often become public. Programmers are often tempted to protocols often become public. Programmers are often tempted to
choose a "random" value or to guess the next unassigned value of a choose a "random" value or to guess the next unassigned value of a
parameter; both are hazardous. parameter; both are hazardous.
The IANA is tasked to avoid frivolous assignments and to The IANA is expected to avoid frivolous assignments and to
distinguish different assignments uniquely. The IANA accomplishes distinguish different assignments uniquely. The IANA accomplishes
both goals by requiring a technical description of each protocol both goals by requiring a technical description of each protocol
or service to which a value is to be assigned. Judgment on the 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 adequacy of the description resides with the IANA. In the case of
a standards track or Experimental protocol, the corresponding a standards track or Experimental protocol, the corresponding
technical specifications provide the required documentation for technical specifications provide the required documentation for
IANA. For a proprietary protocol, the IANA will keep confidential IANA. For a proprietary protocol, the IANA will keep confidential
any writeup that is supplied, but at least a short (2 page) any writeup that is supplied, but at least a short (2 page)
writeup is still required for an assignment. writeup is still required for an assignment.
2. NOMENCLATURE 2. NOMENCLATURE
2.1. The Internet Standards Track 2.1 The Internet Standards Track
Specifications that are destined to become Internet Standards Specifications that are destined to become Internet Standards
evolve through a set of maturity levels known as the "standards evolve through a set of maturity levels known as the "standards
track". These maturity levels -- "Proposed Standard", "Draft track". These maturity levels -- "Proposed Standard", "Draft
Standard", and "Standard" -- are defined and discussed below in Standard", and "Standard" -- are defined and discussed below in
Section 3.2. Section 3.2.
Even after a specification has been adopted as an Internet Even after a specification has been adopted as an Internet
Standard, further evolution often occurs based on experience and Standard, further evolution often occurs based on experience and
the recognition of new requirements. The nomenclature and the recognition of new requirements. The nomenclature and
procedures of Internet standardization provide for the replacement procedures of Internet standardization provide for the replacement
of old Internet Standards with new ones, and the assignment of of old Internet Standards with new ones, and the assignment of
descriptive labels to indicate the status of "retired" Internet descriptive labels to indicate the status of "retired" Internet
Standards. A set of maturity levels is defined in Section 3.3 to Standards. A set of maturity levels is defined in Section 3.3 to
cover these and other "off-track" specifications. cover these and other "off-track" specifications.
2.2. Types of Specifications 2.2 Types of Specifications
Specifications subject to the Internet standardization process Specifications subject to the Internet standardization process
fall into two categories: Technical Specifications (TS) and fall into two categories: Technical Specifications (TS) and
Applicability Statements (AS). Applicability Statements (AS).
2.2.1. Technical Specification (TS) 2.2.1 Technical Specification (TS)
A Technical Specification is any description of a protocol, A Technical Specification is any description of a protocol,
service, procedure, convention, or format. It may completely service, procedure, convention, or format. It may completely
describe all of the relevant aspects of its subject, or it may describe all of the relevant aspects of its subject, or it may
leave one or more parameters or options unspecified. A TS may leave one or more parameters or options unspecified. A TS may
be completely self-contained, or it may incorporate material be completely self-contained, or it may incorporate material
from other specifications by reference to other documents from other specifications by reference to other documents
(which may or may not be Internet Standards). (which may or may not be Internet Standards).
A TS shall include a statement of its scope and the general A TS shall include a statement of its scope and the general
intent for its use (domain of applicability). Thus, a TS that intent for its use (domain of applicability). Thus, a TS that
is inherently specific to a particular context shall contain a is inherently specific to a particular context shall contain a
statement to that effect. However, a TS does not specify statement to that effect. However, a TS does not specify
requirements for its use within the Internet; these requirements for its use within the Internet; these
requirements, which depend on the particular context in which requirements, which depend on the particular context in which
the TS is incorporated by different system configurations, is the TS is incorporated by different system configurations, is
defined by an Applicability Statement. defined by an Applicability Statement.
2.2.2. Applicability Statement (AS) 2.2.2 Applicability Statement (AS)
An Applicability Statement specifies how, and under what An Applicability Statement specifies how, and under what
circumstances, one or more TSs are to be applied to support a circumstances, one or more TSs are to be applied to support a
particular Internet capability. An AS may specify uses for TSs particular Internet capability. An AS may specify uses for TSs
that are not Internet Standards, as discussed in Section 4. that are not Internet Standards, as discussed in Section 4.
An AS identifies the relevant TSs and the specific way in which An AS identifies the relevant TSs and the specific way in which
they are to be combined, and may also specify particular values they are to be combined, and may also specify particular values
or ranges of TS parameters or subfunctions of a TS protocol or ranges of TS parameters or subfunctions of a TS protocol
that must be implemented. An AS also specifies the that must be implemented. An AS also specifies the
circumstances in which the use of a particular TS is required, circumstances in which the use of a particular TS is required,
recommended, or elective. recommended, or elective.
An AS may describe particular methods of using a TS in a An AS may describe particular methods of using a TS in a
restricted "domain of applicability", such as Internet routers, restricted "domain of applicability", such as Internet routers,
terminal servers, Internet systems that interface to Ethernets, terminal servers, Internet systems that interface to Ethernets,
or datagram-based database servers. or datagram-based database servers.
The broadest type of AS is a comprehensive conformance The broadest type of AS is a comprehensive conformance
specification, commonly called a "requirements document", for a specification, commonly called a "requirements document", for a
particular class of Internet systems [3,4,5], such as Internet particular class of Internet systems, such as Internet routers
routers or Internet hosts. or Internet hosts.
An AS may not have a higher maturity level in the standards 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 track than any standards-track TS to which the AS applies. For
at Draft Standard level may be referenced by an AS at the example, a TS at Draft Standard level may be referenced by an
Proposed Standard or Draft Standard level, but not an AS at the AS at the Proposed Standard or Draft Standard level, but not by
Standard level. Like a TS, an AS does not come into effect an AS at the Standard level. Like a TS, an AS does not come
until it reaches Standard level. into effect until it reaches Standard level.
Although TSs and ASs are conceptually separate, in practice an Although TSs and ASs are conceptually separate, in practice a
Internet Standard RFC may include elements of both an AS and one standards- track document may combine an AS and one or more
or more TSs in a single document. For example, Technical related TSs. For example, Technical Specifications that are
Specifications that are developed specifically and exclusively for developed specifically and exclusively for some particular domain
some particular domain of applicability, e.g., for mail server of applicability, e.g., for mail server hosts, often contain
hosts, often contain within a single specification all of the within a single specification all of the relevant AS and TS
relevant AS and TS information. In such cases, no useful purpose information. In such cases, no useful purpose would be served by
would be served by deliberately distributing the information among deliberately distributing the information among several documents
several documents just to preserve the formal AS/TS distinction. just to preserve the formal AS/TS distinction. However, a TS that
However, a TS that is likely to apply to more than one domain of is likely to apply to more than one domain of applicability should
applicability should be developed in a modular fashion, to be developed in a modular fashion, to facilitate its incorporation
facilitate its incorporation by multiple ASs. by multiple ASs.
2.3. Standards Track Maturity Levels 2.3 Standards Track Maturity Levels
ASs and TSs go through stages of development, testing, and ASs and TSs go through stages of development, testing, and
acceptance. Within the Internet standards process, these stages acceptance. Within the Internet standards process, these stages
are formally labeled "maturity levels". are formally labeled "maturity levels".
This section describes the maturity levels and the expected This section describes the maturity levels and the expected
characteristics of specifications at each level. The general characteristics of specifications at each level. The general
procedures for developing a specification and processing it procedures for developing a specification and processing it
through the maturity levels along the standards track were through the maturity levels along the standards track were
discussed in Section 2 above. discussed in Section 2 above.
2.3.1. Proposed Standard 2.3.1 Proposed Standard
The entry-level maturity for the standards track is "Proposed The entry-level maturity for the standards track is "Proposed
Standard". A Proposed Standard specification is generally Standard". A Proposed Standard specification is generally
stable, has resolved known design choices, is believed to be stable, has resolved known design choices, is believed to be
well-understood, has received significant community review, and well-understood, has received significant community review, and
appears to enjoy enough community interest to be considered appears to enjoy enough community interest to be considered
valuable. However, further experience might result in a change valuable. However, further experience might result in a change
or even retraction of the specification before it advances to a or even retraction of the specification before it advances.
Standard.
Usually, neither implementation nor operational experience is Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and Standard. However, such experience is highly desirable, and
will usually represent a strong argument in favor of a Proposed will usually represent a strong argument in favor of a Proposed
Standard designation. Furthermore, the IAB may require Standard designation.
implementation and/or operational experience prior to granting
Proposed Standard status to a specification that materially The IESG may require implementation and/or operational
affects the core Internet protocols or that specifies behavior experience prior to granting Proposed Standard status to a
that may have significant operational impact on the Internet. specification that materially affects the core Internet
Typically, such a specification will be published initially protocols or that specifies behavior that may have significant
with Experimental or Prototype status (see below), and moved to operational impact on the Internet. Typically, such a
the standards track only after sufficient implementation or specification will be published initially with Experimental or
operational experience has been obtained. 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 A Proposed Standard should have no known technical omissions
with respect to the requirements placed upon it. In some with respect to the requirements placed upon it. However, the
cases, the IESG may recommend that the requirements be IESG may recommend that this requirement be explicitly reduced
explicitly reduced in order to allow a protocol to advance into in order to allow a protocol to advance into the Proposed
the Proposed Standard state. This can happen if the Standard state, when a specification is considered to be useful
specification is considered to be useful and necessary (and and necessary (and timely), even absent the missing features.
timely), even absent the missing features. For example, some For example, some protocols have been advanced by explicitly
protocols have been advanced by explicitly deciding to omit deciding to omit security features, since an overall security
security features at the Proposed Standard level, since an architecture was still under development.
overall security architecture was still under development.
2.3.2. Draft Standard 2.3.2 Draft Standard
A specification from which at least two independent and A specification from which at least two independent and
interoperable implementations have been developed, and for interoperable implementations have been developed, and for
which sufficient successful operational experience has been which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level. This obtained, may be elevated to the "Draft Standard" level. This
is a major advance in status, indicating a strong belief that is a major advance in status, indicating a strong belief that
the specification is mature and will be useful. the specification is mature and will be useful.
A Draft Standard must be well-understood and known to be quite A Draft Standard must be well-understood and known to be quite
stable, both in its semantics and as a basis for developing an stable, both in its semantics and as a basis for developing an
implementation. A Draft Standard may still require additional implementation. A Draft Standard may still require additional
or more widespread field experience, since it is possible for or more widespread field experience, since it is possible for
implementations based on Draft Standard specifications to implementations based on Draft Standard specifications to
demonstrate unforeseen behavior when subjected to large-scale demonstrate unforeseen behavior when subjected to large-scale
use in production environments. use in production environments.
2.3.3. Internet Standard 2.3.3 Internet Standard
A specification for which significant implementation and A specification for which significant implementation and
successful operational experience has been obtained may be successful operational experience has been obtained may be
elevated to the Internet Standard level. An Internet Standard elevated to the Internet Standard level. An Internet Standard
(which may simply be referred to as a Standard) is (which may simply be referred to as a Standard) is
characterized by a high degree of technical maturity and by a characterized by a high degree of technical maturity and by a
generally held belief that the specified protocol or service generally held belief that the specified protocol or service
provides significant benefit to the Internet community. provides significant benefit to the Internet community.
2.4. Non-Standards Track Maturity Levels 2.4 Non-Standards Track Maturity Levels
Not every TS or AS is on the standards track. A TS may not be 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 intended to be an Internet Standard, or it may be intended for
eventual standardization but not yet ready to enter the standards eventual standardization but not yet ready to enter the standards
track. A TS or AS may have been superseded by more recent track. A TS or AS may have been superseded by more recent
Internet Standards, or have otherwise fallen into disuse or Internet Standards, or have otherwise fallen into disuse or
disfavor. disfavor.
Specifications not on the standards track are labeled with one of Specifications not on the standards track are labeled with one of
four off-track maturity levels: "Prototype, "Experimental", | four off-track maturity levels: "Prototype, "Experimental",
"Informational", and "Historic". There are no time limits | "Informational", and "Historic". There are no time limits
associated with these non-standard track labels, and the documents | associated with these non-standard track labels, and the documents
bearing these labels are not standards in any sense. bearing these labels are not Internet standards in any sense.
2.4.1. Prototype | 2.4.1 Prototype
The "Prototype" designation on a TS indicates a specification | The "Prototype" designation on a TS indicates a specification
produced by a protocol engineering effort that is not | for which the eventual destination may be the standards track,
sufficiently mature to enter the standards track. For example, | but which is not at present sufficiently mature to enter the
a Prototype TS may specify behavior that is not completely | standards track. For example, a Prototype TS may result in
understood, or it may have known technical omissions or | behavior that is not completely understood, or it may have
architectural defects. It may undergo significant changes | known technical omissions or architectural defects. It may
before entering the standards track, and it may be discarded in | undergo significant changes before entering the standards
favor of another proposal. One use of the Prototype | track, or it may be discarded in favor of another proposal.
designation is the dissemination of a specification as it | One use of the Prototype designation is the dissemination of a
undergoes development and testing. | specification as it undergoes development and testing.
A Prototype specification will generally be the output of an | A Prototype specification will generally be the output of an
organized Internet engineering effort, for example a Working | organized Internet engineering effort, for example a Working
Group of the IETF. An IETF Working Group should submit a | Group of the IETF. An IETF Working Group should submit a
document that is intended for Prototype status to the IESG. | document that is intended for Prototype status to the IESG.
The IESG will forward it to the RFC Editor for publication, | The IESG will forward it to the RFC Editor for publication,
after verifying that there has been adequate coordination with | after verifying that there has been adequate coordination with
the standards process. | the standards process.
2.4.2. Experimental | 2.4.2 Experimental
The "Experimental" designation on a TS indicates a | The "Experimental" designation on a TS typically indicates a
specification that is part of a research effort. Such a | specification that is part of some research or development
specification is published for general information of the | effort. Such a specification is published for the general
Internet technical community and as an archival record of the | information of the Internet technical community and as an
work. An Experimental specification may be the output of an | archival record of the work. An Experimental specification may
organized Internet research effort or it may be an individual | be the output of an organized Internet research effort (e.g., a
contribution. | Research Group of the IRTF), or it may be an individual
contribution.
Documents intended for Experimental status should be submitted | Documents intended for Experimental status should be submitted
directly to the RFC Editor for publication. The rules are | directly to the RFC Editor for publication. The procedure is
intended to expedite the publication of any responsible | intended to expedite the publication of any responsible
Experimental specification, subject only to editorial | Experimental specification, subject only to editorial
considerations, and to a check that there has been adequate | considerations, and to verification that there has been
coordination with the standards process. adequate coordination with the standards process.
2.4.3. Informational 2.4.3 Informational
An "Informational" specification is published for the general An "Informational" specification is published for the general
information of the Internet community, and does not represent information of the Internet community, and does not represent
an Internet community consensus or recommendation. an Internet community consensus or recommendation. The
procedure is intended to expedite the publication of any
responsible informational document, 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 Specifications that have been prepared outside of the Internet
community and are not incorporated into the Internet standards community and are not incorporated into the Internet standards
process by any of the provisions of Section 4 may be published process by any of the provisions of Section 4 may be published
as Informational RFCs, with the permission of the owner. as Informational RFCs, with the permission of the owner.
2.4.4. Historic 2.4.4 Historic
A TS or AS that has been superseded by a more recent A TS or AS that has been superseded by a more recent
specification or is for any other reason considered to be specification or is for any other reason considered to be
obsolete is assigned to the "Historic" level. (Purists have obsolete is assigned to the "Historic" level. (Purists have
suggested that the word should be "Historical"; however, at suggested that the word should be "Historical"; however, at
this point the use of "Historic" is historical.) this point the use of "Historic" is historical.)
2.5. Requirement Levels 2.5 Requirement Levels
An AS may apply one of the following "requirement levels" to each An AS may apply one of the following "requirement levels" to each
of the TSs to which it refers: of the TSs to which it refers:
(a) Required: Implementation of the referenced TS, as specified (a) Required: Implementation of the referenced TS, as specified
by the AS, is required to achieve minimal conformance. For by the AS, is required to achieve minimal conformance. For
example, IP and ICMP must be implemented by all Internet example, IP and ICMP must be implemented by all Internet
systems using the TCP/IP Protocol Suite. systems using the TCP/IP Protocol Suite.
(b) Recommended: Implementation of the referenced TS is not (b) Recommended: Implementation of the referenced TS is not
skipping to change at page 14, line 23 skipping to change at page 15, line 22
in limited or unique circumstances. For example, the usage in limited or unique circumstances. For example, the usage
of a protocol with the "Experimental" designation should of a protocol with the "Experimental" designation should
generally be limited to those actively involved with the generally be limited to those actively involved with the
experiment. experiment.
(e) Not Recommended: A TS that is considered to be inappropriate (e) Not Recommended: A TS that is considered to be inappropriate
for general use is labeled "Not Recommended". This may be for general use is labeled "Not Recommended". This may be
because of its limited functionality, specialized nature, or because of its limited functionality, specialized nature, or
historic status. historic status.
The "IAB Official Protocol Standards" RFC lists a general The "Official Protocol Standards" RFC lists a general requirement
requirement level for each TS, using the nomenclature defined in level for each TS, using the nomenclature defined in this section.
this section. In many cases, more detailed descriptions of the In many cases, more detailed descriptions of the requirement
requirement levels of particular protocols and of individual levels of particular protocols and of individual features of the
features of the protocols will be found in appropriate ASs. protocols will be found in appropriate ASs.
3. THE INTERNET STANDARDS PROCESS 3. THE INTERNET STANDARDS PROCESS
3.1. Review and Approval 3.1 Review and Approval
A "standards action" -- entering a particular specification into, A "standards action" -- entering a particular specification into,
or advancing it within, or removing it from, the standards track advancing it within, or removing it from, the standards track --
-- must be approved by the IAB following recommendation by the must be approved by the IESG.
IESG.
3.1.1. Initiation of Action 3.1.1 Initiation of Action
Typically, a standards action is initiated by a recommendation Typically, a standards action is initiated by a recommendation
to the appropriate IETF Area Director by the individual or to the appropriate IETF Area Director by the individual or
group that is responsible for the specification, usually an group that is responsible for the specification, usually an
IETF Working Group. IETF Working Group.
After completion to the satisfaction of its author and the After completion to the satisfaction of its author and the
cognizant Working Group, a document that is expected to enter cognizant Working Group, a document that is expected to enter
or advance in the Internet standardization process shall be or advance in the Internet standardization process shall be
made available as an Internet Draft. It shall remain as an made available as an Internet Draft. It shall remain as an
Internet Draft for a period of time that permits useful Internet Draft for a period of time that permits useful
community review, at least two weeks, before submission to the community review, at least two weeks, before submission to the
IESG with a recommendation for action. IESG with a recommendation for action.
3.1.2. IESG Review 3.1.2 IESG Review and Approval
The IESG shall determine if an independent technical review of
the specification is required, and shall commission one if
necessary. This may require creating a new Working Group, or
there may be an agreement by an existing group 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.
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 The IESG shall determine whether a specification satisfies the
applicable criteria for the recommended action (see Sections applicable criteria for the recommended action (see Sections
3.2 and 3.3 of this document) and shall communicate its 3.2 and 3.3 of this document).
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 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 less than two weeks after issuance |
of the last-call notification to the IETF mailing list, the |
IESG shall communicate to the IAB its final recommendation via |
email, with a copy to the IETF mailing list. This notification |
shall include a citation to the most current version of the |
document, and a clear statement of any relationship or |
anticipated impact of this action on other Internet standards- |
track specifications or non-Internet standards.
3.1.3. IAB Review 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 IAB shall review the IESG recommendation in a timely The IESG shall communicate its findings to the IETF to permit a
manner. If the IAB finds a significant problem or needs final review by the general Internet community. This "last-
clarification on a particular point, it shall resolve the call" notification shall be via electronic mail to the IETF
matter with the Working Group and its chairperson and/or the mailing list. In addition, for important specifications there
document author, with the assistance and concurrence of the shall be a presentation or statement by the appropriate Working
IESG and the relevant IETF Area Director. 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 IAB shall notify the IETF mailing list of IAB approval or | In a timely fashion, but no sooner than two weeks after issuing
other action that results. 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.4. Publication 3.1.3 Publication
Following IAB approval and any necessary editorial work, the Following IESG approval and any necessary editorial work, the
RFC Editor shall publish the specification as an RFC. The RFC Editor shall publish the specification as an RFC. The
specification shall then be removed from the Internet Drafts specification shall then be removed from the Internet Drafts
directory. directory.
An official summary of standards actions completed and pending | An official summary of standards actions completed and pending
shall appear in each issue of the Internet Society Newsletter. | shall appear in each issue of the Internet Society Newsletter.
This shall constitute the Journal of Record of Internet | This shall constitute the Journal of Record for Internet
standards actions. In addition, the IAB shall publish a | standards actions. In addition, the IESG shall publish a
monthly summary of standards actions completed and pending in | monthly summary of standards actions completed and pending in
the Internet Monthly Report, distributed to all members of the | the Internet Monthly Report, which is distributed to all
IETF mailing list. members of the IETF mailing list.
3.2. Entering the Standards Track Finally, the IAB shall publish quarterly an "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 A specification that is potentially an Internet Standard may
originate from: originate from:
(a) an IAB-sponsored effort (typically an IETF Working Group), (a) an ISOC-sponsored effort (typically an IETF Working Group),
(b) independent activity by individuals, or (b) independent activity by individuals, or
(c) an external organization. (c) an external organization.
Here (a) represents the great majority of cases. In cases (b) and Here (a) represents the great majority of cases. In cases (b) and
(c), the work might be tightly integrated with the work of an (c), the work might be tightly integrated with the work of an
existing IETF Working Group, or it might be offered for existing IETF Working Group, or it might be offered for
standardization without prior IETF involvement. In most cases, a standardization without prior IETF involvement. In most cases, a
specification resulting from an effort that took place outside of specification resulting from an effort that took place outside of
an IETF Working Group context will be submitted to an appropriate an IETF Working Group will be submitted to an appropriate Working
Working Group for evaluation and refinement. If necessary, an Group for evaluation and refinement. If necessary, an appropriate
appropriate Working Group will be created. Working Group will be created.
For externally-developed specifications that are well-integrated For externally-developed specifications that are well-integrated
with existing Working Group efforts, a Working Group is assumed to with existing Working Group efforts, a Working Group is assumed to
afford adequate community review of the accuracy and applicability afford adequate community review of the accuracy and applicability
of the specification. If a Working Group is unable to resolve all of the specification. If a Working Group is unable to resolve all
technical and usage questions, additional independent review may technical and usage questions, additional independent review may
be necessary. Such reviews may be done within a Working Group be necessary. Such reviews may be done within a Working Group
context, or by an ad hoc review committee established specifically context, or by an ad hoc review committee established specifically
for that purpose. It is the responsibility of the appropriate for that purpose. It is the responsibility of the appropriate
IETF Area Director to determine what, if any, review of an IETF Area Director to determine what, if any, review of an
external specification is needed and how it shall be conducted. external specification is needed and how it shall be conducted.
3.3. Advancing in the Standards Track 3.3 Advancing in the Standards Track
A specification shall remain at the Proposed Standard level for at A specification shall remain at the Proposed Standard level for at
least six (6) months and at the Draft Standard level for at least least six (6) months.
four (4) months, to ensure adequate time for community review. |
These intervals shall be measured from the date of publication of |
the resulting RFC(s), or, if the action does not result in RFC |
publication, the date of IAB approval of the action. |
A review of the viability of a standardization effort will be | A specification shall remain at the Draft Standard level for at
conducted by the IESG and IAB when a standards-track specification | least four (4) months, or until at least one IETF meeting has
has remained at the same status level for twenty-four (24) months, | occurred, whichever comes later.
and every twelve (12) months thereafter until the status is |
changed. The IESG shall recommend, and the IAB approve, | These minimum periods are intended to ensure adequate opportunity
termination or continuation of the development, with the | for community review without severely impacting timeliness. These
appropriate change of status. Such a recommendation shall be | intervals shall be measured from the date of publication of the
communicated to the IETF via electronic mail to the IETF mailing | corresponding RFC(s), or, if the action does not result in RFC
list, to allow the Internet community an opportunity to comment. | publication, the date of IESG approval of the action.
This provision is not intended to threaten a legitimate and active |
Working Group effort, but rather to provide an administrative | 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. mechanism for terminating a moribund effort.
A specification may be (indeed, is likely to be) revised as it A specification may be (indeed, is likely to be) revised as it
advances through the standards track. At each stage, the IESG advances through the standards track. At each stage, the IESG
shall determine the scope and significance of the revision to the shall determine the scope and significance of the revision to the
specification, and, if necessary and appropriate, modify the specification, and, if necessary and appropriate, modify the
recommended action. Minor revisions are expected, but a recommended action. Minor revisions are expected, but a
significant revision may require that the specification accumulate significant revision may require that the specification accumulate
more experience at its current maturity level before progressing. more experience at its current maturity level before progressing.
Finally, if the specification has been changed very significantly, Finally, if the specification has been changed very significantly,
the IESG may recommend that the revision be treated as a new the IESG may recommend that the revision be treated as a new
document, re-entering the standards track at the beginning. document, re-entering the standards track at the beginning.
Change of status shall result in republication of the | Change of status shall result in republication of the
specification as an RFC, except in the rare case that there have | specification as an RFC, except in the rare case that there have
been no changes at all in the specification since the last | been no changes at all in the specification since the last
publication. Generally, desired changes will be "batched" for | publication. Generally, desired changes will be "batched" for
incorporation at the next level in the standards track. However, | incorporation at the next level in the standards track. However,
deferral of changes to the next standards action on the | deferral of changes to the next standards action on the
specification will not always be possible or desirable; for | specification will not always be possible or desirable; for
example, an important typographic error, or a technical error that | example, an important typographical error, or a technical error
does not represent a change in overall function of the | that does not represent a change in overall function of the
specification, may need to be corrected immediately. In such | specification, may need to be corrected immediately. In such
cases, the IESG or RFC Editor may be asked to republish the RFC | cases, the IESG or RFC Editor may be asked to republish the RFC
with corrections, and this will not reset the minimum time-at- | with corrections, and this will not reset the minimum time-at-
level clock. level clock.
3.4. Revising a Standard 3.4 Revising a Standard
A new version of an established Internet Standard must progress | A new version of an established Internet Standard must progress
through the full Internet standardization process as if it were a | through the full Internet standardization process as if it were a
completely new specification. Once the new version has reached | completely new specification. Once the new version has reached
the Standard level, it will usually replace the previous version, | the Standard level, it will usually replace the previous version,
which will move to the Historic status. However, in some cases which will move to Historic status. However, in some cases both
both versions may remain as Internet Standards, to honor the versions may remain as Internet Standards, to honor the
requirements of an installed base. In this sitution, the requirements of an installed base. In this situation, the
relationship between the previous and the new versions must be relationship between the previous and the new versions must be
explicitly stated in the text of the new version or in another explicitly stated in the text of the new version or in another
appropriate document (e.g., an Applicability Statement; see appropriate document (e.g., an Applicability Statement; see
Section 2.2.2). Section 2.2.2).
3.5. Retiring a Standard | 3.5 Retiring a Standard
As the technology changes and matures, it is possible for a new | As the technology changes and matures, it is possible for a new
Standard specification to be so clearly superior technically that | Standard specification to be so clearly superior technically that
one or more existing Internet Standards for the same function | one or more existing Internet Standards for the same function
should be retired. In this case, the IESG shall recommend and the | should be retired. In this case, the IESG shall approve a change
IAB approve a change of status of the superseded specification(s) | of status of the superseded specification(s) from Standard to
from Standard to Historic. This recommendation shall be issued | Historic. This recommendation shall be issued with the same
with the same Last-Call and notification procedures used for any | Last-Call and notification procedures used for any other standards
other standards action. 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.
* 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 4. EXTERNAL STANDARDS AND SPECIFICATIONS
Many de facto and de jure standards groups other than the IAB/IETF Many standards groups other than the IETF create and publish
create and publish standards documents for network protocols and standards documents for network protocols and services. When these
services. When these external specifications play an important role external specifications play an important role in the Internet, it is
in the Internet, it is desirable to reach common agreements on their desirable to reach common agreements on their usage -- i.e., to
usage -- i.e., to establish Internet Standards relating to these establish Internet Standards relating to these external
external specifications. specifications.
There are two categories of external specifications: There are two categories of external specifications:
(1) Open Standards (1) Open Standards
Accredited national and international standards bodies, such as Accredited national and international standards bodies, such as
ANSI, ISO, IEEE, and CCITT, develop a variety of protocol and ANSI, ISO, IEEE, and ITU-TS, develop a variety of protocol and
service specifications that are similar to Technical service specifications that are similar to Technical
Specifications (see glossary in Appendix A). These Specifications defind here. National and international groups
specifications are generally de jure standards. Similarly, also publish "implementors' agreements" that are analogous to
national and international groups publish "implementors' Applicability Statements, capturing a body of implementation-
agreements" that are analogous to Applicability Statements, specific detail concerned with the practical application of
capturing a body of implementation-specific detail concerned their standards.
with the practical application of their standards.
(2) Vendor Specifications (2) Vendor Specifications
A vendor-proprietary specification that has come to be widely A vendor-proprietary specification that has come to be widely
used in the Internet may be treated by the Internet community as used in the Internet may be treated by the Internet community as
a de facto "standard". Such a specification is not generally if it were a "standard". Such a specification is not generally
developed in an open fashion, is typically proprietary, and is developed in an open fashion, is typically proprietary, and is
controlled by the vendor or vendors that produced it. controlled by the vendor or vendors that produced it.
To avoid conflict between competing versions of a specification, the To avoid conflict between competing versions of a specification, the
Internet community will not standardize a TS or AS that is simply an Internet community will not standardize a TS or AS that is simply an
"Internet version" of an existing external specification, unless an "Internet version" of an existing external specification, unless an
explicit cooperative arrangement to do so has been made. However, explicit cooperative arrangement to do so has been made. However,
there are several ways in which an external specification that is there are several ways in which an external specification that is
important for the operation and/or evolution of the Internet may be important for the operation and/or evolution of the Internet may be
adopted for Internet use. adopted for Internet use.
(a) Incorporation of an Open Standard (a) Incorporation of an Open Standard
An Internet Standard TS or AS may incorporate an open external An Internet Standard TS or AS may incorporate an open external
standard by reference. The reference must be to a specific standard by reference. The reference must be to a specific
version of the external standard, e.g., by publication date or version of the external standard, e.g., by publication date or
by edition number, according to the prevailing convention of the by edition number, according to the prevailing convention of the
organization that is responsible for the specification. organization that is responsible for the specification.
For example, many Internet Standards incorporate by reference For example, many Internet Standards incorporate by reference
the ANSI standard character set "ASCII" [7]. the ANSI standard character set "ASCII" [2]. Whenever possible,
the referenced specification shall be made available online.
(b) Incorporation of a Vendor Specification (b) Incorporation of a Vendor Specification
Vendor-proprietary specifications may also be incorporated, by Vendor-proprietary specifications may be incorporated by
reference to a specific version of the vendor standard. If the reference to a specific version of the vendor standard. If the
vendor-proprietary specification is not widely and readily vendor-proprietary specification is not widely and readily
available, the IAB may request that it be published as an available, the IESG may request that it be published as an
Informational RFC. | Informational RFC.
For a vendor-proprietary specification to be incorporated within | For a vendor-proprietary specification to be incorporated within
the Internet standards process, the proprietor must follow the | the Internet standards process, the proprietor must meet the
requirements of section 5 below. | requirements of section 5 below, and in general the
specification shall be made available online.
The IAB/IETF will generally not favor a particular vendor's The IESG shall not favor a particular vendor's proprietary
proprietary specification over the technically equivalent and specification over the technically equivalent and competing
competing specifications of other vendors by making it specifications of other vendors by making it "required" or
"required" or "recommended". "recommended".
(c) Assumption | (c) Assumption
An IETF Working Group may start from an external specification | An IETF Working Group may start from an external specification
and develop it into an Internet TS or AS, if the specification | and develop it into an Internet TS or AS, if the specification
is provided to the Working Group in compliance with the | is provided to the Working Group in compliance with the
requirements of section 5 below. Continued participation in the | requirements of section 5 below, and if change control must have
IETF work by the original owner is likely to be valuable, and it | been conveyed to IETf by the original developer of the
is encouraged. specification. Continued participation in the IETF work by the
original owner is likely to be valuable, and it is encouraged.
5. INTELLECTUAL PROPERTY RIGHTS | The following sample text illustrates how a vendor might convey
change control to the Internet Society, per (c):
In all matters of intellectual property rights, Internet's intention | "XXXX Organization asserts that it has the right to transfer to
is to benefit the Internet community and the public at large, while | the Internet Society responsibility for further evolution of the
respecting the known, legitimate rights of others. | YYYY protocol documented in References (1-n) below. XXXX
Organization hereby transfers to the Internet Society
responsibilty for all future modification and development of the
YYYY protocol, without reservation or condition."
In this section: | 5. INTELLECTUAL PROPERTY RIGHTS
o "applicable patents" or "applicable pending patents" means | [This section is current under review by ISOC counsel, and is not
purportedly valid patents or patent applications that | final.]
purportedly apply to technology required to practice an Internet |
standard. |
o "Trade secrets" means confidential, proprietary information. | In all matters of intellectual property rights, the intention is to
benefit the Internet community and the public at large, while
respecting the known, legitimate rights of others.
o "ISOC" includes the Internet Society, its directors, officers, | In this section:
employees, contractors, and agents, IAB, IETF, IESG, and |
Internet working groups and committees. |
o "Standards work" includes the creation, development, testing, | o "applicable patents" or "applicable pending patents" means
revision, adoption, or maintenance of an Internet standard. | purportedly valid patents or patent applications that
purportedly apply to technology required to practice an Internet
standard.
o "Standards documents" include specifications, RFCs, and | o "Trade secrets" means confidential, proprietary information.
proposed, draft, and adopted standards. |
o "Internet community" means the entire set of people using the | o "ISOC" includes the Internet Society, its trustees, officers,
Internet standards, directly or indirectly. | employees, contractors, and agents, IAB, IETF, IESG, IRTF, IRSG,
and Internet Working Groups, Research Groups, and committees.
5.1. Trade Secret Rights | o "Standards work" includes the creation, development, testing,
revision, adoption, or maintenance of an Internet standard.
ISOC will not accept, in connection with its standards work, any | o "Standards documents" include specifications, RFCs, and
technology or information subject to any commitment, | Proposed, Draft, and Internet Standards.
understanding, or agreement to keep it confidential or otherwise |
restrict its use or dissemination. |
5.2. Patent Rights | o "Internet community" means the entire set of people using the
Internet standards, directly or indirectly.
(A) ISOC will not propose, adopt, or continue to maintain any | 5.1 Trade Secret Rights
standard which can only be practiced using technology that is |
subject to known applicable patents or patent applications, |
except with prior written assurance that: |
1. ISOC may, without cost, freely use the technology in its | ISOC will not accept, in connection with its standards work, any
standards work, and | technology or information subject to any commitment,
understanding, or agreement to keep it confidential or otherwise
restrict its use or dissemination.
2. upon adoption and during maintenance of a standard, any | 5.2 Patent Rights
party will be able to obtain the right to use the |
technology under specified, reasonable, non- |
discriminatory terms. |
3. the party giving the assurance has the right and power | (A) ISOC will not propose, adopt, or continue to maintain any
to grant the licenses and knows of no other applicable | standard which can only be practiced using technology that is
patents or patent applications or other intellectual | subject to known applicable patents or patent applications,
property rights that may prevent ISOC and users of | except with prior written assurance that:
Internet from practicing the standard. |
When the written assurance has been obtained, the standards | 1. ISOC may, without cost, freely use the technology in its
documents shall include the following notice: | standards work, and
"__________(name of patent owner) has provided written | 2. upon adoption and during maintenance of a standard, any
assurance to the Internet Society that any party will be able | party will be able to obtain the right to use the
to obtain, under reasonable, nondiscriminatory terms, the | technology under specified, reasonable, non-
right to use the technology covered by__________(list patents | discriminatory terms.
and patent applications) to practice the standard. A copy of |
the assurance may be obtained from ________. The Internet |
Society takes no position on the validity or scope of the |
patents and patent applications, nor on the appropriateness |
of the terms of the assurance. The Internet Society makes no |
representation there are no other intellectual property |
rights which apply to practicing this standard, or that it |
has made any effort to identify any such intellectual |
property rights." |
(B) ISOC encourages all interested parties to bring to its | 3. the party giving the assurance has the right and power
attention, at the earliest possible time, the existence of | to grant the licenses and knows of no other applicable
any applicable patents or patent applications. For this | patents or patent applications or other intellectual
purpose, each standards document will include the following | property rights that may prevent ISOC and users of
invitation: | Internet standards from practicing the standard.
"The Internet Society invites any interested party to | When such written assurance has been obtained, the standards
bring to its attention any patents or patent applications | documents shall include the following notice:
which purport to cover technology that may be required to |
practice this standard. Address the information to |
__________." |
When applicable, the following sentence will be included in | "__________(name of patent owner) has provided written
the notice: | 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 patents and patent applications) to
practice the standard. A copy of the assurance may be
obtained from ________. The Internet Society takes no
position on the validity or scope of the patents and
patent applications, nor on the appropriateness of the
terms of the assurance. The Internet Society makes no
representation there are no other intellectual property
rights which apply to practicing this standard, nor that
it has made any effort to identify any such intellectual
property rights."
"As of __________, no information about any applicable patents| (B) ISOC encourages all interested parties to bring to its
or patent applications has been received." | attention, at the earliest possible time, the existence of
any applicable patents or patent applications. For this
purpose, each standards document will include the following
invitation:
(C) ISOC disclaims any responsibility to identify the existence | "The Internet Society invites any interested party to
of or to evaluate applicable patents or patent applications | bring to its attention any patents or patent applications
on behalf of or for the benefit of any member of the Internet | which purport to cover technology that may be required to
community. | practice this standard. Address the information to
the Executive Director of the Internet Society."
(D) ISOC takes no position on the validity or scope of any | When applicable, the following sentence will be included in
applicable patent or patent application. | the notice:
(E) ISOC will take no position on the ownership of inventions | "As of __________, no information about any applicable patents
made during standards work, except for inventions of which an | or patent applications has been received."
employee or agent of the Internet Society is a joint |
inventor. In the latter case, the Internet Society will make |
its rights available to anyone in the Internet community on a |
royalty-free basis. |
6. ACKNOWLEDGMENTS AND REFERENCES (C) ISOC disclaims any responsibility for identifying the
existence of or for evaluating applicable patents or patent
applications on behalf of or for the benefit of any member of
the Internet community.
This document represents the combined output of the Internet (D) ISOC takes no position on the validity or scope of any
Architecture Board and the Internet Engineering Steering Group, the applicable patent or patent application.
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, Barry Leiner, and Patrice Lyons. It
incorporates a number of useful suggestions made by IETF members.
[1] Cerf, V., "The Internet Activities Board", RFC 1160, IAB, May (E) ISOC will take no position on the ownership of inventions
1990. 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 to anyone in the Internet community on a
royalty-free basis.
[2] Postel, J., "IAB Official Protocol Standards", RFC 1280, IAB, [The following sections are to be written.]
March 1992.
[3] Braden, R., Editor, "Requirements for Internet Hosts -- 5.3 Copyright
Communication Layers", RFC 1122, IETF, October 1989. 5.4 Notices And Agreements
[4] Braden, R., Editor, "Requirements for Internet Hosts -- 5.4.1 Notices to appear in Standards Documents
Application and Support", RFC 1123, IETF, October 1989.
[5] Almquist, P., Editor, "Requirements for IP Routers", in 5.4.2 Confirmation of implied Licenses
preparation.
[6] Hinden, R., "Internet Engineering Task Force Internet Routing 5.4.3 Text
Protocol Standardization Criteria", RFC 1264, BBN, October 1991.
[7] ANSI, Coded Character Set -- 7-Bit American Standard Code for 6. REFERENCES
Information Interchange, ANSI X3.4-1986.
[8] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, ISI, [1] Postel, J., "IAB Official Protocol Standards", RFC 1410, IAB,
March 1990. March 1993.
[9] Postel, J., "Introduction to the STD Notes", RFC 1311, ISI, [2] ANSI, Coded Character Set -- 7-Bit American Standard Code for
March 1992. Information Interchange, ANSI X3.4-1986.
[10] Postel, J., "How to Write an RFC", RFC 1???, ISI, ????, 199?. [3] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340, ISI,
July 1992.
APPENDIX A: GLOSSARY [4] Postel, J., "Introduction to the STD Notes", RFC 1311, ISI,
March 1992.
ANSI: American National Standards Institute [5] Postel, J., "Request for Comments on Request for Comments", RFC
1111, August 1989.
CCITT: Consultative Committee for International Telephone and APPENDIX A: GLOSSARY OF ACRONYMS
Telegraphy.
A part of the UN Treaty Organization: the International ANSI: American National Standards Institute
Telecommunications Union (ITU). ARPA: (U.S.) Advanced Research Projects Agency
AS: Applicability Statement
ASCII: American Standard Code for Information Interchange
ITU-TS: Telecommunications Standardization sector of the International
Telecommunications Union (ITU), a UN treaty organization;
ITU-TS was formerly called CCITT.
IAB: Internet Architecture Board
IANA: Internet Assigned Number 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
DARPA: (U.S.) Defense Advanced Research Projects Agency APPENDIX B: CONTACT POINTS
ISO: International Organization for Standardization To contact the RFC Editor, send an email message to: "rfc-
editor@isi.edu".
APPENDIX B: CONTACT POINTS | 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 RFC Editor, send an email message to "rfc- | To contact the IESG, send an email message to: "iesg@isi.edu".
editor@isi.edu". |
To contact the IANA for information or to request a number, keyword | To contact the IAB, send an email message to: "iab-contact@isi.edu"
or parameter assignment send an email message to "iana@isi.edu". |
To contact the IESG, send an email message to "iesg@isi.edu". | To contact the Executive Director of the ISOC, send an email message
to Executive-Director@isoc.org".
To contact the IAB, send an email message to "iab-contact@isi.edu" 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.
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 the every standards RFC
should include an email list for the responsible Working Group.
Security Considerations Security Considerations
Security issues are not substantially discussed in this memo. Security issues are not substantially discussed in this memo.
Authors' Address Author's Address
A. Lyman Chapin Christian Huitema, IAB Chairman
BBN Communications Corporation INRIA, Sophia-Antipolis
150 Cambridge Park Drive 2004 Route des Lucioles
Cambridge, MA 02140 BP 109
F-06561 Valbonne Cedex
France
Phone: 617-873-3133 Phone: +33 93 65 77 15
Fax: 617-873-4086
Email: Lyman@BBN.COM EMail: Christian.Huitema@MIRSA.INRIA.FR
Bob Braden Phill Gross, IESG Chairman
University of Southern California Advanced Network and Services
Information Sciences Institute 100 Clearbrook Road
4676 Admiralty Way Elmsford, NY 10523
Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: 914-789-5335
EMail: Braden@ISI.EDU EMail: pgross@nis.ans.net
 End of changes. 163 change blocks. 
573 lines changed or deleted 762 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/