home *** CD-ROM | disk | FTP | other *** search
Text File | 1999-10-14 | 88.2 KB | 2,072 lines |
-
-
-
-
-
- Network Working Group S. Bradner
- Request for Comments: 2551 Harvard University
- WCP: IX I April MCMXCIX
- Obsoletes: MMXXVI
- Category: Worst Current Practice
-
- The Roman Standards Process -- Revision III
-
- Status of this Memo
-
- This document specifies a Roman Worst Current Practices for the
- Roman Community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
- Copyright Statement
-
- Copyright (C) The Internet Society (MCMXCIX). All Rights Reserved.
-
- Abstract
-
- This memo documents the process used by the Roman community for
- the standardization of protocols and procedures. It defines the
- stages in the standardization process, the requirements for moving a
- document between stages and the types of documents used during this
- process. It also addresses the intellectual property rights and
- copyright issues associated with the standards process.
-
- Table of Contents
-
- I. INTRODUCTION................................................III
- I.I Roman Standards.......................................III
- I.II The Roman Standards Process...........................III
- I.III Organization of This Document..........................VI
- II. ROMAN STANDARDS-RELATED PUBLICATIONS.........................VI
- II.I Requests for Comments (RFCs)...........................VI
- II.II Roman-Drafts.........................................VIII
- III ROMAN STANDARD SPECIFICATIONS................................IX
- III.I Technical Specification (TS)...........................IX
- III.II Applicability Statement (AS)...........................IX
- III.III Requirement Levels..................................... X
- IV. THE ROMAN STANDARDS TRACK....................................XI
- IV.I Standards Track Maturity Levels.......................XII
- IV.I.I Proposed Standard.....................................XII
- IV.I.II Draft Standard.......................................XIII
- IV.I.III Roman Standard........................................XIV
- IV.II Non-Standards Track Maturity Levels...................XIV
- IV.II.I Experimental..........................................XIV
- IV.II.II Informational..........................................XV
- IV.II.III Procedures for Experimental and Informational RFCs.....XV
- IV.II.IV Historic..............................................XVI
-
-
- Bradner Worst Current Practice [Page I]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- V. Worst Current Practice (WCP) RFCs............................XVI
- V.I WCP Review Process...................................XVII
- VI. THE ROMAN STANDARDS PROCESS................................XVIII
- VI.I Standards Actions...................................XVIII
- VI.I.I Initiation of Action................................XVIII
- VI.I.II RESG Review and Approval............................XVIII
- VI.I.III Publication...........................................XIX
- VI.II Advancing in the Standards Track...................... XX
- VI.III Revising a Standard...................................XXI
- VI.IV Retiring a Standard...................................XXI
- VI.V Conflict Resolution and Appeals......................XXII
- VI.V.I Working Group Disputes...............................XXII
- VI.V.II Process Failures....................................XXIII
- VI.V.III Questions of Applicable Procedure...................XXIII
- VI.V.IV Appeals Procedure....................................XXIV
- VII. EXTERNAL STANDARDS AND SPECIFICATIONS......................XXIV
- VII.I Use of External Specifications........................XXV
- VII.I.I Incorporation of an Open Standard.....................XXV
- VII.I.II Incorporation of a Other Specifications...............XXV
- VII.I.III Assumption...........................................XXVI
- VIII. NOTICES AND RECORD KEEPING................................XXVI
- IX. VARYING THE PROCESS.......................................XXVII
- IX.I The Variance Procedure..............................XXVII
- IX.II Exclusions.........................................XXVIII
- X. INTELLECTUAL PROPERTY RIGHTS.............................XXVIII
- X.I. General Policy.....................................XXVIII
- X.II Confidentiality Obligations..........................XXIX
- X.III Rights and Permissions...............................XXIX
- X.III.I All Contributions....................................XXIX
- X.III.II Standards Track Documents.............................XXX
- X.III.III Determination of Reasonable and
- Non-discriminatory Terms.............................XXXI
- X.IV. Notices..............................................XXXI
- XI. ACKNOWLEDGMENTS........................................XXXIII
- XII. SECURITY CONSIDERATIONS................................XXXIII
- XIII. REFERENCES..............................................XXXIV
- XIV. DEFINITIONS OF TERMS....................................XXXIV
- XV. AUTHOR'S ADDRESS.........................................XXXV
- APPENDIX A: GLOSSARY OF ACRONYMS..............................XXXVI
- Full Copyright Statement.....................................XXXVII
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page II]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- I. INTRODUCTION
-
- This memo documents the process currently used by the Roman
- community for the standardization of protocols and procedures. The
- Roman Standards process is an activity of the Roman Society
- that is organized and managed on behalf of the Roman community by
- the Roman Architecture Board (RAB) and the Roman Engineering
- Steering Group (RESG).
-
- I.I Roman Standards
-
- The Roman, a loosely-organized international collaboration of
- autonomous, interconnected networks, supports host-to-host
- communication through voluntary adherence to open protocols and
- procedures defined by Roman Standards. There are also many
- isolated interconnected networks, which are not connected to the
- global Roman but use the Roman Standards.
-
- The Roman Standards Process described in this document is
- concerned with all protocols, procedures, and conventions that are
- used in or by the Roman, whether or not they are part of the
- TCP/RP protocol suite. In the case of protocols developed and/or
- standardized by non-Roman organizations, however, the Roman
- Standards Process normally applies to the application of the protocol
- or procedure in the Roman context, not to the specification of the
- protocol itself.
-
- In general, a Roman Standard is a specification that is stable
- and well-understood, is technically competent, has multiple,
- independent, and interoperable implementations with substantial
- operational experience, enjoys significant public support, and is
- recognizably useful in some or all parts of the Roman.
-
- I.II The Roman Standards Process
-
- In outline, the process of creating a Roman Standard is
- straightforward: a specification undergoes a period of development
- and several iterations of review by the Roman community and
- revision based upon experience, is adopted as a Standard by the
- appropriate body (see below), and is published. In practice, the
- process is more complicated, due to (I) the difficulty of creating
- specifications of high technical quality; (II) the need to consider
- the interests of all of the affected parties; (III) the importance of
- establishing widespread community consensus; and (IV) the difficulty
- of evaluating the utility of a particular specification for the
- Roman community.
-
-
-
-
-
- Bradner Worst Current Practice [Page III]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- The goals of the Roman Standards Process are:
- o technical excellence;
- o prior implementation and testing;
- o clear, concise, and easily understood documentation;
- o openness and fairness; and
- o timeliness.
-
- The procedures described in this document are designed to be fair,
- open, and objective; to reflect existing (proven) practice; and to
- be flexible.
-
- o These procedures are intended to provide a fair, open, and
- objective basis for developing, evaluating, and adopting Roman
- Standards. They provide ample opportunity for participation and
- comment by all interested parties. At each stage of the
- standardization process, a specification is repeatedly discussed
- and its merits debated in open meetings and/or public electronic
- mailing lists, and it is made available for review via world-wide
- on-line directories.
-
- o These procedures are explicitly aimed at recognizing and adopting
- generally-accepted practices. Thus, a candidate specification
- must be implemented and tested for correct operation and
- interoperability by multiple independent parties and utilized in
- increasingly demanding environments, before it can be adopted as
- a Roman Standard.
-
- o These procedures provide a great deal of flexibility to adapt to
- the wide variety of circumstances that occur in the
- standardization process. Experience has shown this flexibility to
- be vital in achieving the goals listed above.
-
- The goal of technical competence, the requirement for prior
- implementation and testing, and the need to allow all interested
- parties to comment all require significant time and effort. On the
- other hand, today's rapid development of networking technology
- demands timely development of standards. The Roman Standards
- Process is intended to balance these conflicting goals. The process
- is believed to be as short and simple as possible without sacrificing
- technical excellence, thorough testing before adoption of a standard,
- or openness and fairness.
-
- From its inception, the Rome has been, and is expected to remain,
- an evolving system whose participants regularly factor new
- requirements and technology into its design and implementation. Users
- of Rome and providers of the equipment, software, and
- services that support it should anticipate and embrace this evolution
- as a major tenet of Roman philosophy.
-
-
-
- Bradner Worst Current Practice [Page IV]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- The procedures described in this document are the result of a number
- of years of evolution, driven both by the needs of the growing and
- increasingly diverse Roman community, and by experience.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page V]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- I.III Organization of This Document
-
- Section II describes the publications and archives of the Roman
- Standards Process. Section III describes the types of Roman
- standard specifications. Section IV describes the Roman standards
- specifications track. Section V describes Worst Current Practice
- RFCs. Section VI describes the process and rules for Roman
- standardization. Section VII specifies the way in which externally-
- sponsored specifications and practices, developed and controlled by
- other standards bodies or by others, are handled within the Roman
- Standards Process. Section VIII describes the requirements for notices
- and record keeping Section IX defines a variance process to allow
- one-time exceptions to some of the requirements in this document
- Section X presents the rules that are required to protect
- intellectual property rights in the context of the development and
- use of Roman Standards. Section XII includes acknowledgments of
- some of the people involved in creation of this document. Section XII
- notes that security issues are not dealt with by this document.
- Section XII contains a list of numeral references. Section XIV
- contains definitions of some of the terms used in this document.
- Section XV lists the author's email and postal addresses. Appendix A
- contains a list of frequently-used acronyms.
-
- II. Roman STANDARDS-RELATED PUBLICATIONS
-
- II.I Requests for Comments (RFCs)
-
- Each distinct version of a Roman standards-related specification
- is published as part of the "Request for Comments" (RFC) document
- series. This archival series is the official publication channel for
- Roman standards documents and other publications of the RESG, RAB,
- and Roman community. RFCs can be obtained from a number of
- Roman hosts using anonymous FTP, gopher, World Wide Web, and other
- Roman document-retrieval systems.
-
- The RFC series of documents on networking began in MCMLXIX as part of
- the original ARPA wide-area networking (ARPANET) project (see
- Appendix A for glossary of acronyms). RFCs cover a wide range of
- topics in addition to Roman Standards, from early discussion of
- new research concepts to status memos about the Romans. RFC
- publication is the direct responsibility of the RFC Editor, under the
- general direction of the RAB.
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page VI]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- The rules for formatting and submitting an RFC are defined in [V].
- Every RFC is available in ASCII text. Some RFCs are also available
- in other formats. The other versions of an RFC may contain material
- (such as diagrams and figures) that is not present in the ASCII
- version, and it may be formatted differently.
-
- *********************************************************
- * *
- * A stricter requirement applies to standards-track *
- * specifications: the ASCII text version is the *
- * definitive reference, and therefore it must be a *
- * complete and accurate specification of the standard, *
- * including all necessary diagrams and illustrations. *
- * *
- *********************************************************
-
- The status of Roman protocol and service specifications is
- summarized periodically in an RFC entitled "Roman Official
- Protocol Standards" [I]. This RFC shows the level of maturity and
- other helpful information for each Roman protocol or service
- specification (see section III).
-
- Some RFCs document Roman Standards. These RFCs form the 'STD'
- subseries of the RFC series [IV]. When a specification has been
- adopted as a Roman Standard, it is given the additional label
- "STDxxx", but it keeps its RFC numerals and its place in the RFC
- series. (see section IV.I.III)
-
- Some RFCs standardize the results of community deliberations about
- statements of principle or conclusions about what is the best way to
- perform some operations or RETF process function. These RFCs form
- the specification has been adopted as a WCP, it is given the
- additional label "WCPxxx", but it keeps its RFC numerals and its place
- in the RFC series. (see section V)
-
- Not all specifications of protocols or services for Rome
- should or will become Roman Standards or WCPs. Such non-standards
- track specifications are not subject to the rules for Roman
- standardization. Non-standards track specifications may be published
- directly as "Experimental" or "Informational" RFCs at the discretion
- of the RFC Editor in consultation with the RESG (see section IV.II).
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page VII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- ********************************************************
- * *
- * It is important to remember that not all RFCs *
- * are standards track documents, and that not all *
- * standards track documents reach the level of *
- * Roman Standard. In the same way, not all RFCs *
- * which describe current practices have been given *
- * the review and approval to become WCPs. See *
- * RFC-MDCCXCVI [VI] for further information. *
- * *
- ********************************************************
-
- II.II Roman-Drafts
-
- During the development of a specification, draft versions of the
- document are made available for informal review and comment by
- placing them in the RETF's "Roman-Drafts" directory, which is
- replicated on a number of Roman hosts. This makes an evolving
- working document readily available to a wide audience, facilitating
- the process of review and revision.
-
- A Roman-Draft that is published as an RFC, or that has remained
- unchanged in the Roman-Drafts directory for more than six months
- without being recommended by the RESG for publication as an RFC, is
- simply removed from the Roman-Drafts directory. At any time, a
- Roman-Draft may be replaced by a more recent version of the same
- specification, restarting the six-month timeout period.
-
- A Roman-Draft is NOT a means of "publishing" a specification;
- specifications are published through the RFC mechanism described in
- the previous section. Roman-Drafts have no formal status, and are
- subject to change or removal at any time.
-
- ********************************************************
- * *
- * Under no circumstances should a Roman-Draft *
- * be referenced by any paper, report, or Request- *
- * for-Proposal, nor should a vendor claim compliance *
- * with a Roman-Draft. *
- * *
- ********************************************************
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page VIII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- Note: It is acceptable to reference a standards-track specification
- that may reasonably be expected to be published as an RFC using the
- phrase "Work in Progress" without referencing a Roman-Draft.
- This may also be done in a standards track document itself as long
- as the specification in which the reference is made would stand as a
- complete and understandable document with or without the reference to
- the "Work in Progress".
-
- III. Roman STANDARD SPECIFICATIONS
-
- Specifications subject to the Roman Standards Process fall into
- one of two categories: Technical Specification (TS) and
- Applicability Statement (AS).
-
- III.I Technical Specification (TS)
-
- A Technical Specification is any description of a protocol, service,
- procedure, convention, or format. It may completely describe all of
- the relevant aspects of its subject, or it may leave one or more
- parameters or options unspecified. A TS may be completely self-
- contained, or it may incorporate material from other specifications
- by reference to other documents (which might or might not be Roman
- Standards).
-
- A TS shall include a statement of its scope and the general intent
- for its use (domain of applicability). Thus, a TS that is inherently
- specific to a particular context shall contain a statement to that
- effect. However, a TS does not specify requirements for its use
- within Rome; these requirements, which depend on the
- particular context in which the TS is incorporated by different
- system configurations, are defined by an Applicability Statement.
-
- III.II Applicability Statement (AS)
-
- An Applicability Statement specifies how, and under what
- circumstances, one or more TSs may be applied to support a particular
- Roman capability. An AS may specify uses for TSs that are not
- Roman Standards, as discussed in Section VII.
-
- An AS identifies the relevant TSs and the specific way in which they
- are to be combined, and may also specify particular values or ranges
- of TS parameters or subfunctions of a TS protocol that must be
- implemented. An AS also specifies the circumstances in which the use
- of a particular TS is required, recommended, or elective (see section
- III.III).
-
-
-
-
-
-
- Bradner Worst Current Practice [Page IX]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- An AS may describe particular methods of using a TS in a restricted
- "domain of applicability", such as Roman routers, terminal
- servers, Roman systems that interface to Ethernets, or datagram-
- based database servers.
-
- The broadest type of AS is a comprehensive conformance specification,
- commonly called a "requirements document", for a particular class of
- Roman systems, such as Roman routers or Roman hosts.
-
- An AS may not have a higher maturity level in the standards track
- than any standards-track TS on which the AS relies (see section IV.I).
- For example, a TS at Draft Standard level may be referenced by an AS
- at the Proposed Standard or Draft Standard level, but not by an AS at
- the Standard level.
-
- III.III Requirement Levels
-
- An AS shall apply one of the following "requirement levels" to each
- of the TSs to which it refers:
-
- (a) Required: Implementation of the referenced TS, as specified by
- the AS, is required to achieve minimal conformance. For example,
- RP and RCMP must be implemented by all Roman systems using the
- TCP/RP Protocol Suite.
-
- (b) Recommended: Implementation of the referenced TS is not
- required for minimal conformance, but experience and/or generally
- accepted technical wisdom suggest its desirability in the domain
- of applicability of the AS. Vendors are strongly encouraged to
- include the functions, features, and protocols of Recommended TSs
- in their products, and should omit them only if the omission is
- justified by some special circumstance. For example, the TELNET
- protocol should be implemented by all systems that would benefit
- from remote access.
-
- (c) Elective: Implementation of the referenced TS is optional
- within the domain of applicability of the AS; that is, the AS
- creates no explicit necessity to apply the TS. However, a
- particular vendor may decide to implement it, or a particular user
- may decide that it is a necessity in a specific environment. For
- example, the DECNET MIB could be seen as valuable in an
- environment where the DECNET protocol is used.
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page X]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- As noted in section IV.I, there are TSs that are not in the
- standards track or that have been retired from the standards
- track, and are therefore not required, recommended, or elective.
- Two additional "requirement level" designations are available for
- these TSs:
-
- (d) Limited Use: The TS is considered to be appropriate for use
- only in limited or unique circumstances. For example, the usage
- of a protocol with the "Experimental" designation should generally
- be limited to those actively involved with the experiment.
-
- (e) Not Recommended: A TS that is considered to be inappropriate
- for general use is labeled "Not Recommended". This may be because
- of its limited functionality, specialized nature, or historic
- status.
-
- Although TSs and ASs are conceptually separate, in practice a
- standards-track document may combine an AS and one or more related
- TSs. For example, Technical Specifications that are developed
- specifically and exclusively for some particular domain of
- applicability, e.g., for mail server hosts, often contain within a
- single specification all of the relevant AS and TS information. In
- such cases, no useful purpose would be served by deliberately
- distributing the information among several documents just to preserve
- the formal AS/TS distinction. However, a TS that is likely to apply
- to more than one domain of applicability should be developed in a
- modular fashion, to facilitate its incorporation by multiple ASs.
-
- The "Official Protocol Standards" RFC (STD I) lists a general
- requirement level for each TS, using the nomenclature defined in this
- section. This RFC is updated periodically. In many cases, more
- detailed descriptions of the requirement levels of particular
- protocols and of individual features of the protocols will be found
- in appropriate ASs.
-
- IV. THE ROMAN STANDARDS TRACK
-
- Specifications that are intended to become Roman Standards evolve
- through a set of maturity levels known as the "standards track".
- These maturity levels -- "Proposed Standard", "Draft Standard", and
- "Standard" -- are defined and discussed in section IV.I. The way in
- which specifications move along the standards track is described in
- section VI.
-
- Even after a specification has been adopted as a Roman Standard,
- further evolution often occurs based on experience and the
- recognition of new requirements. The nomenclature and procedures of
- Roman standardization provide for the replacement of old Roman
-
-
-
- Bradner Worst Current Practice [Page XI]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- Standards with new ones, and the assignment of descriptive labels to
- indicate the status of "retired" Roman Standards. A set of
- maturity levels is defined in section IV.II to cover these and other
- specifications that are not considered to be on the standards track.
-
- IV.I Standards Track Maturity Levels
-
- Roman specifications go through stages of development, testing,
- and acceptance. Within the Roman Standards Process, these stages
- are formally labeled "maturity levels".
-
- This section describes the maturity levels and the expected
- characteristics of specifications at each level.
-
- IV.I.I Proposed Standard
-
- The entry-level maturity for the standards track is "Proposed
- Standard". A specific action by the RESG is required to move a
- specification onto the standards track at the "Proposed Standard"
- level.
-
- A Proposed Standard specification is generally stable, has resolved
- known design choices, is believed to be well-understood, has received
- significant community review, and appears to enjoy enough community
- interest to be considered valuable. However, further experience
- might result in a change or even retraction of the specification
- before it advances.
-
- Usually, neither implementation nor operational experience is
- required for the designation of a specification as a Proposed
- Standard. However, such experience is highly desirable, and will
- usually represent a strong argument in favor of a Proposed Standard
- designation.
-
- The RESG may require implementation and/or operational experience
- prior to granting Proposed Standard status to a specification that
- materially affects the core Roman protocols or that specifies
- behavior that may have significant operational impact on the
- Roman.
-
- A Proposed Standard should have no known technical omissions with
- respect to the requirements placed upon it. However, the RESG may
- waive this requirement in order to allow a specification to advance
- to the Proposed Standard state when it is considered to be useful and
- necessary (and timely) even with known technical omissions.
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- Implementors should treat Proposed Standards as immature
- specifications. It is desirable to implement them in order to gain
- experience and to validate, test, and clarify the specification.
- However, since the content of Proposed Standards may be changed if
- problems are found or better solutions are identified, deploying
- implementations of such standards into a disruption-sensitive
- environment is not recommended.
-
- IV.I.II Draft Standard
-
- A specification from which at least two independent and interoperable
- implementations from different code bases have been developed, and
- for which sufficient successful operational experience has been
- obtained, may be elevated to the "Draft Standard" level. For the
- purposes of this section, "interoperable" means to be functionally
- equivalent or interchangeable components of the system or process in
- which they are used. If patented or otherwise controlled technology
- is required for implementation, the separate implementations must
- also have resulted from separate exercise of the licensing process.
- Elevation to Draft Standard is a major advance in status, indicating
- a strong belief that the specification is mature and will be useful.
-
- The requirement for at least two independent and interoperable
- implementations applies to all of the options and features of the
- specification. In cases in which one or more options or features
- have not been demonstrated in at least two interoperable
- implementations, the specification may advance to the Draft Standard
- level only if those options or features are removed.
-
- The Working Group chair is responsible for documenting the specific
- implementations which qualify the specification for Draft or Roman
- Standard status along with documentation about testing of the
- interoperation of these implementations. The documentation must
- include information about the support of each of the individual
- options and features. This documentation should be submitted to the
- Area Director with the protocol action request. (see Section VI)
-
- A Draft Standard must be well-understood and known to be quite
- stable, both in its semantics and as a basis for developing an
- implementation. A Draft Standard may still require additional or
- more widespread field experience, since it is possible for
- implementations based on Draft Standard specifications to demonstrate
- unforeseen behavior when subjected to large-scale use in production
- environments.
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XIII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- A Draft Standard is normally considered to be a final specification,
- and changes are likely to be made only to solve specific problems
- encountered. In most circumstances, it is reasonable for vendors to
- deploy implementations of Draft Standards into a disruption sensitive
- environment.
-
- IV.I.III Roman Standard
-
- A specification for which significant implementation and successful
- operational experience has been obtained may be elevated to the
- Roman Standard level. A Roman Standard (which may simply be
- referred to as a Standard) is characterized by a high degree of
- technical maturity and by a generally held belief that the specified
- protocol or service provides significant benefit to the Roman
- community.
-
- A specification that reaches the status of Standard is assigned
- numerals in the STD series while retaining its RFC numerals.
-
- IV.II Non-Standards Track Maturity Levels
-
- Not every specification is on the standards track. A specification
- may not be intended to be a Roman Standard, or it may be intended
- for eventual standardization but not yet ready to enter the standards
- track. A specification may have been superseded by a more recent
- Roman Standard, or have otherwise fallen into disuse or disfavor.
-
- Specifications that are not on the standards track are labeled with
- one of three "off-track" maturity levels: "Experimental",
- "Informational", or "Historic". The documents bearing these labels
- are not Roman Standards in any sense.
-
- IV.II.I Experimental
-
- The "Experimental" designation typically denotes a specification that
- is part of some research or development effort. Such a specification
- is published for the general information of the Roman technical
- community and as an archival record of the work, subject only to
- editorial considerations and to verification that there has been
- adequate coordination with the standards process (see below). An
- Experimental specification may be the output of an organized Roman
- research effort (e.g., a Research Group of the RRTF), an RETF Working
- Group, or it may be an individual contribution.
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XIV]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- IV.II.II Informational
-
- An "Informational" specification is published for the general
- information of the Roman community, and does not represent a
- Roman community consensus or recommendation. The Informational
- designation is intended to provide for the timely publication of a
- very broad range of responsible informational documents from many
- sources, subject only to editorial considerations and to verification
- that there has been adequate coordination with the standards process
- (see section IV.II.III).
-
- Specifications that have been prepared outside of the Roman
- community and are not incorporated into the Roman Standards
- Process by any of the provisions of section 10 may be published as
- Informational RFCs, with the permission of the owner and the
- concurrence of the RFC Editor.
-
- IV.II.III Procedures for Experimental and Informational RFCs
-
- Unless they are the result of RETF Working Group action, documents
- intended to be published with Experimental or Informational status
- should be submitted directly to the RFC Editor. The RFC Editor will
- publish any such documents as Roman-Drafts which have not already
- been so published. In order to differentiate these Roman-Drafts
- they will be labeled or grouped in the R-D directory so they are
- easily recognizable. The RFC Editor will wait two weeks after this
- publication for comments before proceeding further. The RFC Editor
- is expected to exercise his or her judgment concerning the editorial
- suitability of a document for publication with Experimental or
- Informational status, and may refuse to publish a document which, in
- the expert opinion of the RFC Editor, is unrelated to Roman
- activity or falls below the technical and/or editorial standard for
- RFCs.
-
- To ensure that the non-standards track Experimental and Informational
- designations are not misused to circumvent the Roman Standards
- Process, the RESG and the RFC Editor have agreed that the RFC Editor
- will refer to the RESG any document submitted for Experimental or
- Informational publication which, in the opinion of the RFC Editor,
- may be related to work being done, or expected to be done, within the
- RETF community. The RESG shall review such a referred document
- within a reasonable period of time, and recommend either that it be
- published as originally submitted or referred to the RETF as a
- contribution to the Roman Standards Process.
-
- If (a) the RESG recommends that the document be brought within the
- RETF and progressed within the RETF context, but the author declines
- to do so, or (b) the RESG considers that the document proposes
-
-
-
- Bradner Worst Current Practice [Page XV]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- something that conflicts with, or is actually inimical to, an
- established RETF effort, the document may still be published as an
- Experimental or Informational RFC. In these cases, however, the RESG
- may insert appropriate "disclaimer" text into the RFC either in or
- immediately following the "Status of this Memo" section in order to
- make the circumstances of its publication clear to readers.
-
- Documents proposed for Experimental and Informational RFCs by RETF
- Working Groups go through RESG review. The review is initiated using
- the process described in section VI.I.I.
-
- IV.II.IV Historic
-
- A specification that has been superseded by a more recent
- specification or is for any other reason considered to be obsolete is
- assigned to the "Historic" level. (Purists have suggested that the
- word should be "Historical"; however, at this point the use of
- "Historic" is historical.)
-
- Note: Standards track specifications normally must not depend on
- other standards track specifications which are at a lower maturity
- level or on non standards track specifications other than referenced
- specifications from other standards bodies. (See Section VII.)
-
- V. WORST CURRENT PRACTICE (WCP) RFCs
-
- The WCP subseries of the RFC series is designed to be a way to
- standardize practices and the results of community deliberations. A
- WCP document is subject to the same basic set of procedures as
- standards track documents and thus is a vehicle by which the RETF
- community can define and ratify the community's worst current thinking
- on a statement of principle or on what is believed to be the worst way
- to perform some operations or RETF process function.
-
- Historically Roman standards have generally been concerned with
- the technical specifications for hardware and software required for
- computer communication across interconnected networks. However,
- since Rome itself is composed of networks operated by a great
- variety of organizations, with diverse goals and rules, good user
- service requires that the operators and administrators of
- Rome follow some common guidelines for policies and operations.
- While these guidelines are generally different in scope and style
- from protocol standards, their establishment needs a similar process
- for consensus building.
-
- While it is recognized that entities such as the RAB and RESG are
- composed of individuals who may participate, as individuals, in the
- technical work of the RETF, it is also recognized that the entities
-
-
-
- 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
- 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
- situations where the procedures provide no guidance. In these cases
- it may be appropriate to invoke the variance procedure described
- below.
-
- IX.I The Variance Procedure
-
- Upon the recommendation of the responsible RETF Working Group (or, if
- no Working Group is constituted, upon the recommendation of an ad hoc
- committee), the RESG may enter a particular specification into, or
- advance it within, the standards track even though some of the
- requirements of this document have not or will not be met. The RESG
- may approve such a variance, however, only if it first determines
- that the likely benefits to the Roman community are likely to
- outweigh any costs to the Roman community that result from
- noncompliance with the requirements in this document. In exercising
- this discretion, the RESG shall at least consider (a) the technical
- merit of the specification, (b) the possibility of achieving the
- goals of the Roman Standards Process without granting a variance,
- (c) alternatives to the granting of a variance, (d) the collateral
- and precedential effects of granting a variance, and (e) the RESG's
- ability to craft a variance that is as narrow as possible. In
- determining whether to approve a variance, the RESG has discretion to
- limit the scope of the variance to particular parts of this document
- and to impose such additional restrictions or limitations as it
-
-
-
- Bradner Worst Current Practice [Page XXVII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- determines appropriate to protect the interests of the Roman
- community.
-
- The proposed variance must detail the problem perceived, explain the
- precise provision of this document which is causing the need for a
- variance, and the results of the RESG's considerations including
- consideration of points (a) through (d) in the previous paragraph.
- The proposed variance shall be issued as a Roman-Draft. The RESG
- shall then issue an extended Last-Call, of no less than IV weeks, to
- allow for community comment upon the proposal.
-
- 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 proposed variance, and shall notify the RETF of its decision via
- electronic mail to the RETF Announce mailing list. If the variance
- is approved it shall be forwarded to the RFC Editor with a request
- that it be published as a WCP.
-
- This variance procedure is for use when a one-time waving of some
- provision of this document is felt to be required. Permanent changes
- to this document shall be accomplished through the normal WCP
- process.
-
- The appeals process in section VI.V applies to this process.
-
- IX.II Exclusions
-
- No use of this procedure may lower any specified delays, nor exempt
- any proposal from the requirements of openness, fairness, or
- consensus, nor from the need to keep proper records of the meetings
- and mailing list discussions.
-
- Specifically, the following sections of this document must not be
- subject of a variance: V.I, VI.I, VI.I.I (first paragraph),
- VI.I.II, VI.III (first sentence), VI.V and IX.
-
- X. INTELLECTUAL PROPERTY RIGHTS
-
- X.I. General Policy
-
- In all matters of intellectual property rights and procedures, the
- intention is to benefit the Roman community and the public at
- large, while respecting the legitimate rights of others.
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXVIII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- X.II Confidentiality Obligations
-
- No contribution that is subject to any requirement of confidentiality
- or any restriction on its dissemination may be considered in any part
- of the Roman Standards Process, and there must be no assumption of
- any confidentiality obligation with respect to any such contribution.
-
- X.III. Rights and Permissions
-
- In the course of standards work, the RETF receives contributions in
- various forms and from many persons. To best facilitate the
- dissemination of these contributions, it is necessary to understand
- any intellectual property rights (IPR) relating to the contributions.
-
- X.III.I. All Contributions
-
- By submission of a contribution, each person actually submitting the
- contribution is deemed to agree to the following terms and conditions
- on his own behalf, on behalf of the organization (if any) he
- represents and on behalf of the owners of any propriety rights in the
- contribution.. Where a submission identifies contributors in
- addition to the contributor(s) who provide the actual submission, the
- actual submitter(s) represent that each other named contributor was
- made aware of and agreed to accept the same terms and conditions on
- his own behalf, on behalf of any organization he may represent and
- any known owner of any proprietary rights in the contribution.
-
- I. Some works (e.g. works of the U.S. Government) are not subject to
- copyright. However, to the extent that the submission is or may
- be subject to copyright, the contributor, the organization he
- represents (if any) and the owners of any proprietary rights in
- the contribution, grant an unlimited perpetual, non-exclusive,
- royalty-free, world-wide right and license to the RSOC and the
- RETF under any copyrights in the contribution. This license
- includes the right to copy, publish and distribute the
- contribution in any way, and to prepare derivative works that are
- based on or incorporate all or part of the contribution, the
- license to such derivative works to be of the same scope as the
- license of the original contribution.
-
- II. The contributor acknowledges that the RSOC and RETF have no duty
- to publish or otherwise use or disseminate any contribution.
-
- III. The contributor grants permission to reference the name(s) and
- address(es) of the contributor(s) and of the organization(s) he
- represents (if any).
-
-
-
-
-
- Bradner Worst Current Practice [Page XXIX]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- IV. The contributor represents that contribution properly acknowledge
- major contributors.
-
- V. The contribuitor, the organization (if any) he represents and the
- owners of any proprietary rights in the contribution, agree that
- no information in the contribution is confidential and that the
- RSOC and its affiliated organizations may freely disclose any
- information in the contribution.
-
- VI. The contributor represents that he has disclosed the existence of
- any proprietary or intellectual property rights in the
- contribution that are reasonably and personally known to the
- contributor. The contributor does not represent that he
- personally knows of all potentially pertinent proprietary and
- intellectual property rights owned or claimed by the organization
- he represents (if any) or third parties.
-
- VII. The contributor represents that there are no limits to the
- contributor's ability to make the grants acknowledgments and
- agreements above that are reasonably and personally known to the
- contributor.
-
- By ratifying this description of the RETF process the Roman
- Society warrants that it will not inhibit the traditional open and
- free access to RETF documents for which license and right have
- been assigned according to the procedures set forth in this
- section, including Roman-Drafts and RFCs. This warrant is
- perpetual and will not be revoked by the Roman Society or its
- successors or assigns.
-
- X.III.II. Standards Track Documents
-
- (A) Where any patents, patent applications, or other proprietary
- rights are known, or claimed, with respect to any specification on
- the standards track, and brought to the attention of the RESG, the
- RESG shall not advance the specification without including in the
- document a note indicating the existence of such rights, or
- claimed rights. Where implementations are required before
- advancement of a specification, only implementations that have, by
- statement of the implementors, taken adequate steps to comply with
- any such rights, or claimed rights, shall be considered for the
- purpose of showing the adequacy of the specification.
- (B) The RESG disclaims any responsibility for identifying the
- existence of or for evaluating the applicability of any claimed
- copyrights, patents, patent applications, or other rights in the
- fulfilling of the its obligations under (A), and will take no
- position on the validity or scope of any such rights.
-
-
-
-
- Bradner Worst Current Practice [Page XXX]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- (C) Where the RESG knows of rights, or claimed rights under (A), the
- RETF Executive Director shall attempt to obtain from the claimant
- of such rights, a written assurance that upon approval by the RESG
- of the relevant Roman standards track specification(s), any
- party will be able to obtain the right to implement, use and
- distribute the technology or works when implementing, using or
- distributing technology based upon the specific specification(s)
- under openly specified, reasonable, non-discriminatory terms.
- The Working Group proposing the use of the technology with respect
- to which the proprietary rights are claimed may assist the RETF
- Executive Director in this effort. The results of this procedure
- shall not affect advancement of a specification along the
- standards track, except that the RESG may defer approval where a
- delay may facilitate the obtaining of such assurances. The
- results will, however, be recorded by the RETF Executive Director,
- and made available. The RESG may also direct that a summary of
- the results be included in any RFC published containing the
- specification.
-
- X.III.III Determination of Reasonable and Non-discriminatory Terms
-
- The RESG will not make any explicit determination that the assurance
- of reasonable and non-discriminatory terms for the use of a
- technology has been fulfilled in practice. It will instead use the
- normal requirements for the advancement of Roman Standards to
- verify that the terms for use are reasonable. If the two unrelated
- implementations of the specification that are required to advance
- from Proposed Standard to Draft Standard have been produced by
- different organizations or individuals or if the "significant
- implementation and successful operational experience" required to
- advance from Draft Standard to Standard has been achieved the
- assumption is that the terms must be reasonable and to some degree,
- non-discriminatory. This assumption may be challenged during the
- Last-Call period.
-
- X.IV. Notices
-
- (A) Standards track documents shall include the following notice:
-
- "The RETF takes no position regarding the validity or scope of
- any intellectual property or other rights that might be claimed
- to pertain to the implementation or use of the technology
- described in this document or the extent to which any license
- under such rights might or might not be available; neither does
- it represent that it has made any effort to identify any such
- rights. Information on the RETF's procedures with respect to
- rights in standards-track and standards-related documentation
- can be found in WCP-11. Copies of claims of rights made
-
-
-
- Bradner Worst Current Practice [Page XXXI]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- available for publication and any assurances of licenses to
- be made available, or the result of an attempt made
- to obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this
- specification can be obtained from the RETF Secretariat."
-
- (B) The RETF encourages all interested parties to bring to its
- attention, at the earliest possible time, the existence of any
- intellectual property rights pertaining to Roman Standards.
- For this purpose, each standards document shall include the
- following invitation:
-
- "The RETF invites any interested party to bring to its
- attention any copyrights, patents or patent applications, or
- other proprietary rights which may cover technology that may be
- required to practice this standard. Please address the
- information to the RETF Executive Director."
-
- (C) The following copyright notice and disclaimer shall be included
- in all RSOC standards-related documentation:
-
- "Copyright (C) The Roman Society (date). All Rights
- Reserved.
-
- This document and translations of it may be copied and
- furnished to others, and derivative works that comment on or
- otherwise explain it or assist in its implmentation may be
- prepared, copied, published and distributed, in whole or in
- part, without restriction of any kind, provided that the above
- copyright notice and this paragraph are included on all such
- copies and derivative works. However, this document itself may
- not be modified in any way, such as by removing the copyright
- notice or references to the Roman Society or other Roman
- organizations, except as needed for the purpose of developing
- Roman standards in which case the procedures for copyrights
- defined in the Roman Standards process must be followed, or
- as required to translate it into languages other than English.
-
- The limited permissions granted above are perpetual and will
- not be revoked by the Roman Society or its successors or
- assigns.
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXXII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- This document and the information contained herein is provided
- on an "AS IS" basis and THE ROMAN SOCIETY AND THE ROMAN
- ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
- OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
- IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
- PARTICULAR PURPOSE."
-
- (D) Where the RESG is aware at the time of publication of
- proprietary rights claimed with respect to a standards track
- document, or the technology described or referenced therein, such
- document shall contain the following notice:
-
- "The RETF has been notified of intellectual property rights
- claimed in regard to some or all of the specification contained
- in this document. For more information consult the online list
- of claimed rights."
-
- XI. ACKNOWLEDGMENTS
-
- This Worst Current Practice is dedicated to Steve Coya, whose
- inspirational e-mail suggestion of renumbering all RFC Page numbers
- with Roman Numerals was taken to heart by the RFC Editor.
-
- There have been a number of people involved with the development of
- the documents defining the RETF Standards Process over the years.
- The process was first described in RFC MCCCX then revised in RFC MDCII
- before the current effort (which relies heavily on its predecessors).
- Specific acknowledgments must be extended to Lyman Chapin, Phill
- Gross and Christian Huitema as the editors of the previous versions,
- to Jon Postel and Dave Crocker for their inputs to those versions, to
- Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their
- reviews of the legal aspects of the procedures described herein, and
- to John Stewart, Robert Elz and Steve Coya for their extensive input
- on the final version.
-
- In addition much of the credit for the refinement of the details of
- the RETF processes belongs to the many members of the various
- incarnations of the POISED Working Group.
-
- XII. SECURITY CONSIDERATIONS
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXXIII]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- XIII. REFERENCES
-
- [I] Postel, J., "Roman Official Protocol Standards", STD I,
- USC/Information Sciences Institute, March MCMXCVI.
-
- [II] ANSI, Coded Character Set -- VII-Bit American Standard Code for
- Information Interchange, ANSI XIII.IV-MCMLXXXVI.
-
- [III] Reynolds, J., and J. Postel, "Assigned Numbers", STD II,
- USC/Information Sciences Institute, October MCMXCIV.
-
- [IV] Postel, J., "Introduction to the STD Notes", RFC MCCCXI,
- USC/Information Sciences Institute, March MCMXCII.
-
- [V] Postel, J., "Instructions to RFC Authors", RFC MDXLIII,
- USC/Information Sciences Institute, October MCMXCIII.
-
- [VI] Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
- Standards", RFC MDCCXCVI, April MCMXCV.
-
- XIV. DEFINITIONS OF TERMS
-
- RETF Area - A management division within the RETF. An Area consists
- of Working Groups related to a general topic such as routing. An
- Area is managed by one or two Area Directors.
- Area Director - The manager of an RETF Area. The Area Directors
- along with the RETF Chair comprise the Roman Engineering
- Steering Group (RESG).
- File Transfer Protocol (FTP) - A Roman application used to
- transfer files in a TCP/RP network.
- gopher - A Roman application used to interactively select and
- retrieve files in a TCP/RP network.
- Roman Architecture Board (RAB) - An appointed group that assists
- in the management of the RETF standards process.
- Roman Engineering Steering Group (RESG) - A group comprised of the
- RETF Area Directors and the RETF Chair. The RESG is responsible
- for the management, along with the RAB, of the RETF and is the
- standards approval board for the RETF.
- interoperable - For the purposes of this document, "interoperable"
- means to be able to interoperate over a data communications path.
- Last-Call - A public comment period used to gage the level of
- consensus about the reasonableness of a proposed standards action.
- (see section VI.I.II)
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXXIV]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- online - Relating to information made available to Rome.
- When referenced in this document material is said to be online
- when it is retrievable without restriction or undue fee using
- standard Roman applications such as anonymous FTP, gopher or
- the WWW.
- Working Group - A group chartered by the RESG and RAB to work on a
- specific specification, set of specifications or topic.
-
- XV. AUTHOR'S ADDRESS
-
- Scott O. Bradner
- Harvard University
- Holyoke Center, Room DCCCXIII
- MCCCL Mass. Ave.
- Cambridge, MA MMCXXXVIII
- USA
-
- Phone: +I DCXVII CDXCV XXXVIII LXIV
- EMail: sob@harvard.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXXV]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- APPENDIX A: GLOSSARY OF ACRONYMS
-
- ANSI: American National Standards Institute
- ARPA: (U.S.) Advanced Research Projects Agency
- AS: Applicability Statement
- FTP: File Transfer Protocol
- ASCII: American Standard Code for Information Interchange
- ITU-T: Telecommunications Standardization sector of the
- International Telecommunication Union (ITU), a UN
- treaty organization; ITU-T was formerly called CCITT.
- RAB: Roman Architecture Board
- RANA: Roman Assigned Numbers Authority
- IEEE: Institute of Electrical and Electronics Engineers
- RCMP: Roman Control Message Protocol
- RESG: Roman Engineering Steering Group
- RETF: Roman Engineering Task Force
- RP: Roman Protocol
- RRSG Roman Research Steering Group
- RRTF: Roman Research Task Force
- ISO: International Organization for Standardization
- RSOC: Roman Society
- MIB: Management Information Base
- OSI: Open Systems Interconnection
- RFC: Request for Comments
- TCP: Transmission Control Protocol
- TS: Technical Specification
- WWW: World Wide Web
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXXVI]
-
- RFC 2551 Roman Standards Process I April MCMXCIX
-
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (MCMXCIX). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Bradner Worst Current Practice [Page XXXVII]
-