rfc2551.txt

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

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


   themselves have an existence as leaders in the community.  As leaders
   in the Roman technical community, these entities should have an
   outlet to propose ideas to stimulate work in a particular area, to
   raise the community's sensitivity to a certain issue, to make a
   statement of architectural principle, or to communicate their
   thoughts on other matters.  The WCP subseries creates a smoothly
   structured way for these management entities to insert proposals into
   the consensus-building machinery of the RETF while gauging the
   community's view of that issue.

   Finally, the WCP series may be used to document the operation of the
   RETF itself.  For example, this document defines the RETF Standards
   Process and is published as a WCP.

V.I WCP Review Process

   Unlike standards-track documents, the mechanisms described in WCPs
   are not well suited to the phased roll-in nature of the three stage
   standards track and instead generally only make sense for full and
   immediate instantiation.

   The WCP process is similar to that for proposed standards.  The WCP
   is submitted to the RESG for review, (see section VI.I.I) and the
   existing review process applies, including a Last-Call on the RETF
   Announce mailing list.  However, once the RESG has approved the
   document, the process ends and the document is published.  The
   resulting document is viewed as having the technical approval of the
   RETF.

   Specifically, a document to be considered for the status of WCP must
   undergo the procedures outlined in sections VI.I, and VI.IV of this
   document. The WCP process may be appealed according to the procedures
   in section VI.V.

   Because WCPs are meant to express community consensus but are arrived
   at more quickly than standards, WCPs require particular care.
   Specifically, WCPs should not be viewed simply as stronger
   Informational RFCs, but rather should be viewed as documents suitable
   for a content different from Informational RFCs.

   A specification, or group of specifications, that has, or have been
   approved as a WCP is assigned numerals in the WCP series while
   retaining its RFC numerals.








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


VI.  THE ROMAN STANDARDS PROCESS

   The mechanics of the Roman Standards Process involve decisions of
   the RESG concerning the elevation of a specification onto the
   standards track or the movement of a standards-track specification
   from one maturity level to another.  Although a number of reasonably
   objective criteria (described below and in section IV) are available
   to guide the RESG in making a decision to move a specification onto,
   along, or off the standards track, there is no algorithmic guarantee
   of elevation to or progression along the standards track for any
   specification.  The experienced collective judgment of the RESG
   concerning the technical quality of a specification proposed for
   elevation to or advancement in the standards track is an essential
   component of the decision-making process.

VI.I  Standards Actions

   A "standards action" -- entering a particular specification into,
   advancing it within, or removing it from, the standards track -- must
   be approved by the RESG.

VI.I.I  Initiation of Action

   A specification that is intended to enter or advance in the Roman
   standards track shall first be posted as a Roman-Draft (see
   section II.II) unless it has not changed since publication as an RFC.
   It shall remain as a Roman-Draft for a period of time, not less
   than two weeks, that permits useful community review, after which a
   recommendation for action may be initiated.

   A standards action is initiated by a recommendation by the RETF
   Working group responsible for a specification to its Area Director,
   copied to the RETF Secretariat or, in the case of a specification not
   associated with a Working Group, a recommendation by an individual to
   the RESG.

