parties at the IESG level, any of the parties involved may appeal the
decision to the IAB. The IAB shall then review the situation and
attempt to resolve it in a manner of its own choosing.
The IAB decision is final with respect to the question of whether or
not the Internet standards procedures have been followed and with
respect to all questions of technical merit.
6.5.2 Process Failures
This document sets forward procedures required to be followed to
ensure openness and fairness of the Internet Standards Process, and
the technical viability of the standards created. The IESG is the
principal agent of the IETF for this purpose, and it is the IESG that
is charged with ensuring that the required procedures have been
followed, and that any necessary prerequisites to a standards action
have been met.
If an individual should disagree with an action taken by the IESG in
this process, that person should first discuss the issue with the
ISEG Chair. If the IESG Chair is unable to satisfy the complainant
then the IESG as a whole should re-examine the action taken, along
with input from the complainant, and determine whether any further
action is needed. The IESG shall issue a report on its review of the
complaint to the IETF.
Should the complainant not be satisfied with the outcome of the IESG
review, an appeal may be lodged to the IAB. The IAB shall then review
the situation and attempt to resolve it in a manner of its own
choosing and report to the IETF on the outcome of its review.
If circumstances warrant, the IAB may direct that an IESG decision be
annulled, and the situation shall then be as it was before the IESG
decision was taken. The IAB may also recommend an action to the IESG,
or make such other recommendations as it deems fit. The IAB may not,
however, pre-empt the role of the IESG by issuing a decision which
only the IESG is empowered to make.
The IAB decision is final with respect to the question of whether or
not the Internet standards procedures have been followed.
6.5.3 Questions of Applicable Procedure
Further recourse is available only in cases in which the procedures
themselves (i.e., the procedures described in this document) are
claimed to be inadequate or insufficient to the protection of the
rights of all parties in a fair and open Internet Standards Process.
Claims on this basis may be made to the Internet Society Board of
Trustees. The President of the Internet Society shall acknowledge
such an appeal within two weeks, and shall at the time of
acknowledgment advise the petitioner of the expected duration of the
Trustees' review of the appeal. The Trustees shall review the
situation in a manner of its own choosing and report to the IETF on
the outcome of its review.
The Trustees' decision upon completion of their review shall be final
with respect to all aspects of the dispute.
6.5.4 Appeals Procedure
All appeals must include a detailed and specific description of the
facts of the dispute.
All appeals must be initiated within two months of the public
knowledge of the action or decision to be challenged.
At all stages of the appeals process, the individuals or bodies
responsible for making the decisions have the discretion to define
the specific procedures they will follow in the process of making
their decision.
In all cases a decision concerning the disposition of the dispute,
and the communication of that decision to the parties involved, must
be accomplished within a reasonable period of time.
[NOTE: These procedures intentionally and explicitly do not
establish a fixed maximum time period that shall be considered
"reasonable" in all cases. The Internet Standards Process places a
premium on consensus and efforts to achieve it, and deliberately
foregoes deterministically swift execution of procedures in favor of
a latitude within which more genuine technical agreements may be
reached.]
7. EXTERNAL STANDARDS AND SPECIFICATIONS
Many standards groups other than the IETF create and publish
standards documents for network protocols and services. When these
external specifications play an important role in the Internet, it is
desirable to reach common agreements on their usage -- i.e., to
establish Internet Standards relating to these external
specifications.
There are two categories of external specifications:
(1) Open Standards
Various national and international standards bodies, such as ANSI,
ISO, IEEE, and ITU-T, develop a variety of protocol and service
specifications that are similar to Technical Specifications
defined here. National and international groups also publish
"implementors' agreements" that are analogous to Applicability
Statements, capturing a body of implementation-specific detail
concerned with the practical application of their standards. All
of these are considered to be "open external standards" for the
purposes of the Internet Standards Process.
(2) Other Specifications
Other proprietary specifications that have come to be widely used
in the Internet may be treated by the Internet community as if
they were a "standards". Such a specification is not generally
developed in an open fashion, is typically proprietary, and is
controlled by the vendor, vendors, or organization that produced
it.
7.1 Use of External Specifications
To avoid conflict between competing versions of a specification, the
Internet community will not standardize a specification that is
simply an "Internet version" of an existing external specification
unless an explicit cooperative arrangement to do so has been made.
However, there are several ways in which an external specification
that is important for the operation and/or evolution of the Internet
may be adopted for Internet use.
7.1.1 Incorporation of an Open Standard
An Internet Standard TS or AS may incorporate an open external
standard by reference. For example, many Internet Standards
incorporate by reference the ANSI standard character set "ASCII" [2].
Whenever possible, the referenced specification shall be available
online.
7.1.2 Incorporation of Other Specifications
Other proprietary specifications may be incorporated by reference to
a version of the specification as long as the proprietor meets the
requirements of section 10. If the other proprietary specification
is not widely and readily available, the IESG may request that it be
published as an Informational RFC.
The IESG generally should not favor a particular proprietary
specification over technically equivalent and competing
specification(s) by making any incorporated vendor specification
"required" or "recommended".
7.1.3 Assumption
An IETF Working Group may start from an external specification and
develop it into an Internet specification. This is acceptable if (1)
the specification is provided to the Working Group in compliance with
the requirements of section 10, and (2) change control has been
conveyed to IETF by the original developer of the specification for
the specification or for specifications derived from the original
specification.
8. NOTICES AND RECORD KEEPING
Each of the organizations involved in the development and approval of
Internet Standards shall publicly announce, and shall maintain a
publicly accessible record of, every activity in which it engages, to
the extent that the activity represents the prosecution of any part
of the Internet Standards Process. For purposes of this section, the
organizations involved in the development and approval of Internet
Standards includes the IETF, the IESG, the IAB, all IETF Working
Groups, and the Internet Society Board of Trustees.
For IETF and Working Group meetings announcements shall be made by
electronic mail to the IETF Announce mailing list and shall be made
sufficiently far in advance of the activity to permit all interested
parties to effectively participate. The announcement shall contain
(or provide pointers to) all of the information that is necessary to
support the participation of any interested individual. In the case
of a meeting, for example, the announcement shall include an agenda
that specifies the standards- related issues that will be discussed.
The formal record of an organization's standards-related activity
shall include at least the following:
o the charter of the organization (or a defining document equivalent
to a charter);
o complete and accurate minutes of meetings;
o the archives of Working Group electronic mail mailing lists; and
o all written contributions from participants that pertain to the
organization's standards-related activity.
As a practical matter, the formal record of all Internet Standards
Process activities is maintained by the IETF Secretariat, and is the
responsibility of the IETF Secretariat except that each IETF Working
Group is expected to maintain their own email list archive and must
make a best effort to ensure that all traffic is captured and
included in the archives. Also, the Working Group chair is
responsible for providing the IETF Secretariat with complete and
accurate minutes of all Working Group meetings. Internet-Drafts that
have been removed (for any reason) from the Internet-Drafts
directories shall be archived by the IETF Secretariat for the sole
purpose of preserving an historical record of Internet standards
activity and thus are not retrievable except in special
circumstances.
9. VARYING THE PROCESS
This document, which sets out the rules and procedures by which
Internet Standards and related documents are made is itself a product
of the Internet Standards Process (as a BCP, as described in section
5). It replaces a previous version, and in time, is likely itself to
be replaced.
While, when published, this document represents the community's view
of the proper and correct process to follow, and requirements to be
met, to allow for the best possible Internet Standards and BCPs, it
cannot be assumed that this will always remain the case. From time to
time there may be a desire to update it, by replacing it with a new
version. Updating this document uses the same open procedures as are
used for any other BCP.
In addition, there may be situations where following the procedures
leads to a deadlock about a specific specification, or there may be
situations where the procedures provide no guidance. In these cases
it may be appropriate to invoke the variance procedure described
below.
9.1 The Variance Procedure
Upon the recommendation of the responsible IETF Working Group (or, if
no Working Group is constituted, upon the recommendation of an ad hoc
committee), the IESG may enter a particular specification into, or
advance it within, the standards track even though some of the
requirements of this document have not or will not be met. The IESG
may approve such a variance, however, only if it first determines
that the likely benefits to the Internet community are likely to
outweigh any costs to the Internet community that result from
noncompliance with the requirements in this document. In exercising
this discretion, the IESG shall at least consider (a) the technical
merit of the specification, (b) the possibility of achieving the
goals of the Internet Standards Process without granting a variance,
(c) alternatives to the granting of a variance, (d) the collateral
and precedential effects of granting a variance, and (e) the IESG's
ability to craft a variance that is as narrow as possible. In
determining whether to approve a variance, the IESG has discretion to
limit the scope of the variance to particular parts of this document
and to impose such additional restrictions or limitations as it
determines appropriate to protect the interests of the Internet
community.
The proposed variance must detail the problem perceived, explain the
precise provision of this document which is causing the need for a
variance, and the results of the IESG's considerations including
consideration of points (a) through (d) in the previous paragraph.
The proposed variance shall be issued as an Internet Draft. The IESG
shall then issue an extended Last-Call, of no less than 4 weeks, to
allow for community comment upon the proposal.
In a timely fashion after the expiration of the Last-Call period, the
IESG shall make its final determination of whether or not to approve
the proposed variance, and shall notify the IETF of its decision via
electronic mail to the IETF Announce mailing list. If the variance
is approved it shall be forwarded to the RFCEditor with a request
that it be published as a BCP.
This variance procedure is for use when a one-time waving of some
provision of this document is felt to be required. Permanent changes
to this document shall be accomplished through the normal BCP
process.
The appeals process in section 6.5 applies to this process.
9.2 Exclusions
No use of this procedure may lower any specified delays, nor exempt
any proposal from the requirements of openness, fairness, or
consensus, nor from the need to keep proper records of the meetings
and mailing list discussions.
Specifically, the following sections of this document must not be
subject of a variance: 5.1, 6.1, 6.1.1 (first paragraph), 6.1.2, 6.3
(first sentence), 6.5 and 9.
10. INTELLECTUAL PROPERTY RIGHTS
10.1. General Policy
In all matters of intellectual property rights and procedures, the
intention is to benefit the Internet community and the public at
large, while respecting the legitimate rights of others.
10.2 Confidentiality Obligations
No contribution that is subject to any requirement of confidentiality
or any restriction on its dissemination may be considered in any part
of the Internet Standards Process, and there must be no assumption of
any confidentiality obligation with respect to any such contribution.
10.3. Rights and Permissions
In the course of standards work, the IETF receives contributions in
various forms and from many persons. To best facilitate the
dissemination of these contributions, it is necessary to understand
any intellectual property rights (IPR) relating to the contributions.
10.3.1. All Contributions
By submission of a contribution, each person actually submitting the
contribution is deemed to agree to the following terms and conditions
on his own behalf, on behalf of the organization (if any) he
represents and on behalf of the owners of any propriety rights in the
contribution.. Where a submission identifies contributors in
addition to the contributor(s) who provide the actual submission, the
actual submitter(s) represent that each other named contributor was
made aware of and agreed to accept the same terms and conditions on
his own behalf, on behalf of any organization he may represent and
any known owner of any proprietary rights in the contribution.
l. Some works (e.g. works of the U.S. Government) are not subject to
copyright. However, to the extent that the submission is or may
be subject to copyright, the contributor, the organization he
represents (if any) and the owners of any proprietary rights in
the contribution, grant an unlimited perpetual, non-exclusive,
royalty-free, world-wide right and license to the ISOC and the
IETF under any copyrights in the contribution. This license
includes the right to copy, publish and distribute the
contribution in any way, and to prepare derivative works that are
based on or incorporate all or part of the contribution, the
license to such derivative works to be of the same scope as the
license of the original contribution.
2. The contributor acknowledges that the ISOC and IETF have no duty
to publish or otherwise use or disseminate any contribution.
3. The contributor grants permission to reference the name(s) and
address(es) of the contributor(s) and of the organization(s) he
represents (if any).
4. The contributor represents that contribution properly acknowledge
major contributors.
5. The contribuitor, the organization (if any) he represents and the
owners of any proprietary rights in the contribution, agree that
no information in the contribution is confidential and that the
ISOC and its affiliated organizations may freely disclose any
information in the contribution.
6. The contributor represents that he has disclosed the existence of
any proprietary or intellectual property rights in the
contribution that are reasonably and personally known to the
contributor. The contributor does not represent that he
personally knows of all potentially pertinent proprietary and
intellectual property rights owned or claimed by the organization
he represents (if any) or third parties.
7. The contributor represents that there are no limits to the
contributor's ability to make the grants acknowledgments and
agreements above that are reasonably and personally known to the
contributor.
By ratifying this description of the IETF process the Internet
Society warrants that it will not inhibit the traditional open and
free access to IETF documents for which license and right have
been assigned according to the procedures set forth in this
section, including Internet-Drafts and RFCs. This warrant is
perpetual and will not be revoked by the Internet Society or its
successors or assigns.
10.3.2. Standards Track Documents
(A) Where any patents, patent applications, or other proprietary
rights are known, or claimed, with respect to any specification on
the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the
document a note indicating the existence of such rights, or
claimed rights. Where implementations are required before
advancement of a specification, only implementations that have, by
statement of the implementors, taken adequate steps to comply with
any such rights, or claimed rights, shall be considered for the
purpose of showing the adequacy of the specification.
(B) The IESG disclaims any responsibility for identifying the
existence of or for evaluating the applicability of any claimed
copyrights, patents, patent applications, or other rights in the
fulfilling of the its obligations under (A), and will take no
position on the validity or scope of any such rights.
(C) Where the IESG knows of rights, or claimed rights under (A), the
IETF Executive Director shall attempt to obtain from the claimant
of such rights, a written assurance that upon approval by the IESG
of the relevant Internet standards track specification(s), any
party will be able to obtain the right to implement, use and
distribute the technology or works when implementing, using or
distributing technology based upon the specific specification(s)
under openly specified, reasonable, non-discriminatory terms.
The Working Group proposing the use of the technology with respect
to which the proprietary rights are claimed may assist the IETF
Executive Director in this effort. The results of this procedure
shall not affect advancement of a specification along the
standards track, except that the IESG may defer approval where a
delay may facilitate the obtaining of such assurances. The
results will, however, be recorded by the IETF Executive Director,
and made available. The IESG may also direct that a summary of
the results be included in any RFCpublished containing the
specification.
10.3.3 Determination of Reasonable and Non-discriminatory Terms
The IESG will not make any explicit determination that the assurance
of reasonable and non-discriminatory terms for the use of a
technology has been fulfilled in practice. It will instead use the
normal requirements for the advancement of Internet Standards to
verify that the terms for use are reasonable. If the two unrelated
implementations of the specification that are required to advance
from Proposed Standard to Draft Standard have been produced by
different organizations or individuals or if the "significant
implementation and successful operational experience" required to
advance from Draft Standard to Standard has been achieved the
assumption is that the terms must be reasonable and to some degree,
non-discriminatory. This assumption may be challenged during the
Last-Call period.
10.4. Notices
(A) Standards track documents shall include the following notice:
"The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."
(B) The IETF encourages all interested parties to bring to its
attention, at the earliest possible time, the existence of any
intellectual property rights pertaining to Internet Standards.
For this purpose, each standards document shall include the
following invitation:
"The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director."
(C) The following copyright notice and disclaimer shall be included
in all ISOC standards-related documentation:
"Copyright (C) The Internet Society (date). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implmentation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
(D) Where the IESG is aware at the time of publication of
proprietary rights claimed with respect to a standards track
document, or the technology described or referenced therein, such
document shall contain the following notice:
"The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights."
11. ACKNOWLEDGMENTS
There have been a number of people involved with the development of
the documents defining the IETF Standards Process over the years.
The process was first described in RFC1310 then revised in RFC1602
before the current effort (which relies heavily on its predecessors).
Specific acknowledgments must be extended to Lyman Chapin, Phill
Gross and Christian Huitema as the editors of the previous versions,
to Jon Postel and Dave Crocker for their inputs to those versions, to
Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their
reviews of the legal aspects of the procedures described herein, and
to John Stewart, Robert Elz and Steve Coya for their extensive input
on the final version.
In addition much of the credit for the refinement of the details of
the IETF processes belongs to the many members of the various
incarnations of the POISED Working Group.
12. SECURITY CONSIDERATIONS
Security issues are not discussed in this memo.
13. REFERENCES
[1] Postel, J., "Internet Official Protocol Standards", STD 1,
USC/Information Sciences Institute, March 1996.
[2] ANSI, Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[4] Postel, J., "Introduction to the STD Notes", RFC1311,
USC/Information Sciences Institute, March 1992.
[5] Postel, J., "Instructions to RFCAuthors", RFC1543,
USC/Information Sciences Institute, October 1993.
[6] Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
Standards", RFC1796, April 1995.
14. DEFINITIONS OF TERMS
IETF Area - A management division within the IETF. An Area consists
of Working Groups related to a general topic such as routing. An
Area is managed by one or two Area Directors.
Area Director - The manager of an IETF Area. The Area Directors
along with the IETF Chair comprise the Internet Engineering
Steering Group (IESG).
File Transfer Protocol (FTP) - An Internet application used to
transfer files in a TCP/IP network.
gopher - An Internet application used to interactively select and
retrieve files in a TCP/IP network.
Internet Architecture Board (IAB) - An appointed group that assists
in the management of the IETF standards process.
Internet Engineering Steering Group (IESG) - A group comprised of the
IETF Area Directors and the IETF Chair. The IESG is responsible
for the management, along with the IAB, of the IETF and is the
standards approval board for the IETF.
interoperable - For the purposes of this document, "interoperable"
means to be able to interoperate over a data communications path.
Last-Call - A public comment period used to gage the level of
consensus about the reasonableness of a proposed standards action.
(see section 6.1.2)
online - Relating to information made available over the Internet.
When referenced in this document material is said to be online
when it is retrievable without restriction or undue fee using
standard Internet applications such as anonymous FTP, gopher or
the WWW.
Working Group - A group chartered by the IESG and IAB to work on a
specific specification, set of specifications or topic.
15. AUTHOR'S ADDRESS
Scott O. Bradner
Harvard University
Holyoke Center, Room 813
1350 Mass. Ave.
Cambridge, MA 02138
USA
Phone: +1 617 495 3864
EMail: sob@harvard.edu
APPENDIX A: GLOSSARY OF ACRONYMS
ANSI: American National Standards Institute
ARPA: (U.S.) Advanced Research Projects Agency
AS: Applicability Statement
FTP: File Transfer Protocol
ASCII: American Standard Code for Information Interchange
ITU-T: Telecommunications Standardization sector of the
International Telecommunication Union (ITU), a UN
treaty organization; ITU-T was formerly called CCITT.
IAB: Internet Architecture Board
IANA: Internet Assigned Numbers Authority
IEEE: Institute of Electrical and Electronics Engineers
ICMP: Internet Control Message Protocol
IESG: Internet Engineering Steering Group
IETF: Internet Engineering Task Force
IP: Internet Protocol
IRSG Internet Research Steering Group
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
WWW: World Wide Web