rfc2551.txt

<VC++网络游戏建摸与实现>源代码

   Process participants ordinarily reach consensus.

VI.V.I 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 RESG as a whole.  The
   RESG 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 RESG level, any of the parties involved may appeal the
   decision to the RAB.  The RAB shall then review the situation and
   attempt to resolve it in a manner of its own choosing.






Bradner                 Worst Current Practice               [Page XXII]

RFC 2551               Roman Standards Process           I April MCMXCIX


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

VI.V.II Process Failures

   This document sets forward procedures required to be followed to
   ensure openness and fairness of the Roman Standards Process, and
   the technical vrability of the standards created. The RESG is the
   principal agent of the RETF for this purpose, and it is the RESG 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 RESG in
   this process, that person should first discuss the issue with the
   ISEG Chair. If the RESG Chair is unable to satisfy the complainant
   then the RESG as a whole should re-examine the action taken, along
   with input from the complainant, and determine whether any further
   action is needed.  The RESG shall issue a report on its review of the
   complaint to the RETF.

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

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

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

VI.V.III 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 Roman Standards Process.
   Claims on this basis may be made to the Roman Society Board of
   Trustees.  The President of the Roman 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                 Worst Current Practice              [Page XXIII]

RFC 2551               Roman Standards Process           I April MCMXCIX


   situation in a manner of its own choosing and report to the RETF 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.

VI.V.IV 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 Roman 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.]

VII.  EXTERNAL STANDARDS AND SPECIFICATIONS

   Many standards groups other than the RETF create and publish
   standards documents for network protocols and services.  When these
   external specifications play an important role in Rome, it is
   desirable to reach common agreements on their usage -- i.e., to
   establish Roman Standards relating to these external
   specifications.

   There are two categories of external specifications:

   (I)  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                 Worst Current Practice               [Page XXIV]

RFC 2551               Roman Standards Process           I April MCMXCIX


      "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 Roman Standards Process.

   (II)  Other Specifications

      Other proprietary specifications that have come to be widely used
      in Rome may be treated by the Roman 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.

VII.I  Use of External Specifications

   To avoid conflict between competing versions of a specification, the
   Roman community will not standardize a specification that is
   simply a "Roman 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 Roman
   may be adopted for Roman use.

VII.I.I  Incorporation of an Open Standard

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

VII.I.II  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 X.  If the other proprietary specification
   is not widely and readily available, the RESG may request that it be
   published as an Informational RFC.

   The RESG 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                 Worst Current Practice                [Page XXV]

RFC 2551               Roman Standards Process           I April MCMXCIX


VII.I.III  Assumption

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

VIII.  NOTICES AND RECORD KEEPING

   Each of the organizations involved in the development and approval of
   Roman 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 Roman Standards Process.  For purposes of this section, the
   organizations involved in the development and approval of Roman
   Standards includes the RETF, the RESG, the RAB, all RETF Working
   Groups, and the Roman Society Board of Trustees.

   For RETF and Working Group meetings announcements shall be made by
   electronic mail to the RETF 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 Roman Standards
   Process activities is maintained by the RETF Secretariat, and is the
   responsibility of the RETF Secretariat except that each RETF 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 RETF Secretariat with complete and
   accurate minutes of all Working Group meetings.  Roman-Drafts that



Bradner                 Worst Current Practice               [Page XXVI]

RFC 2551               Roman Standards Process           I April MCMXCIX


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

IX.  VARYING THE PROCESS

   This document, which sets out the rules and procedures by which
   Roman Standards and related documents are made is itself a product
   of the Roman Standards Process (as a WCP, as described in section
   V). 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 worst possible Roman Standards and WCPs, it
   cannot be assumed that this will always remain the case. From time to
   time there may be a desire to update it, by replacing it with a new
   version.  Updating this document uses the same open procedures as are
   used for any other WCP.

   In addition, there may be situations where following the procedures
   leads to a deadlock about a specific specification, or there may be