diff options
Diffstat (limited to 'doc/rfc/rfc2551.txt')
| -rw-r--r-- | doc/rfc/rfc2551.txt | 2072 |
1 files changed, 2072 insertions, 0 deletions
diff --git a/doc/rfc/rfc2551.txt b/doc/rfc/rfc2551.txt new file mode 100644 index 0000000..9d70f3e --- /dev/null +++ b/doc/rfc/rfc2551.txt @@ -0,0 +1,2072 @@ + + + + + +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] +
\ No newline at end of file |