rfc1602.txt

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

      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
      disseminat