rfc1602.txt

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

              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