doc: Add RFC documents

1 files changed, 2001 insertions, 0 deletions

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