< draft-ietf-poised95-std-proc-3-02.txt   draft-ietf-poised95-std-proc-3-03.txt >
Network Working Group S. Bradner Network Working Group S. Bradner
Internet-Draft Harvard University Internet-Draft Harvard University
Editor Editor
January 1996 February 1996
Expires in six months
The Internet Standards Process -- Revision 3 The Internet Standards Process -- Revision 3
a proposed revision of part of RFC 1602 a proposed revision of part of RFC 1602
<draft-ietf-poised95-std-proc-3-02.txt> <draft-ietf-poised95-std-proc-3-03.txt>
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. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 2, line 11 skipping to change at page 2, line 11
document between stages and the types of documents used during this document between stages and the types of documents used during this
process. It also addresses the intellectual property rights and process. It also addresses the intellectual property rights and
copyright issues associated with the standards process. copyright issues associated with the standards process.
Table of Contents Table of Contents
Status of this Memo.................................................1 Status of this Memo.................................................1
Abstract............................................................1 Abstract............................................................1
1. INTRODUCTION....................................................3 1. INTRODUCTION....................................................3
1.1 Internet Standards...........................................3 1.1 Internet Standards...........................................3
1.2 The Internet Standards Process...............................3 1.2 The Internet Standards Process...............................4
1.3 Organization of This Document................................5 1.3 Organization of This Document................................5
2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................5 2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................6
2.1 Requests for Comments (RFCs).................................5 2.1 Requests for Comments (RFCs).................................6
2.2 Internet-Drafts..............................................7 2.2 Internet-Drafts..............................................7
3. INTERNET STANDARD SPECIFICATIONS................................8 3. INTERNET STANDARD SPECIFICATIONS................................8
3.1 Technical Specification (TS).................................8 3.1 Technical Specification (TS).................................8
3.2 Applicability Statement (AS).................................8 3.2 Applicability Statement (AS).................................8
3.3 Requirement Levels...........................................9 3.3 Requirement Levels...........................................9
4. THE INTERNET STANDARDS TRACK...................................10 4. THE INTERNET STANDARDS TRACK...................................10
4.1 Standards Track Maturity Levels.............................10 4.1 Standards Track Maturity Levels.............................11
4.1.1 Proposed Standard.......................................10 4.1.1 Proposed Standard.......................................11
4.1.2 Draft Standard..........................................11 4.1.2 Draft Standard..........................................12
4.1.3 Internet Standard.......................................12 4.1.3 Internet Standard.......................................12
4.2 Non-Standards Track Maturity Levels.........................12 4.2 Non-Standards Track Maturity Levels.........................12
4.2.1 Experimental............................................12 4.2.1 Experimental............................................13
4.2.2 Informational...........................................13 4.2.2 Informational...........................................13
4.2.3 Procedures for Experimental and Informational RFCs......13 4.2.3 Procedures for Experimental and Informational RFCs......13
4.2.4 Historic................................................14 4.2.4 Historic................................................14
5. BEST CURRENT PRACTICE (BCP) RFCs...............................14 5. BEST CURRENT THINKING ABOUT PRACTICE (BCP) RFCs................14
5.1 BCP Review Process..........................................15 5.1 BCP Review Process..........................................15
6. THE INTERNET STANDARDS PROCESS.................................15 6. THE INTERNET STANDARDS PROCESS.................................16
6.1 Standards Actions...........................................16 6.1 Standards Actions...........................................16
6.1.1 Initiation of Action....................................16 6.1.1 Initiation of Action....................................16
6.1.2 IESG Review and Approval................................16 6.1.2 IESG Review and Approval................................17
6.1.3 Publication.............................................17 6.1.3 Publication.............................................18
6.2 Advancing in the Standards Track............................17 6.2 Advancing in the Standards Track............................18
6.3 Revising a Standard.........................................19 6.3 Revising a Standard.........................................19
6.4 Retiring a Standard.........................................19 6.4 Retiring a Standard.........................................19
6.5 Conflict Resolution and Appeals.............................19 6.5 Conflict Resolution and Appeals.............................20
7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................21 6.5.1 Working Group disputes...................................20
7.1 Use of External Specifications..............................21 6.5.2 Process Failures.........................................21
7.1.1 Incorporation of an Open Standard.......................22 6.5.3 Questions of applicable procedure........................21
7.1.2 Incorporation of a Vendor Standard......................22 6.5.4 Appeals procedure........................................22
7.1.3 Assumption..............................................22 7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................22
8 NOTICES AND RECORD KEEPING......................................22 7.1 Use of External Specifications..............................23
9. INTELLECTUAL PROPERTY RIGHTS...................................23 7.1.1 Incorporation of an Open Standard.......................23
9.1. General Policy.............................................23 7.1.2 Incorporation of a Other Specifications.................23
9.2 Confidentiality Obligations................................23 7.1.3 Assumption..............................................24
9.3. Rights and Permissions.....................................24 8. NOTICES AND RECORD KEEPING......................................24
9.3.1. All Contributions.......................................24 9. VARYING THE PROCESS.............................................25
9.4.2. Standards Track Documents...............................24 9.1 The Variance Procedure.......................................25
9.4.3 Determination of Reasonable and 9.2 Exclusions...................................................26
Non-discriminatory Terms................................25 10. INTELLECTUAL PROPERTY RIGHTS..................................26
9.5. Notices....................................................25 10.1. General Policy............................................26
10. ACKNOWLEDGMENTS................................................27 10.2 Confidentiality Obligations...............................27
11. SECURITY CONSIDERATIONS........................................27 10.3. Rights and Permissions....................................27
12. REFERENCES.....................................................27 10.3.1. All Contributions......................................27
13 .AUTHORS' ADDRESS...............................................28 10.3.2. Standards Track Documents..............................28
10.3.3 Determination of Reasonable and
Non-discriminatory Terms................................28
10.4. Notices...................................................29
11. ACKNOWLEDGMENTS................................................30
12. SECURITY CONSIDERATIONS........................................30
13. REFERENCES.....................................................30
14. DEFINITIONS OF TERMS...........................................31
15 .AUTHORS' ADDRESS...............................................32
APPENDIX A: DEFINITIONS OF TERMS...................................28 APPENDIX A: GLOSSARY OF ACRONYMS...................................32
APPENDIX B: GLOSSARY OF ACRONYMS...................................28
1. INTRODUCTION 1. INTRODUCTION
This memo documents the process currently used by the Internet This memo documents the process currently used by the Internet
community for the standardization of protocols and procedures. The community for the standardization of protocols and procedures. The
Internet Standards process is an activity of the Internet Society Internet Standards process is an activity of the Internet Society
that is organized and managed on behalf of the Internet community by that is organized and managed on behalf of the Internet community by
the Internet Architecture Board (IAB) and the Internet Engineering the Internet Architecture Board (IAB) and the Internet Engineering
Steering Group (IESG). Steering Group (IESG).
skipping to change at page 5, line 25 skipping to change at page 5, line 32
as a major tenet of Internet philosophy. as a major tenet of Internet philosophy.
The procedures described in this document are the result of a number The procedures described in this document are the result of a number
of years of evolution, driven both by the needs of the growing and of 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.
1.3 Organization of This Document 1.3 Organization of This Document
Section 2 describes the publications and archives of the Internet Section 2 describes the publications and archives of the Internet
standards process, and specifies the requirements for record-keeping standards process, and specifies the requirements for record-keeping
and public access to information. Section 3 describes the Internet and public access to information. Section 3 describes the types of
standards track. Section 4 describes the types of Internet standard Internet standard specifications. Section 4 describes the Internet
specification. Section 5 describes the process and rules for Internet standards specifications track. Section 5 describes Best Current
standardization. Section 6 specifies the way in which externally- Practice RFCs. Section 6 describes the process and rules for
sponsored specifications and practices, developed and controlled by Internet standardization. Section 7 specifies the way in which
other standards bodies or by vendors, are handled within the Internet externally-sponsored specifications and practices, developed and
standards process. Section 7 presents the rules that are required to controlled by other standards bodies or by others, are handled within
protect intellectual property rights in the context of the the Internet standards process. Section 8 describes the requirements
development and use of Internet Standards. Section 8 contains a list for notices and record keeping Section 9 defines a variance process
of numbered references. to allow one-time exceptions to some of the requirements in this
document Section 10 presents the rules that are required to protect
Appendix A contains definitions of some of the terms used in this intellectual property rights in the context of the development and
document. Appendix B contains a list of frequently-used acronyms. use of Internet Standards. Section 11 includes acknowledgments of
some of the people involved in creation of this document. Section 12
notes that security issues are not dealt with by this document.
Section 13 contains a list of numbered references. Section 14
contains definitions of some of the terms used in this document.
Section 15 lists the authors' email and postal addresses. Appendix A
contains a list of frequently-used acronyms.
2. INTERNET STANDARDS-RELATED PUBLICATIONS 2. INTERNET STANDARDS-RELATED PUBLICATIONS
2.1 Requests for Comments (RFCs) 2.1 Requests for Comments (RFCs)
Each distinct version of an Internet standards-related specification Each distinct version of an Internet standards-related specification
is published as part of the "Request for Comments" (RFC) document is published as part of the "Request for Comments" (RFC) document
series. This archival series is the official publication channel for series. This archival series is the official publication channel for
Internet standards documents and other publications of the IESG, IAB, Internet standards documents and other publications of the IESG, IAB,
and Internet community. RFCs can be obtained from a number of and Internet community. RFCs can be obtained from a number of
skipping to change at page 6, line 12 skipping to change at page 6, line 26
The RFC series of documents on networking began in 1969 as part of The RFC series of documents on networking began in 1969 as part of
the original ARPA wide-area networking (ARPANET) project (see the original ARPA wide-area networking (ARPANET) project (see
Appendix A for glossary of acronyms). RFCs cover a wide range of Appendix A for glossary of acronyms). RFCs cover a wide range of
topics in addition to Internet Standards, from early discussion of topics in addition to Internet Standards, from early discussion of
new research concepts to status memos about the Internet. RFC new research concepts to status memos about the Internet. RFC
publication is the direct responsibility of the RFC Editor, under the publication is the direct responsibility of the RFC Editor, under the
general direction of the IAB. general direction of the IAB.
The rules for formatting and submitting an RFC are defined in [5]. The rules for formatting and submitting an RFC are defined in [5].
Every RFC is available in ASCII text. Some RFCs are also available Every RFC is available in ASCII text. Some RFCs are also available
in PostScript(R). The PostScript(R) version of an RFC may contain in other formats. The other versions of an RFC may contain material
material (such as diagrams and figures) that is not present in the (such as diagrams and figures) that is not present in the ASCII
ASCII version, and it may be formatted differently. version, and it may be formatted differently.
********************************************************* *********************************************************
* * * *
* A stricter requirement applies to standards-track * * A stricter requirement applies to standards-track *
* specifications: the ASCII text version is the * * specifications: the ASCII text version is the *
* definitive reference, and therefore it must be a * * definitive reference, and therefore it must be a *
* complete and accurate specification of the standard, * * complete and accurate specification of the standard, *
* including all necessary diagrams and illustrations. * * including all necessary diagrams and illustrations. *
* * * *
********************************************************* *********************************************************
skipping to change at page 7, line 13 skipping to change at page 7, line 25
of the RFC Editor in consultation with the IESG (see section 4.2). of the RFC Editor in consultation with the IESG (see section 4.2).
******************************************************** ********************************************************
* * * *
* 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. In the same way, not all RFCs * * Internet Standard. In the same way, not all RFCs *
* which describe current practices have been given * * which describe current practices have been given *
* the review and approval to become BCPs. See * * the review and approval to become BCPs. See *
* RFC-1796 for further information. * * RFC-1796 [7] for further information. *
* * * *
******************************************************** ********************************************************
2.2 Internet-Drafts 2.2 Internet-Drafts
During the development of a specification, draft versions of the During the development of a specification, draft versions of the
document are made available for informal review and comment by document are made available for informal review and comment by
placing them in the IETF's "Internet-Drafts" directory, which is placing them in the IETF's "Internet-Drafts" directory, which is
replicated on a number of Internet hosts. This makes an evolving replicated on a number of Internet hosts. This makes an evolving
working document readily available to a wide audience, facilitating working document readily available to a wide audience, facilitating
skipping to change at page 8, line 19 skipping to change at page 8, line 32
one of two categories: Technical Specification (TS) and one of two categories: Technical Specification (TS) and
Applicability Statement (AS). Applicability Statement (AS).
3.1 Technical Specification (TS) 3.1 Technical Specification (TS)
A Technical Specification is any description of a protocol, service, A Technical Specification is any description of a protocol, service,
procedure, convention, or format. It may completely describe all of procedure, convention, or format. It may completely describe all of
the relevant aspects of its subject, or it may leave one or more the relevant aspects of its subject, or it may leave one or more
parameters or options unspecified. A TS may be completely self- parameters or options unspecified. A TS may be completely self-
contained, or it may incorporate material from other specifications contained, or it may incorporate material from other specifications
by reference to other documents (which may or may not be Internet by reference to other documents (which might or might not be Internet
Standards). Standards).
A TS shall include a statement of its scope and the general intent A TS shall include a statement of its scope and the general intent
for its use (domain of applicability). Thus, a TS that is inherently for its use (domain of applicability). Thus, a TS that is inherently
specific to a particular context shall contain a statement to that specific to a particular context shall contain a statement to that
effect. However, a TS does not specify requirements for its use effect. However, a TS does not specify requirements for its use
within the Internet; these requirements, which depend on the within the Internet; these requirements, which depend on the
particular context in which the TS is incorporated by different particular context in which the TS is incorporated by different
system configurations, are defined by an Applicability Statement. system configurations, are defined by an Applicability Statement.
skipping to change at page 11, line 45 skipping to change at page 12, line 10
However, since the content of Proposed Standards may be changed if However, since the content of Proposed Standards may be changed if
problems are found or better solutions are identified, deploying problems are found or better solutions are identified, deploying
implementations of such standards into a disruption-sensitive implementations of such standards into a disruption-sensitive
customer base is not recommended. customer base is not recommended.
4.1.2 Draft Standard 4.1.2 Draft Standard
A specification from which at least two independent and interoperable A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and implementations from different code bases have been developed, and
for which sufficient successful operational experience has been for which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level. If patented obtained, may be elevated to the "Draft Standard" level. For the
or otherwise controlled technology is required for implementation, purposes of this section, "interoperable" means to be able to
the separate implementations must also have resulted from separate interoperate over a data communications path. If patented or
otherwise controlled technology is required for implementation, the
separate implementations must also have resulted from separate
exercise of the licensing process. Elevation to Draft Standard is a exercise of the licensing process. Elevation to Draft Standard is a
major advance in status, indicating a strong belief that the major advance in status, indicating a strong belief that the
specification is mature and will be useful. specification is mature and will be useful.
The requirement for at least two independent and interoperable The requirement for at least two independent and interoperable
implementations applies to all of the options and features of the implementations applies to all of the options and features of the
specification. In cases in which one or more options or features specification. In cases in which one or more options or features
have not been demonstrated in at least two interoperable have not been demonstrated in at least two interoperable
implementations, the specification may advance to the Draft Standard implementations, the specification may advance to the Draft Standard
level only if those options or features are removed. level only if those options or features are removed.
skipping to change at page 15, line 37 skipping to change at page 15, line 50
are not well suited to the phased roll-in nature of the three stage are not well suited to the phased roll-in nature of the three stage
standards track and instead generally only make sense for full and standards track and instead generally only make sense for full and
immediate instantiation. immediate instantiation.
The BCP process is similar to that for proposed standards. The BCP The BCP process is similar to that for proposed standards. The BCP
is submitted to the IESG for review, (see section 6.1.1) and the is submitted to the IESG for review, (see section 6.1.1) and the
existing review process applies, including a Last-Call on the IETF existing review process applies, including a Last-Call on the IETF
Announce mailing list. However, once the IESG has approved the Announce mailing list. However, once the IESG has approved the
document, the process ends and the document is published. The document, the process ends and the document is published. The
resulting document is viewed as having the technical approval of the resulting document is viewed as having the technical approval of the
IETF, but it is not, and cannot become an official Internet Standard. IETF.
Specifically, a document to be considered for the status of BCP must Specifically, a document to be considered for the status of BCP must
undergo the procedures outlined in sections 6.1, and 6.5 of this undergo the procedures outlined in sections 6.1, and 6.4 of this
document. It is also under the restrictions of section 6.2 and the document. It is also under the restrictions of section 6.2 and the
process may be appealed according to the procedures in section 6.6. process may be appealed according to the procedures in section 6.5.
Because BCPs are meant to express community consensus but are arrived Because BCPs are meant to express community consensus but are arrived
at more quickly than standards, BCPs require particular care. at more quickly than standards, BCPs require particular care.
Specifically, BCPs should not be viewed simply as stronger Specifically, BCPs should not be viewed simply as stronger
Informational RFCs, but rather should be viewed as documents suitable Informational RFCs, but rather should be viewed as documents suitable
for a content unique from Informational RFCs. for a content different from Informational RFCs.
A specification that has been approved as a BCP is assigned a number A specification, or group of specifications, that has, or have been
in the BCP series while retaining its RFC number. approved as a BCP is assigned a number in the BCP series while
retaining its RFC number(s).
6. THE INTERNET STANDARDS PROCESS 6. THE INTERNET STANDARDS PROCESS
The mechanics of the Internet standards process involve decisions of The mechanics of the Internet standards process involve decisions of
the IESG concerning the elevation of a specification onto the the IESG concerning the elevation of a specification onto the
standards track or the movement of a standards-track specification standards track or the movement of a standards-track specification
from one maturity level to another. Although a number of reasonably from one maturity level to another. Although a number of reasonably
objective criteria (described below and in section 4) are available objective criteria (described below and in section 4) are available
to guide the IESG in making a decision to move a specification onto, to guide the IESG in making a decision to move a specification onto,
along, or off the standards track, there is no algorithmic guarantee along, or off the standards track, there is no algorithmic guarantee
skipping to change at page 17, line 12 skipping to change at page 17, line 28
determinations, particularly when the specification is considered by determinations, particularly when the specification is considered by
the IESG to be extremely important in terms of its potential impact the IESG to be extremely important in terms of its potential impact
on the Internet or on the suite of Internet protocols, the IESG may, on the Internet or on the suite of Internet protocols, the IESG may,
at its discretion, commission an independent technical review of the at its discretion, commission an independent technical review of the
specification. specification.
The IESG will send notice to the IETF of the pending IESG The IESG will send notice to the IETF of the pending IESG
consideration of the document(s) to permit a final review by the consideration of the document(s) to permit a final review by the
general Internet community. This "Last-Call" notification shall be general Internet community. This "Last-Call" notification shall be
via electronic mail to the IETF Announce mailing list. Comments on a via electronic mail to the IETF Announce mailing list. Comments on a
Last-Call shall be accepted from anyone, and should be sent to the Last-Call shall be accepted from anyone, and should be sent should be
email address specified in the Last-Call. sent as directed in the Last-Call announcement.
The Last-Call period shall be no shorter than two weeks except in The Last-Call period shall be no shorter than two weeks except in
those cases where the proposed standards action was not initiated by those cases where the proposed standards action was not initiated by
an IETF Working Group, in which case the Last-Call period shall be no an IETF Working Group, in which case the Last-Call period shall be no
shorter than four weeks. If the IESG believes that the community shorter than four weeks. If the IESG believes that the community
interest would be served by allowing more time for comment, it may interest would be served by allowing more time for comment, it may
decide on a longer Last-Call period or to explicitly lengthen a decide on a longer Last-Call period or to explicitly lengthen a
current Last-Call period. current Last-Call period.
The IETF may decide to recommend the formation of a new Working Group The IESG is not bound by the action recommended when the
in the case of significant controversy in response to a specification specification was submitted. For example, the IESG may decide to
consider the specification for publication in a different category
than that requested. If the IESG determines this before the Last-
Call is issued then the Last-Call should reflect the IESG's view.
The IESG could also decide to change the publication category based
on the response to a Last-Call. In addition, the IESG may decide to
recommend the formation of a new Working Group in the case of
significant controversy in response to a Last-Call for specification
not originating from an IETF Working Group. not originating from an IETF Working Group.
In a timely fashion after the expiration of the Last-Call period, the 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 IESG shall make its final determination of whether or not to approve
the standards action, and shall notify the IETF of its decision via the standards action, and shall notify the IETF of its decision via
electronic mail to the IETF Announce mailing list. electronic mail to the IETF Announce mailing list.
6.1.3 Publication 6.1.3 Publication
If a standards action is approved, notification is sent to the RFC If a standards action is approved, notification is sent to the RFC
skipping to change at page 19, line 40 skipping to change at page 20, line 15
reason that an existing standards track specification should be reason that an existing standards track specification should be
retired, the IESG shall approve a change of status of the old retired, the IESG shall approve a change of status of the old
specification(s) to Historic. This recommendation shall be issued specification(s) to Historic. This recommendation shall be issued
with the same Last-Call and notification procedures used for any with the same Last-Call and notification procedures used for any
other standards action. A request to retire an existing standard can other standards action. A request to retire an existing standard can
originate from a Working Group, an Area Director or some other originate from a Working Group, an Area Director or some other
interested party. interested party.
6.5 Conflict Resolution and Appeals 6.5 Conflict Resolution and Appeals
IETF Working Groups are generally able to reach consensus, which Disputes are possible at various stages during the IETF process. As
sometimes requires difficult compromises between or among different much as possible the process is designed so that compromises can be
technical proposals. However, there are times when even the most made, and genuine consensus achieved, however there are times when
reasonable and knowledgeable people are unable to agree. To achieve even the most reasonable and knowledgeable people are unable to
the goals of openness and fairness, such conflicts must be resolved agree. To achieve the goals of openness and fairness, such conflicts
by a process of open review and discussion. This section specifies must be resolved by a process of open review and discussion. This
the procedures that shall be followed to deal with Internet standards section specifies the procedures that shall be followed to deal with
issues that cannot be resolved through the normal processes whereby Internet standards issues that cannot be resolved through the normal
IETF Working Groups and other Internet standards process participants processes whereby IETF Working Groups and other Internet standards
ordinarily reach consensus. process participants ordinarily reach consensus.
6.5.1 Working Group disputes
An individual (whether a participant in the relevant Working Group or An individual (whether a participant in the relevant Working Group or
not) may disagree with a Working Group recommendation based on his or not) may disagree with a Working Group recommendation based on his or
her belief that either (a) his or her own views have not been her belief that either (a) his or her own views have not been
adequately considered by the Working Group, or (b) the Working Group adequately considered by the Working Group, or (b) the Working Group
has made an incorrect technical choice which places the quality has made an incorrect technical choice which places the quality
and/or integrity of the Working Group's product(s) in significant and/or integrity of the Working Group's product(s) in significant
jeopardy. The first issue is a difficulty with Working Group jeopardy. The first issue is a difficulty with Working Group
process; the latter is an assertion of technical error. These two process; the latter is an assertion of technical error. These two
types of disagreement are quite different, but both are handled by types of disagreement are quite different, but both are handled by
skipping to change at page 20, line 38 skipping to change at page 21, line 15
If the disagreement is not resolved to the satisfaction of the If the disagreement is not resolved to the satisfaction of the
parties at the IESG level, any of the parties involved may appeal the 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 decision to the IAB. The IAB shall then review the situation and
attempt to resolve it in a manner of its own choosing. attempt to resolve it in a manner of its own choosing.
The IAB decision is final with respect to the question of whether or The IAB decision is final with respect to the question of whether or
not the Internet standards procedures have been followed and with not the Internet standards procedures have been followed and with
respect to all questions of technical merit. 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.
In 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 Further recourse is available only in cases in which the procedures
themselves (i.e., the procedures described in this document) are themselves (i.e., the procedures described in this document) are
claimed to be inadequate or insufficient to the protection of the claimed to be inadequate or insufficient to the protection of the
rights of all parties in a fair and open Internet standards process. 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 Claims on this basis may be made to the Internet Society Board of
Trustees. The President of the Internet Society shall acknowledge Trustees. The President of the Internet Society shall acknowledge
such an appeal within two weeks, and shall at the time of such an appeal within two weeks, and shall at the time of
acknowledgment advise the petitioner of the expected duration of the acknowledgment advise the petitioner of the expected duration of the
Trustees' review of the appeal. The Trustees' decision upon Trustees' review of the appeal. The Trustees shall review the
completion of their review shall be final with respect to all aspects situation in a manner of its own choosing and report to the IETF on
of the dispute. 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 All appeals must include a detailed and specific description of the
facts of the dispute. facts of the dispute.
At all stages of the appeals process, the individuals or bodies At all stages of the appeals process, the individuals or bodies
responsible for making the decisions have the discretion to define responsible for making the decisions have the discretion to define
the specific procedures they will follow in the process of making the specific procedures they will follow in the process of making
their decision. their decision.
In all cases a decision concerning the disposition of the dispute, In all cases a decision concerning the disposition of the dispute,
skipping to change at page 21, line 34 skipping to change at page 23, line 4
Many standards groups other than the IETF create and publish Many standards groups other than the IETF create and publish
standards documents for network protocols and services. When these standards documents for network protocols and services. When these
external specifications play an important role in the Internet, it is external specifications play an important role in the Internet, it is
desirable to reach common agreements on their usage -- i.e., to desirable to reach common agreements on their usage -- i.e., to
establish Internet Standards relating to these external establish Internet Standards relating to these external
specifications. specifications.
There are two categories of external specifications: There are two categories of external specifications:
(1) Open Standards (1) Open Standards
Various national and international standards bodies, such as ANSI, Various national and international standards bodies, such as ANSI,
ISO, IEEE, and ITU-T, develop a variety of protocol and service ISO, IEEE, and ITU-T, develop a variety of protocol and service
specifications that are similar to Technical Specifications specifications that are similar to Technical Specifications
defined here. National and international groups also publish defined here. National and international groups also publish
"implementors' agreements" that are analogous to Applicability "implementors' agreements" that are analogous to Applicability
Statements, capturing a body of implementation-specific detail Statements, capturing a body of implementation-specific detail
concerned with the practical application of their standards. All concerned with the practical application of their standards. All
of these are considered to be "open external standards" for the of these are considered to be "open external standards" for the
purposes of the Internet standards process. purposes of the Internet standards process.
(2) Vendor Specifications (2) Other Specifications
A vendor-proprietary specification that has come to be widely used Other proprietary specifications that have come to be widely used
in the Internet may be treated by the Internet community as if it in the Internet may be treated by the Internet community as if
were a "standard". Such a specification is not generally they were a "standards". 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, vendors, or organization that produced
it.
7.1 Use of External Specifications 7.1 Use of External Specifications
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 specification that is Internet community will not standardize a specification that is
simply an "Internet version" of an existing external specification simply an "Internet version" of an existing external specification
unless an explicit cooperative arrangement to do so has been made. unless an explicit cooperative arrangement to do so has been made.
However, there are several ways in which an external specification However, there are several ways in which an external specification
that is important for the operation and/or evolution of the Internet that is important for the operation and/or evolution of the Internet
may be adopted for Internet use. may be adopted for Internet use.
7.1.1 Incorporation of an Open Standard 7.1.1 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. For example, many Internet Standards standard by reference. For example, many Internet Standards
incorporate by reference the ANSI standard character set "ASCII" incorporate by reference the ANSI standard character set "ASCII"
[2]. Whenever possible, the referenced specification shall be [2]. Whenever possible, the referenced specification shall be
available online. available online.
7.1.2 Incorporation of a Vendor Specification 7.1.2 Incorporation of Other Specifications
Vendor-proprietary specifications may be incorporated by reference Other proprietary specifications may be incorporated by reference
to a specific version of the vendor standard as long as the to a version of the specification as long as the proprietor meets
proprietor meets the requirements of section 8. If the vendor- the requirements of section 8. If the other proprietary
proprietary specification is not widely and readily available, the specification is not widely and readily available, the IESG may
IESG may request that it be published as an Informational RFC. request that it be published as an Informational RFC.
The IESG generally should not favor a particular vendor's The IESG generally should not favor a particular proprietary
proprietary specification over the technically equivalent and specification over the technically equivalent and competing
competing specification(s) of other vendors by making any specification(s) by making any incorporated vendor specification
incorporated vendor specification "required" or "recommended". "required" or "recommended".
7.1.3 Assumption 7.1.3 Assumption
An IETF Working Group may start from an external specification and An IETF Working Group may start from an external specification and
develop it into an Internet specification. This is acceptable if develop it into an Internet specification. This is acceptable if
(1) the specification is provided to the Working Group in (1) the specification is provided to the Working Group in
compliance with the requirements of section 9, and (2) change compliance with the requirements of section 9, and (2) change
control has been conveyed to IETF by the original developer of the control has been conveyed to IETF by the original developer of the
specification for the specification or for specifications derived specification for the specification or for specifications derived
from the original specification. from the original specification.
skipping to change at page 23, line 42 skipping to change at page 25, line 13
process activities is maintained by the IETF Secretariat, and is the process activities is maintained by the IETF Secretariat, and is the
responsibility of the IESG Secretary except that each IETF working responsibility of the IESG Secretary except that each IETF working
group is expected to maintain their own email list archive and must group is expected to maintain their own email list archive and must
make a best effort to ensure that all traffic is captured and make a best effort to ensure that all traffic is captured and
included in the archives. Internet drafts that have been removed included in the archives. Internet drafts that have been removed
(for any reason) from the Internet-Drafts directories shall be (for any reason) from the Internet-Drafts directories shall be
archived by the IETF Secretariat for the sole purpose of preserving archived by the IETF Secretariat for the sole purpose of preserving
an historical record of Internet standards activity and thus are not an historical record of Internet standards activity and thus are not
retrievable except in special circumstances. retrievable except in special circumstances.
9. INTELLECTUAL PROPERTY RIGHTS 9. VARYING THE PROCESS
9.1. General Policy 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 RFC Editor 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 In all matters of intellectual property rights and procedures, the
intention is to benefit the Internet community and the public at intention is to benefit the Internet community and the public at
large, while respecting the legitimate rights of others. large, while respecting the legitimate rights of others.
9.2 Confidentiality Obligations 10.2 Confidentiality Obligations
No contribution that is subject to any requirement of confidentiality No contribution that is subject to any requirement of confidentiality
or any restriction on its dissemination may be considered in any part or any restriction on its dissemination may be considered in any part
of the Internet standards process, and there must be no assumption of of the Internet standards process, and there must be no assumption of
any confidentiality obligation with respect to any such contribution. any confidentiality obligation with respect to any such contribution.
9.3. Rights and Permissions 10.3. Rights and Permissions
In the course of standards work, the IETF receives contributions in In the course of standards work, the IETF receives contributions in
various forms and from many persons. To best facilitate the various forms and from many persons. To best facilitate the
dissemination of these contributions, it is necessary to understand dissemination of these contributions, it is necessary to understand
any intellectual property rights (IPR) relating to the contributions. any intellectual property rights (IPR) relating to the contributions.
9.3.1. All Contributions 10.3.1. All Contributions
By submission of a contribution, each person actually submitting the By submission of a contribution, each person actually submitting the
contribution is deemed to agree to the following terms and conditions contribution is deemed to agree to the following terms and conditions
on his own behalf and/or on behalf of the organization he represents. on his own behalf and/or on behalf of the organization he represents.
Where a submission identifies contributors in addition to the Where a submission identifies contributors in addition to the
contributor(s) who provide the actual submission, the actual contributor(s) who provide the actual submission, the actual
submitter(s)represent that each other named contributor was made submitter(s)represent that each other named contributor was made
aware of and agreed to accept the same terms and conditions on his aware of and agreed to accept the same terms and conditions on his
own behalf and/or on behalf of any organization he may represent. own behalf and/or on behalf of any organization he may represent.
skipping to change at page 25, line 7 skipping to change at page 28, line 9
works properly acknowledge major contributors. works properly acknowledge major contributors.
By ratifying this description of the IETF process the Internet By ratifying this description of the IETF process the Internet
Society warrants that it will not inhibit the traditional open and Society warrants that it will not inhibit the traditional open and
free access to IETF documents for which license and right have free access to IETF documents for which license and right have
been assigned according to the procedures set forth in this been assigned according to the procedures set forth in this
section, including Internet-Drafts and RFCs. This warrant is section, including Internet-Drafts and RFCs. This warrant is
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. successors or assigns.
9.3.2. Standards Track Documents 10.3.2. Standards Track Documents
(A) Where any patents, patent applications, or other proprietary (A) Where any patents, patent applications, or other proprietary
rights are known, or claimed, with respect to any specification on rights are known, or claimed, with respect to any specification on
the standards track, and brought to the attention of the IESG, the the standards track, and brought to the attention of the IESG, the
IESG shall not advance the specification without including in the IESG shall not advance the specification without including in the
document a note indicating the existence of such rights, or document a note indicating the existence of such rights, or
claimed rights. Where implementations are required before claimed rights. Where implementations are required before
advancement of a specification, only implementations that have, by advancement of a specification, only implementations that have, by
statement of the implementers, taken adequate steps to comply with statement of the implementors, taken adequate steps to comply with
any such rights, or claimed rights, shall be considered for the any such rights, or claimed rights, shall be considered for the
purpose of showing the adequacy of the specification. purpose of showing the adequacy of the specification.
(B) The IESG disclaims any responsibility for identifying the (B) The IESG disclaims any responsibility for identifying the
existence of or for evaluating the applicability of any claimed existence of or for evaluating the applicability of any claimed
copyrights, patents, patent applications, or other rights in the copyrights, patents, patent applications, or other rights in the
fulfilling of the its obligations under (A), and will take no fulfilling of the its obligations under (A), and will take no
position on the validity or scope of any such rights. position on the validity or scope of any such rights.
(C) Where the IESG knows of rights, or claimed rights under (A), the (C) Where the IESG knows of rights, or claimed rights under (A), the
IESG Secretary shall attempt to obtain from the claimant of such IESG Secretary shall attempt to obtain from the claimant of such
rights, a written assurance that upon approval by the IESG of the rights, a written assurance that upon approval by the IESG of the
skipping to change at page 25, line 42 skipping to change at page 28, line 44
group proposing the use of the technology with respect to which group proposing the use of the technology with respect to which
the proprietary rights are claimed may assist the IESG Secretary the proprietary rights are claimed may assist the IESG Secretary
in this effort. The results of this procedure shall not affect in this effort. The results of this procedure shall not affect
advancement of a specification along the standards track, though advancement of a specification along the standards track, though
the IESG may defer approval where a delay may facilitate the the IESG may defer approval where a delay may facilitate the
obtaining of such assurances. The results will, however, be obtaining of such assurances. The results will, however, be
recorded by the IESG Secretary, and made available online. The recorded by the IESG Secretary, and made available online. The
IESG may also direct that a summary of the results be included in IESG may also direct that a summary of the results be included in
any RFC published containing the specification. any RFC published containing the specification.
9.3.3 Determination of Reasonable and Non-discriminatory Terms 10.3.3 Determination of Reasonable and Non-discriminatory Terms
The IESG will not make any explicit determination that the assurance The IESG will not make any explicit determination that the assurance
of reasonable and non-discriminatory terms for the use of a of reasonable and non-discriminatory terms for the use of a
technology has been fulfilled in practice. It will instead use the technology has been fulfilled in practice. It will instead use the
normal requirements for the advancement of Internet Standards to normal requirements for the advancement of Internet Standards to
verify that the terms for use are reasonable. If the two unrelated verify that the terms for use are reasonable. If the two unrelated
implementations of the standard that are required to advance from implementations of the standard that are required to advance from
Proposed to Draft have been produced by different organizations or Proposed to Draft have been produced by different organizations or
individuals or if the "significant implementation and successful individuals or if the "significant implementation and successful
operational experience" required to advance from Draft to full operational experience" required to advance from Draft to full
Standard has been achieved the assumption is that the terms must be Standard has been achieved the assumption is that the terms must be
reasonable and to some degree, non-discriminatory. This assumption reasonable and to some degree, non-discriminatory. This assumption
may be challenged during the Last-Call period. may be challenged during the Last-Call period.
9.4. Notices 10.4. Notices
(A) Standards track documents shall include the following notice: (A) Standards track documents shall include the following notice:
"The IETF takes no position on the validity or scope of any "The IETF takes no position on the validity or scope of any
claimed rights to the implementation or use of the technology claimed rights to the implementation or use of the technology
described in this document, nor that it has made any effort to described in this document, nor that it has made any effort to
identify any such intellectual property rights. Information on identify any such intellectual property rights. Information on
the IETF's procedures with respect to rights in standards and the IETF's procedures with respect to rights in standards and
standards-related documentation can be found in BCP-xxx, dated standards-related documentation can be found in BCP-xxx, dated
in the future. Copies of claims of rights made available for in the future. Copies of claims of rights made available for
skipping to change at page 27, line 24 skipping to change at page 30, line 26
(D) Where the IESG is aware of proprietary rights claimed with (D) Where the IESG is aware of proprietary rights claimed with
respect to a standards track document, or the technology described respect to a standards track document, or the technology described
or referenced therein, such document shall contain the following or referenced therein, such document shall contain the following
notice: notice:
"The IETF has been notified of intellectual property rights "The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained claimed in regard to some or all of the specification contained
in this document. For more information consult the online list in this document. For more information consult the online list
of claimed rights." of claimed rights."
10. ACKNOWLEDGMENTS 11. ACKNOWLEDGMENTS
There have been a number of people involved with the development of There have been a number of people involved with the development of
the documents defining the IETF standards process over the years. the documents defining the IETF standards process over the years.
The process was first described in RFC 1310 then revised in RFC 1602 The process was first described in RFC 1310 then revised in RFC 1602
before the current effort (which relies heavily on its predecessors). before the current effort (which relies heavily on its predecessors).
Specific acknowledgments must be extended to Lyman Chapin, Phill Specific acknowledgments must be extended to Lyman Chapin, Phill
Gross and Christian Huitema as the editors of the previous versions, Gross and Christian Huitema as the editors of the previous versions,
to Jon Postel and Dave Crocker for their inputs to those versions, to Jon Postel and Dave Crocker for their inputs to those versions, to
and to Andy Ireland, Geoff Stewart, Jim Lampert and Dick Holleman for Andy Ireland, Geoff Stewart, Jim Lampert and Dick Holleman for their
their reviews of the legal aspects of the procedures described reviews of the legal aspects of the procedures described herein, and
herein. to John Stewart and Robert Elz for extensive input on the final
version.
In addition much of the credit for the refinement of the details of In addition much of the credit for the refinement of the details of
the IETF processes belongs to the many members of the various the IETF processes belongs to the many members of the various
incarnations of the POISED working group. incarnations of the POISED working group.
11. SECURITY CONSIDERATIONS 12. SECURITY CONSIDERATIONS
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
12. REFERENCES 13. REFERENCES
[1] Postel, J., "Internet Official Protocol Standards", STD 1, [1] Postel, J., "Internet Official Protocol Standards", STD 1,
USC/Information Sciences Institute, November 1995. USC/Information Sciences Institute, November 1995.
[2] ANSI, Coded Character Set -- 7-Bit American Standard Code for [2] ANSI, Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994. USC/Information Sciences Institute, October 1994.
[4] Postel, J., "Introduction to the STD Notes", RFC 1311, [4] Postel, J., "Introduction to the STD Notes", RFC 1311,
USC/Information Sciences Institute, March 1992. USC/Information Sciences Institute, March 1992.
[5] Postel, J., "Instructions to RFC Authors", RFC 1543, [5] Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993. USC/Information Sciences Institute, October 1993.
[6] Postel, J., T. Li, and Y. Rekhter "Best Current Practices, RFC [6] Postel, J., T. Li, and Y. Rekhter "Best Current Practices, RFC
1818, USC/Information Sciences Institute, Cisco Systems, August 1818, USC/Information Sciences Institute, Cisco Systems, August
1995. 1995.
13 AUTHORS' ADDRESS [7] Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
Standards", RFC 1726, April 1995
Scott O. Bradner
Harvard University
Holyoke Center, Room 813
1350 Mass. Ave.
Cambridge, MA 02138
USA +1 617 495 3864
sob@harvard.edu
APPENDIX A: DEFINITIONS 14. DEFINITIONS OF TERMS
IETF Area - A management division within the IETF. An Area consists IETF Area - A management division within the IETF. An Area consists
of Working Groups related to a general topic such as routing. An of Working Groups related to a general topic such as routing. An
Area is managed by one or two Area Directors. Area is managed by one or two Area Directors.
Area Director - The manager of an IETF Area. The Area Directors Area Director - The manager of an IETF Area. The Area Directors
along with the IETF Chair comprise the Internet Engineering along with the IETF Chair comprise the Internet Engineering
Steering Group (IESG). Steering Group (IESG).
File Transfer Protocol (FTP) - An Internet application used to File Transfer Protocol (FTP) - An Internet application used to
transfer files in a TCP/IP network. transfer files in a TCP/IP network.
gopher - An Internet application used to interactively select and gopher - An Internet application used to interactively select and
retrieve files in a TCP/IP network. retrieve files in a TCP/IP network.
Internet Architecture Board (IAB) - An appointed group that assists Internet Architecture Board (IAB) - An appointed group that assists
in the management of the IETF standards process. in the management of the IETF standards process.
Internet Engineering Steering Group (IESG) - A group comprised of the Internet Engineering Steering Group (IESG) - A group comprised of the
IETF Area Directors and the IETF Chair. The IESG is responsible IETF Area Directors and the IETF Chair. The IESG is responsible
for the management, along with the IAB, of the IETF and is the for the management, along with the IAB, of the IETF and is the
standards approval board for the IETF. 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 Last-Call - A public comment period used to gage the level of
consensus about the reasonableness of a proposed standards action. consensus about the reasonableness of a proposed standards action.
(see section 6.1.2) (see section 6.1.2)
online - Relating to information made available over the Internet. online - Relating to information made available over the Internet.
When referenced in this document material is said to be online When referenced in this document material is said to be online
when it is retrievable without restriction or undue fee using when it is retrievable without restriction or undue fee using
standard Internet applications such as anonymous FTP, gopher or standard Internet applications such as anonymous FTP, gopher or
the WWW. the WWW.
Working Group - A group chartered by the IESG and IAB to work on a Working Group - A group chartered by the IESG and IAB to work on a
specific specification, set of specifications or topic. specific specification, set of specifications or topic.
APPENDIX B: GLOSSARY OF ACRONYMS 15. AUTHORS' ADDRESS
Scott O. Bradner
Harvard University
Holyoke Center, Room 813
1350 Mass. Ave.
Cambridge, MA 02138
USA +1 617 495 3864
sob@harvard.edu
APPENDIX A: GLOSSARY OF ACRONYMS
ANSI: American National Standards Institute ANSI: American National Standards Institute
ARPA: (U.S.) Advanced Research Projects Agency ARPA: (U.S.) Advanced Research Projects Agency
AS: Applicability Statement AS: Applicability Statement
FTP: File Transfer Protocol FTP: File Transfer Protocol
ASCII: American Standard Code for Information Interchange ASCII: American Standard Code for Information Interchange
ITU-T: Telecommunications Standardization sector of the ITU-T: Telecommunications Standardization sector of the
International Telecommunications Union (ITU), a UN International Telecommunications Union (ITU), a UN
treaty organization; ITU-T was formerly called CCITT. treaty organization; ITU-T was formerly called CCITT.
IAB: Internet Architecture Board IAB: Internet Architecture Board
 End of changes. 51 change blocks. 
127 lines changed or deleted 275 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/