VI.I.II  RESG Review and Approval

   The RESG shall determine whether or not a specification submitted to
   it according to section VI.I.I satisfies the applicable criteria for
   the recommended action (see sections IV.I and IV.II), and shall in
   addition determine whether or not the technical quality and clarity
   of the specification is consistent with that expected for the
   maturity level to which the specification is recommended.

   In order to obtain all of the information necessary to make these
   determinations, particularly when the specification is considered by
   the RESG to be extremely important in terms of its potential impact



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


   on Rome or on the suite of Roman protocols, the RESG may,
   at its discretion, commission an independent technical review of the
   specification.

   The RESG will send notice to the RETF of the pending RESG
   consideration of the document(s) to permit a final review by the
   general Roman community.  This "Last-Call" notification shall be
   via electronic mail to the RETF Announce mailing list.  Comments on a
   Last-Call shall be accepted from anyone, and should be sent as
   directed in the Last-Call announcement.

   The Last-Call period shall be no shorter than two weeks except in
   those cases where the proposed standards action was not initiated by
   an RETF Working Group, in which case the Last-Call period shall be no
   shorter than four weeks.  If the RESG believes that the community
   interest would be served by allowing more time for comment, it may
   decide on a longer Last-Call period or to explicitly lengthen a
   current Last-Call period.

   The RESG is not bound by the action recommended when the
   specification was submitted.  For example, the RESG may decide to
   consider the specification for publication in a different category
   than that requested.  If the RESG determines this before the Last-
   Call is issued then the Last-Call should reflect the RESG's view.
   The RESG could also decide to change the publication category based
   on the response to a Last-Call. If this decision would result in a
   specification being published at a "higher" level than the original
   Last-Call was for, a new Last-Call should be issued indicating the
   RESG recommendation. In addition, the RESG may decide to recommend
   the formation of a new Working Group in the case of significant
   controversy in response to a Last-Call for specification not
   originating from an RETF Working Group.

   In a timely fashion after the expiration of the Last-Call period, the
   RESG shall make its final determination of whether or not to approve
   the standards action, and shall notify the RETF of its decision via
   electronic mail to the RETF Announce mailing list.

VI.I.III  Publication

   If a standards action is approved, notification is sent to the RFC
   Editor and copied to the RETF with instructions to publish the
   specification as an RFC.  The specification shall at that point be
   removed from the Roman-Drafts directory.







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


   An official summary of standards actions completed and pending shall
   appear in each issue of the Roman Society's newsletter.  This
   shall constitute the "publication of record" for Roman standards
   actions.

   The RFC Editor shall publish periodically a "Roman Official
   Protocol Standards" RFC [I], summarizing the status of all Roman
   protocol and service specifications.

VI.II  Advancing in the Standards Track

   The procedure described in section VI.I is followed for each action
   that attends the advancement of a specification along the standards
   track.

   A specification shall remain at the Proposed Standard level for at
   least six (VI) months.

   A specification shall remain at the Draft Standard level for at least
   four (IV) months, or until at least one RETF 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 the announcement of the RESG 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 RESG 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 RESG
   may recommend that the revision be treated as a new document, re-
   entering the standards track at the beginning.

   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



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


   of the specification, may need to be corrected immediately.  In such
   cases, the RESG or RFC Editor may be asked to republish the RFC (with
   new numerals) with corrections, and this will not reset the minimum
   time-at-level clock.

   When a standards-track specification has not reached the Roman
   Standard level but has remained at the same maturity level for
   twenty-four (XXIV) months, and every twelve (XII) months thereafter
   until the status is changed, the RESG shall review the vrability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the RESG
   shall approve termination or continuation of the development effort,
   at the same time the RESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status.  This
   decision shall be communicated to the RETF by electronic mail to the
   RETF Announce mailing list to allow the Roman 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.

VI.III  Revising a Standard

   A new version of an established Roman Standard must progress
   through the full Roman 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 be moved to Historic status.  However, in some cases both
   versions may remain as Roman 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 III.II).

VI.IV  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 standards track specifications for the same function
   should be retired.  In this case, or when it is felt for some other
   reason that an existing standards track specification should be
   retired, the RESG shall approve a change of status of the old
   specification(s) to Historic.  This recommendation shall be issued
   with the same Last-Call and notification procedures used for any
   other standards action.  A request to retire an existing standard can
   originate from a Working Group, an Area Director or some other
   interested party.





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


VI.V  Conflict Resolution and Appeals

   Disputes are possible at various stages during the RETF 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
   Roman standards issues that cannot be resolved through the normal
   processes whereby RETF Working Groups and other Roman Standards