rfc2026.txt

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

   Disputes are possible at various stages during the IETF process. As
   much as possible the process is designed so that compromises can be
   made, and genuine consensus achieved, however there are times when
   even the most reasonable and knowledgeable people are unable to
   agree. To achieve the goals of openness and fairness, such conflicts
   must be resolved by a process of open review and discussion. This
   section specifies the procedures that shall be followed to deal with
   Internet standards issues that cannot be resolved through the normal
   processes whereby IETF Working Groups and other Internet Standards
   Process participants ordinarily reach consensus.

6.5.1 Working Group Disputes

   An individual (whether a participant in the relevant Working Group or
   not) may disagree with a Working Group recommendation based on his or
   her belief that either (a) his or her own views have not been
   adequately considered by the Working Group, or (b) the Working Group
   has made an incorrect technical choice which places the quality
   and/or integrity of the Working Group's product(s) in significant
   jeopardy.  The first issue is a difficulty with Working Group
   process;  the latter is an assertion of technical error.  These two
   types of disagreement are quite different, but both are handled by
   the same process of review.

   A person who disagrees with a Working Group recommendation shall
   always first discuss the matter with the Working Group's chair(s),
   who may involve other members of the Working Group (or the Working
   Group as a whole) in the discussion.

   If the disagreement cannot be resolved in this way, any of the
   parties involved may bring it to the attention of the Area
   Director(s) for the area in which the Working Group is chartered.
   The Area Director(s) shall attempt to resolve the dispute.

   If the disagreement cannot be resolved by the Area Director(s) any of
   the parties involved may then appeal to the IESG as a whole.  The
   IESG shall then review the situation and attempt to resolve it in a
   manner of its own choosing.

   If the disagreement is not resolved to the satisfaction of the
   parties at the IESG level, any of the parties involved may appeal the
   decision to the IAB.  The IAB shall then review the situation and
   attempt to resolve it in a manner of its own choosing.






Bradner                  Best Current Practice                 [Page 22]

RFC 2026               Internet Standards Process           October 1996


   The IAB decision is final with respect to the question of whether or
   not the Internet standards procedures have been followed and with
   respect to all questions of technical merit.

6.5.2 Process Failures

   This document sets forward procedures required to be followed to
   ensure openness and fairness of the Internet Standards Process, and
   the technical viability of the standards created. The IESG is the
   principal agent of the IETF for this purpose, and it is the IESG that
   is charged with ensuring that the required procedures have been
   followed, and that any necessary prerequisites to a standards action
   have been met.

   If an individual should disagree with an action taken by the IESG in
   this process, that person should first discuss the issue with the
   ISEG Chair. If the IESG Chair is unable to satisfy the complainant
   then the IESG as a whole should re-examine the action taken, along
   with input from the complainant, and determine whether any further
   action is needed.  The IESG shall issue a report on its review of the
   complaint to the IETF.

   Should the complainant not be satisfied with the outcome of the IESG
   review, an appeal may be lodged to the IAB. The IAB shall then review
   the situation and attempt to resolve it in a manner of its own
   choosing and report to the IETF on the outcome of its review.

   If circumstances warrant, the IAB may direct that an IESG decision be
   annulled, and the situation shall then be as it was before the IESG
   decision was taken. The IAB may also recommend an action to the IESG,
   or make such other recommendations as it deems fit. The IAB may not,
   however, pre-empt the role of the IESG by issuing a decision which
   only the IESG is empowered to make.

   The IAB decision is final with respect to the question of whether or
   not the Internet standards procedures have been followed.

6.5.3 Questions of Applicable Procedure

   Further recourse is available only in cases in which the procedures
   themselves (i.e., the procedures described in this document) are
   claimed to be inadequate or insufficient to the protection of the
   rights of all parties in a fair and open Internet Standards Process.
   Claims on this basis may be made to the Internet Society Board of
   Trustees.  The President of the Internet Society shall acknowledge
   such an appeal within two weeks, and shall at the time of
   acknowledgment advise the petitioner of the expected duration of the
   Trustees' review of the appeal.  The Trustees shall review the



Bradner                  Best Current Practice                 [Page 23]

RFC 2026               Internet Standards Process           October 1996


   situation in a manner of its own choosing and report to the IETF on
   the outcome of its review.

   The Trustees' decision upon completion of their review shall be final
   with respect to all aspects of the dispute.

6.5.4 Appeals Procedure

   All appeals must include a detailed and specific description of the
   facts of the dispute.

   All appeals must be initiated within two months of the public
   knowledge of the action or decision to be challenged.

   At all stages of the appeals process, the individuals or bodies
   responsible for making the decisions have the discretion to define
   the specific procedures they will follow in the process of making
   their decision.

   In all cases a decision concerning the disposition of the dispute,
   and the communication of that decision to the parties involved, must
   be accomplished within a reasonable period of time.

   [NOTE:  These procedures intentionally and explicitly do not
   establish a fixed maximum time period that shall be considered
   "reasonable" in all cases.  The Internet Standards Process places a
   premium on consensus and efforts to achieve it, and deliberately
   foregoes deterministically swift execution of procedures in favor of
   a latitude within which more genuine technical agreements may be
   reached.]

