rfc1602.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      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