rfc1602.txt

RFC 的详细文档！


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,