7.  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

      Various national and international standards bodies, such as ANSI,
      ISO, IEEE, and ITU-T, develop a variety of protocol and service
      specifications that are similar to Technical Specifications
      defined here.  National and international groups also publish



Bradner                  Best Current Practice                 [Page 24]

RFC 2026               Internet Standards Process           October 1996


      "implementors' agreements" that are analogous to Applicability
      Statements, capturing a body of implementation-specific detail
      concerned with the practical application of their standards.  All
      of these are considered to be "open external standards" for the
      purposes of the Internet Standards Process.

   (2)  Other Specifications

      Other proprietary specifications that have come to be widely used
      in the Internet may be treated by the Internet community as if
      they were a "standards".  Such a specification is not generally
      developed in an open fashion, is typically proprietary, and is
      controlled by the vendor, vendors, or organization that produced
      it.

7.1  Use of External Specifications

   To avoid conflict between competing versions of a specification, the
   Internet community will not standardize a specification 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.

7.1.1  Incorporation of an Open Standard

   An Internet Standard TS or AS may incorporate an open external
   standard by reference.  For example, many Internet Standards
   incorporate by reference the ANSI standard character set "ASCII" [2].
   Whenever possible, the referenced specification shall be available
   online.

7.1.2  Incorporation of Other Specifications

   Other proprietary specifications may be incorporated by reference to
   a version of the specification as long as the proprietor meets the
   requirements of section 10.  If the other proprietary specification
   is not widely and readily available, the IESG may request that it be
   published as an Informational RFC.

   The IESG generally should not favor a particular proprietary
   specification over technically equivalent and competing
   specification(s) by making any incorporated vendor specification
   "required" or "recommended".






Bradner                  Best Current Practice                 [Page 25]

RFC 2026               Internet Standards Process           October 1996


7.1.3  Assumption

   An IETF Working Group may start from an external specification and
   develop it into an Internet specification.  This is acceptable if (1)
   the specification is provided to the Working Group in compliance with
   the requirements of section 10, and (2) change control has been
   conveyed to IETF by the original developer of the specification for
   the specification or for specifications derived from the original
   specification.

8.  NOTICES AND RECORD KEEPING

   Each of the organizations involved in the development and approval of
   Internet Standards shall publicly announce, and shall maintain a
   publicly accessible record of, every activity in which it engages, to
   the extent that the activity represents the prosecution of any part
   of the Internet Standards Process.  For purposes of this section, the
   organizations involved in the development and approval of Internet
   Standards includes the IETF, the IESG, the IAB, all IETF Working
   Groups, and the Internet Society Board of Trustees.

   For IETF and Working Group meetings announcements shall be made by
   electronic mail to the IETF Announce mailing list and shall be made
   sufficiently far in advance of the activity to permit all interested
   parties to effectively participate.  The announcement shall contain
   (or provide pointers to) all of the information that is necessary to
   support the participation of any interested individual.  In the case
   of a meeting, for example, the announcement shall include an agenda
   that specifies the standards- related issues that will be discussed.

   The formal record of an organization's standards-related activity
   shall include at least the following:

   o  the charter of the organization (or a defining document equivalent
      to a charter);
   o  complete and accurate minutes of meetings;
   o  the archives of Working Group electronic mail mailing lists;  and
   o  all written contributions from participants that pertain to the
      organization's standards-related activity.

   As a practical matter, the formal record of all Internet Standards
   Process activities is maintained by the IETF Secretariat, and is the
   responsibility of the IETF Secretariat except that each IETF Working
   Group is expected to maintain their own email list archive and must
   make a best effort to ensure that all traffic is captured and
   included in the archives.  Also, the Working Group chair is
   responsible for providing the IETF Secretariat with complete and
   accurate minutes of all Working Group meetings.  Internet-Drafts that



Bradner                  Best Current Practice                 [Page 26]

RFC 2026               Internet Standards Process           October 1996


   have been removed (for any reason) from the Internet-Drafts
   directories shall be archived by the IETF Secretariat for the sole
   purpose of preserving an historical record of Internet standards
   activity and thus are not retrievable except in special
   circumstances.

9.  VARYING THE PROCESS

   This document, which sets out the rules and procedures by which
   Internet Standards and related documents are made is itself a product
   of the Internet Standards Process (as a BCP, as described in section
   5). It replaces a previous version, and in time, is likely itself to
   be replaced.

   While, when published, this document represents the community's view
   of the proper and correct process to follow, and requirements to be
   met, to allow for the best possible Internet Standards and BCPs, it
   cannot be assumed that this will always remain th