home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2551.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  88.2 KB  |  2,072 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6. Network Working Group                                         S. Bradner
  7. Request for Comments: 2551                            Harvard University
  8. WCP: IX                                                  I April MCMXCIX
  9. Obsoletes: MMXXVI
  10. Category: Worst Current Practice
  11.  
  12.               The Roman Standards Process -- Revision III
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies a Roman Worst Current Practices for the
  17.    Roman Community, and requests discussion and suggestions for
  18.    improvements.  Distribution of this memo is unlimited.
  19.  
  20. Copyright Statement
  21.  
  22.    Copyright (C) The Internet Society (MCMXCIX).  All Rights Reserved.
  23.  
  24. Abstract
  25.  
  26.    This memo documents the process used by the Roman community for
  27.    the standardization of protocols and procedures.  It defines the
  28.    stages in the standardization process, the requirements for moving a
  29.    document between stages and the types of documents used during this
  30.    process.  It also addresses the intellectual property rights and
  31.    copyright issues associated with the standards process.
  32.  
  33. Table of Contents
  34.  
  35.   I.   INTRODUCTION................................................III
  36.    I.I       Roman Standards.......................................III
  37.    I.II      The Roman Standards Process...........................III
  38.    I.III     Organization of This Document..........................VI
  39.   II.  ROMAN STANDARDS-RELATED PUBLICATIONS.........................VI
  40.    II.I      Requests for Comments (RFCs)...........................VI
  41.    II.II     Roman-Drafts.........................................VIII
  42.   III  ROMAN STANDARD SPECIFICATIONS................................IX
  43.    III.I     Technical Specification (TS)...........................IX
  44.    III.II    Applicability Statement (AS)...........................IX
  45.    III.III   Requirement Levels..................................... X
  46.   IV.  THE ROMAN STANDARDS TRACK....................................XI
  47.    IV.I      Standards Track Maturity Levels.......................XII
  48.    IV.I.I    Proposed Standard.....................................XII
  49.    IV.I.II   Draft Standard.......................................XIII
  50.    IV.I.III  Roman Standard........................................XIV
  51.    IV.II     Non-Standards Track Maturity Levels...................XIV
  52.    IV.II.I   Experimental..........................................XIV
  53.    IV.II.II  Informational..........................................XV
  54.    IV.II.III Procedures for Experimental and Informational RFCs.....XV
  55.    IV.II.IV  Historic..............................................XVI
  56.  
  57.  
  58. Bradner                 Worst Current Practice                  [Page I]
  59.  
  60. RFC 2551               Roman Standards Process           I April MCMXCIX
  61.  
  62.  
  63.   V.  Worst Current Practice (WCP) RFCs............................XVI
  64.    V.I       WCP Review Process...................................XVII
  65.   VI. THE ROMAN STANDARDS PROCESS................................XVIII
  66.    VI.I      Standards Actions...................................XVIII
  67.    VI.I.I    Initiation of Action................................XVIII
  68.    VI.I.II   RESG Review and Approval............................XVIII
  69.    VI.I.III  Publication...........................................XIX
  70.    VI.II     Advancing in the Standards Track...................... XX
  71.    VI.III    Revising a Standard...................................XXI
  72.    VI.IV     Retiring a Standard...................................XXI
  73.    VI.V      Conflict Resolution and Appeals......................XXII
  74.    VI.V.I    Working Group Disputes...............................XXII
  75.    VI.V.II   Process Failures....................................XXIII
  76.    VI.V.III  Questions of Applicable Procedure...................XXIII
  77.    VI.V.IV   Appeals Procedure....................................XXIV
  78.   VII. EXTERNAL STANDARDS AND SPECIFICATIONS......................XXIV
  79.    VII.I     Use of External Specifications........................XXV
  80.    VII.I.I   Incorporation of an Open Standard.....................XXV
  81.    VII.I.II  Incorporation of a Other Specifications...............XXV
  82.    VII.I.III Assumption...........................................XXVI
  83.   VIII. NOTICES AND RECORD KEEPING................................XXVI
  84.   IX.  VARYING THE PROCESS.......................................XXVII
  85.    IX.I      The Variance Procedure..............................XXVII
  86.    IX.II     Exclusions.........................................XXVIII
  87.   X.   INTELLECTUAL PROPERTY RIGHTS.............................XXVIII
  88.    X.I.      General Policy.....................................XXVIII
  89.    X.II      Confidentiality Obligations..........................XXIX
  90.    X.III     Rights and Permissions...............................XXIX
  91.    X.III.I   All Contributions....................................XXIX
  92.    X.III.II  Standards Track Documents.............................XXX
  93.    X.III.III Determination of Reasonable and
  94.              Non-discriminatory Terms.............................XXXI
  95.    X.IV.     Notices..............................................XXXI
  96.    XI.   ACKNOWLEDGMENTS........................................XXXIII
  97.    XII.  SECURITY CONSIDERATIONS................................XXXIII
  98.    XIII. REFERENCES..............................................XXXIV
  99.    XIV.  DEFINITIONS OF TERMS....................................XXXIV
  100.    XV.   AUTHOR'S ADDRESS.........................................XXXV
  101.    APPENDIX A: GLOSSARY OF ACRONYMS..............................XXXVI
  102.    Full Copyright Statement.....................................XXXVII
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Bradner                 Worst Current Practice                 [Page II]
  114.  
  115. RFC 2551               Roman Standards Process           I April MCMXCIX
  116.  
  117.  
  118. I.  INTRODUCTION
  119.  
  120.    This memo documents the process currently used by the Roman
  121.    community for the standardization of protocols and procedures.  The
  122.    Roman Standards process is an activity of the Roman Society
  123.    that is organized and managed on behalf of the Roman community by
  124.    the Roman Architecture Board (RAB) and the Roman Engineering
  125.    Steering Group (RESG).
  126.  
  127. I.I  Roman Standards
  128.  
  129.    The Roman, a loosely-organized international collaboration of
  130.    autonomous, interconnected networks, supports host-to-host
  131.    communication through voluntary adherence to open protocols and
  132.    procedures defined by Roman Standards.  There are also many
  133.    isolated interconnected networks, which are not connected to the
  134.    global Roman but use the Roman Standards.
  135.  
  136.    The Roman Standards Process described in this document is
  137.    concerned with all protocols, procedures, and conventions that are
  138.    used in or by the Roman, whether or not they are part of the
  139.    TCP/RP protocol suite.  In the case of protocols developed and/or
  140.    standardized by non-Roman organizations, however, the Roman
  141.    Standards Process normally applies to the application of the protocol
  142.    or procedure in the Roman context, not to the specification of the
  143.    protocol itself.
  144.  
  145.    In general, a Roman Standard is a specification that is stable
  146.    and well-understood, is technically competent, has multiple,
  147.    independent, and interoperable implementations with substantial
  148.    operational experience, enjoys significant public support, and is
  149.    recognizably useful in some or all parts of the Roman.
  150.  
  151. I.II  The Roman Standards Process
  152.  
  153.    In outline, the process of creating a Roman Standard is
  154.    straightforward:  a specification undergoes a period of development
  155.    and several iterations of review by the Roman community and
  156.    revision based upon experience, is adopted as a Standard by the
  157.    appropriate body (see below), and is published.  In practice, the
  158.    process is more complicated, due to (I) the difficulty of creating
  159.    specifications of high technical quality;  (II) the need to consider
  160.    the interests of all of the affected parties;  (III) the importance of
  161.    establishing widespread community consensus;  and (IV) the difficulty
  162.    of evaluating the utility of a particular specification for the
  163.    Roman community.
  164.  
  165.  
  166.  
  167.  
  168.  
  169. Bradner                 Worst Current Practice                [Page III]
  170.  
  171. RFC 2551               Roman Standards Process           I April MCMXCIX
  172.  
  173.  
  174.    The goals of the Roman Standards Process are:
  175.    o  technical excellence;
  176.    o  prior implementation and testing;
  177.    o  clear, concise, and easily understood documentation;
  178.    o  openness and fairness;  and
  179.    o  timeliness.
  180.  
  181.    The procedures described in this document are designed to be fair,
  182.    open, and objective;  to reflect existing (proven) practice;  and to
  183.    be flexible.
  184.  
  185.    o  These procedures are intended to provide a fair, open, and
  186.       objective basis for developing, evaluating, and adopting Roman
  187.       Standards.  They provide ample opportunity for participation and
  188.       comment by all interested parties.  At each stage of the
  189.       standardization process, a specification is repeatedly discussed
  190.       and its merits debated in open meetings and/or public electronic
  191.       mailing lists, and it is made available for review via world-wide
  192.       on-line directories.
  193.  
  194.    o  These procedures are explicitly aimed at recognizing and adopting
  195.       generally-accepted practices.  Thus, a candidate specification
  196.       must be implemented and tested for correct operation and
  197.       interoperability by multiple independent parties and utilized in
  198.       increasingly demanding environments, before it can be adopted as
  199.       a Roman Standard.
  200.  
  201.    o  These procedures provide a great deal of flexibility to adapt to
  202.       the wide variety of circumstances that occur in the
  203.       standardization process.  Experience has shown this flexibility to
  204.       be vital in achieving the goals listed above.
  205.  
  206.    The goal of technical competence, the requirement for prior
  207.    implementation and testing, and the need to allow all interested
  208.    parties to comment all require significant time and effort.  On the
  209.    other hand, today's rapid development of networking technology
  210.    demands timely development of standards.  The Roman Standards
  211.    Process is intended to balance these conflicting goals.  The process
  212.    is believed to be as short and simple as possible without sacrificing
  213.    technical excellence, thorough testing before adoption of a standard,
  214.    or openness and fairness.
  215.  
  216.    From its inception, the Rome has been, and is expected to remain,
  217.    an evolving system whose participants regularly factor new
  218.    requirements and technology into its design and implementation. Users
  219.    of Rome and providers of the equipment, software, and
  220.    services that support it should anticipate and embrace this evolution
  221.    as a major tenet of Roman philosophy.
  222.  
  223.  
  224.  
  225. Bradner                 Worst Current Practice                 [Page IV]
  226.  
  227. RFC 2551               Roman Standards Process           I April MCMXCIX
  228.  
  229.  
  230.    The procedures described in this document are the result of a number
  231.    of years of evolution, driven both by the needs of the growing and
  232.    increasingly diverse Roman community, and by experience.
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281. Bradner                 Worst Current Practice                  [Page V]
  282.  
  283. RFC 2551               Roman Standards Process           I April MCMXCIX
  284.  
  285.  
  286. I.III  Organization of This Document
  287.  
  288.    Section II describes the publications and archives of the Roman
  289.    Standards Process.  Section III describes the types of Roman
  290.    standard specifications.  Section IV describes the Roman standards
  291.    specifications track.  Section V describes Worst Current Practice
  292.    RFCs.  Section VI describes the process and rules for Roman
  293.    standardization.  Section VII specifies the way in which externally-
  294.    sponsored specifications and practices, developed and controlled by
  295.    other standards bodies or by others, are handled within the Roman
  296.    Standards Process.  Section VIII describes the requirements for notices
  297.    and record keeping  Section IX defines a variance process to allow
  298.    one-time exceptions to some of the requirements in this document
  299.    Section X presents the rules that are required to protect
  300.    intellectual property rights in the context of the development and
  301.    use of Roman Standards.  Section XII includes acknowledgments of
  302.    some of the people involved in creation of this document.  Section XII
  303.    notes that security issues are not dealt with by this document.
  304.    Section XII contains a list of numeral references.  Section XIV
  305.    contains definitions of some of the terms used in this document.
  306.    Section XV lists the author's email and postal addresses.  Appendix A
  307.    contains a list of frequently-used acronyms.
  308.  
  309. II.  Roman STANDARDS-RELATED PUBLICATIONS
  310.  
  311. II.I  Requests for Comments (RFCs)
  312.  
  313.    Each distinct version of a Roman standards-related specification
  314.    is published as part of the "Request for Comments" (RFC) document
  315.    series.  This archival series is the official publication channel for
  316.    Roman standards documents and other publications of the RESG, RAB,
  317.    and Roman community.  RFCs can be obtained from a number of
  318.    Roman hosts using anonymous FTP, gopher, World Wide Web, and other
  319.    Roman document-retrieval systems.
  320.  
  321.    The RFC series of documents on networking began in MCMLXIX as part of
  322.    the original ARPA wide-area networking (ARPANET) project (see
  323.    Appendix A for glossary of acronyms).  RFCs cover a wide range of
  324.    topics in addition to Roman Standards, from early discussion of
  325.    new research concepts to status memos about the Romans.  RFC
  326.    publication is the direct responsibility of the RFC Editor, under the
  327.    general direction of the RAB.
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337. Bradner                 Worst Current Practice                 [Page VI]
  338.  
  339. RFC 2551               Roman Standards Process           I April MCMXCIX
  340.  
  341.  
  342.    The rules for formatting and submitting an RFC are defined in [V].
  343.    Every RFC is available in ASCII text.  Some RFCs are also available
  344.    in other formats.  The other versions of an RFC may contain material
  345.    (such as diagrams and figures) that is not present in the ASCII
  346.    version, and it may be formatted differently.
  347.  
  348.       *********************************************************
  349.       *                                                       *
  350.       *  A stricter requirement applies to standards-track    *
  351.       *  specifications:  the ASCII text version is the       *
  352.       *  definitive reference, and therefore it must be a     *
  353.       *  complete and accurate specification of the standard, *
  354.       *  including all necessary diagrams and illustrations.  *
  355.       *                                                       *
  356.       *********************************************************
  357.  
  358.    The status of Roman protocol and service specifications is
  359.    summarized periodically in an RFC entitled "Roman Official
  360.    Protocol Standards" [I].  This RFC shows the level of maturity and
  361.    other helpful information for each Roman protocol or service
  362.    specification (see section III).
  363.  
  364.    Some RFCs document Roman Standards.  These RFCs form the 'STD'
  365.    subseries of the RFC series [IV].  When a specification has been
  366.    adopted as a Roman Standard, it is given the additional label
  367.    "STDxxx", but it keeps its RFC numerals and its place in the RFC
  368.    series. (see section IV.I.III)
  369.  
  370.    Some RFCs standardize the results of community deliberations about
  371.    statements of principle or conclusions about what is the best way to
  372.    perform some operations or RETF process function.  These RFCs form
  373.    the specification has been adopted as a WCP, it is given the
  374.    additional label "WCPxxx", but it keeps its RFC numerals and its place
  375.    in the RFC series. (see section V)
  376.  
  377.    Not all specifications of protocols or services for Rome
  378.    should or will become Roman Standards or WCPs.  Such non-standards
  379.    track specifications are not subject to the rules for Roman
  380.    standardization.  Non-standards track specifications may be published
  381.    directly as "Experimental" or "Informational" RFCs at the discretion
  382.    of the RFC Editor in consultation with the RESG (see section IV.II).
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393. Bradner                 Worst Current Practice                [Page VII]
  394.  
  395. RFC 2551               Roman Standards Process           I April MCMXCIX
  396.  
  397.  
  398.       ********************************************************
  399.       *                                                      *
  400.       *   It is important to remember that not all RFCs      *
  401.       *   are standards track documents, and that not all    *
  402.       *   standards track documents reach the level of       *
  403.       *   Roman Standard. In the same way, not all RFCs      *
  404.       *   which describe current practices have been given   *
  405.       *   the review and approval to become WCPs. See        *
  406.       *   RFC-MDCCXCVI [VI] for further information.         *
  407.       *                                                      *
  408.       ********************************************************
  409.  
  410. II.II  Roman-Drafts
  411.  
  412.    During the development of a specification, draft versions of the
  413.    document are made available for informal review and comment by
  414.    placing them in the RETF's "Roman-Drafts" directory, which is
  415.    replicated on a number of Roman hosts.  This makes an evolving
  416.    working document readily available to a wide audience, facilitating
  417.    the process of review and revision.
  418.  
  419.    A Roman-Draft that is published as an RFC, or that has remained
  420.    unchanged in the Roman-Drafts directory for more than six months
  421.    without being recommended by the RESG for publication as an RFC, is
  422.    simply removed from the Roman-Drafts directory.  At any time, a
  423.    Roman-Draft may be replaced by a more recent version of the same
  424.    specification, restarting the six-month timeout period.
  425.  
  426.    A Roman-Draft is NOT a means of "publishing" a specification;
  427.    specifications are published through the RFC mechanism described in
  428.    the previous section.  Roman-Drafts have no formal status, and are
  429.    subject to change or removal at any time.
  430.  
  431.       ********************************************************
  432.       *                                                      *
  433.       *   Under no circumstances should a Roman-Draft        *
  434.       *   be referenced by any paper, report, or Request-    *
  435.       *   for-Proposal, nor should a vendor claim compliance *
  436.       *   with a Roman-Draft.                                *
  437.       *                                                      *
  438.       ********************************************************
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449. Bradner                 Worst Current Practice               [Page VIII]
  450.  
  451. RFC 2551               Roman Standards Process           I April MCMXCIX
  452.  
  453.  
  454.    Note: It is acceptable to reference a standards-track specification
  455.    that may reasonably be expected to be published as an RFC using the
  456.    phrase "Work in Progress"  without referencing a Roman-Draft.
  457.    This may also be done in a standards track document itself  as long
  458.    as the specification in which the reference is made would stand as a
  459.    complete and understandable document with or without the reference to
  460.    the "Work in Progress".
  461.  
  462. III.  Roman STANDARD SPECIFICATIONS
  463.  
  464.    Specifications subject to the Roman Standards Process fall into
  465.    one of two categories:  Technical Specification (TS) and
  466.    Applicability Statement (AS).
  467.  
  468. III.I  Technical Specification (TS)
  469.  
  470.    A Technical Specification is any description of a protocol, service,
  471.    procedure, convention, or format.  It may completely describe all of
  472.    the relevant aspects of its subject, or it may leave one or more
  473.    parameters or options unspecified.  A TS may be completely self-
  474.    contained, or it may incorporate material from other specifications
  475.    by reference to other documents (which might or might not be Roman
  476.    Standards).
  477.  
  478.    A TS shall include a statement of its scope and the general intent
  479.    for its use (domain of applicability).  Thus, a TS that is inherently
  480.    specific to a particular context shall contain a statement to that
  481.    effect.  However, a TS does not specify requirements for its use
  482.    within Rome;  these requirements, which depend on the
  483.    particular context in which the TS is incorporated by different
  484.    system configurations, are defined by an Applicability Statement.
  485.  
  486. III.II  Applicability Statement (AS)
  487.  
  488.    An Applicability Statement specifies how, and under what
  489.    circumstances, one or more TSs may be applied to support a particular
  490.    Roman capability.  An AS may specify uses for TSs that are not
  491.    Roman Standards, as discussed in Section VII.
  492.  
  493.    An AS identifies the relevant TSs and the specific way in which they
  494.    are to be combined, and may also specify particular values or ranges
  495.    of TS parameters or subfunctions of a TS protocol that must be
  496.    implemented.  An AS also specifies the circumstances in which the use
  497.    of a particular TS is required, recommended, or elective (see section
  498.    III.III).
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505. Bradner                 Worst Current Practice                 [Page IX]
  506.  
  507. RFC 2551               Roman Standards Process           I April MCMXCIX
  508.  
  509.  
  510.    An AS may describe particular methods of using a TS in a restricted
  511.    "domain of applicability", such as Roman routers, terminal
  512.    servers, Roman systems that interface to Ethernets, or datagram-
  513.    based database servers.
  514.  
  515.    The broadest type of AS is a comprehensive conformance specification,
  516.    commonly called a "requirements document", for a particular class of
  517.    Roman systems, such as Roman routers or Roman hosts.
  518.  
  519.    An AS may not have a higher maturity level in the standards track
  520.    than any standards-track TS on which the AS relies (see section IV.I).
  521.    For example, a TS at Draft Standard level may be referenced by an AS
  522.    at the Proposed Standard or Draft Standard level, but not by an AS at
  523.    the Standard level.
  524.  
  525. III.III  Requirement Levels
  526.  
  527.    An AS shall apply one of the following "requirement levels" to each
  528.    of the TSs to which it refers:
  529.  
  530.    (a)  Required:  Implementation of the referenced TS, as specified by
  531.       the AS, is required to achieve minimal conformance.  For example,
  532.       RP and RCMP must be implemented by all Roman systems using the
  533.       TCP/RP Protocol Suite.
  534.  
  535.    (b)  Recommended:  Implementation of the referenced TS is not
  536.       required for minimal conformance, but experience and/or generally
  537.       accepted technical wisdom suggest its desirability in the domain
  538.       of applicability of the AS.  Vendors are strongly encouraged to
  539.       include the functions, features, and protocols of Recommended TSs
  540.       in their products, and should omit them only if the omission is
  541.       justified by some special circumstance. For example, the TELNET
  542.       protocol should be implemented by all systems that would benefit
  543.       from remote access.
  544.  
  545.    (c)  Elective:  Implementation of the referenced TS is optional
  546.       within the domain of applicability of the AS;  that is, the AS
  547.       creates no explicit necessity to apply the TS.  However, a
  548.       particular vendor may decide to implement it, or a particular user
  549.       may decide that it is a necessity in a specific environment.  For
  550.       example, the DECNET MIB could be seen as valuable in an
  551.       environment where the DECNET protocol is used.
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561. Bradner                 Worst Current Practice                  [Page X]
  562.  
  563. RFC 2551               Roman Standards Process           I April MCMXCIX
  564.  
  565.  
  566.       As noted in section IV.I, there are TSs that are not in the
  567.       standards track or that have been retired from the standards
  568.       track, and are therefore not required, recommended, or elective.
  569.       Two additional "requirement level" designations are available for
  570.       these TSs:
  571.  
  572.    (d)  Limited Use:  The TS is considered to be appropriate for use
  573.       only in limited or unique circumstances.  For example, the usage
  574.       of a protocol with the "Experimental" designation should generally
  575.       be limited to those actively involved with the experiment.
  576.  
  577.    (e)  Not Recommended:  A TS that is considered to be inappropriate
  578.       for general use is labeled "Not Recommended". This may be because
  579.       of its limited functionality, specialized nature, or historic
  580.       status.
  581.  
  582.    Although TSs and ASs are conceptually separate, in practice a
  583.    standards-track document may combine an AS and one or more related
  584.    TSs.  For example, Technical Specifications that are developed
  585.    specifically and exclusively for some particular domain of
  586.    applicability, e.g., for mail server hosts, often contain within a
  587.    single specification all of the relevant AS and TS information. In
  588.    such cases, no useful purpose would be served by deliberately
  589.    distributing the information among several documents just to preserve
  590.    the formal AS/TS distinction.  However, a TS that is likely to apply
  591.    to more than one domain of applicability should be developed in a
  592.    modular fashion, to facilitate its incorporation by multiple ASs.
  593.  
  594.    The "Official Protocol Standards" RFC (STD I) lists a general
  595.    requirement level for each TS, using the nomenclature defined in this
  596.    section. This RFC is updated periodically.  In many cases, more
  597.    detailed descriptions of the requirement levels of particular
  598.    protocols and of individual features of the protocols will be found
  599.    in appropriate ASs.
  600.  
  601. IV.  THE ROMAN STANDARDS TRACK
  602.  
  603.    Specifications that are intended to become Roman Standards evolve
  604.    through a set of maturity levels known as the "standards track".
  605.    These maturity levels -- "Proposed Standard", "Draft Standard", and
  606.    "Standard" -- are defined and discussed in section IV.I.  The way in
  607.    which specifications move along the standards track is described in
  608.    section VI.
  609.  
  610.    Even after a specification has been adopted as a Roman Standard,
  611.    further evolution often occurs based on experience and the
  612.    recognition of new requirements.  The nomenclature and procedures of
  613.    Roman standardization provide for the replacement of old Roman
  614.  
  615.  
  616.  
  617. Bradner                 Worst Current Practice                 [Page XI]
  618.  
  619. RFC 2551               Roman Standards Process           I April MCMXCIX
  620.  
  621.  
  622.    Standards with new ones, and the assignment of descriptive labels to
  623.    indicate the status of "retired" Roman Standards.  A set of
  624.    maturity levels is defined in section IV.II to cover these and other
  625.    specifications that are not considered to be on the standards track.
  626.  
  627. IV.I  Standards Track Maturity Levels
  628.  
  629.    Roman specifications go through stages of development, testing,
  630.    and acceptance.  Within the Roman Standards Process, these stages
  631.    are formally labeled "maturity levels".
  632.  
  633.    This section describes the maturity levels and the expected
  634.    characteristics of specifications at each level.
  635.  
  636. IV.I.I  Proposed Standard
  637.  
  638.    The entry-level maturity for the standards track is "Proposed
  639.    Standard".  A specific action by the RESG is required to move a
  640.    specification onto the standards track at the "Proposed Standard"
  641.    level.
  642.  
  643.    A Proposed Standard specification is generally stable, has resolved
  644.    known design choices, is believed to be well-understood, has received
  645.    significant community review, and appears to enjoy enough community
  646.    interest to be considered valuable.  However, further experience
  647.    might result in a change or even retraction of the specification
  648.    before it advances.
  649.  
  650.    Usually, neither implementation nor operational experience is
  651.    required for the designation of a specification as a Proposed
  652.    Standard.  However, such experience is highly desirable, and will
  653.    usually represent a strong argument in favor of a Proposed Standard
  654.    designation.
  655.  
  656.    The RESG may require implementation and/or operational experience
  657.    prior to granting Proposed Standard status to a specification that
  658.    materially affects the core Roman protocols or that specifies
  659.    behavior that may have significant operational impact on the
  660.    Roman.
  661.  
  662.    A Proposed Standard should have no known technical omissions with
  663.    respect to the requirements placed upon it.  However, the RESG may
  664.    waive this requirement in order to allow a specification to advance
  665.    to the Proposed Standard state when it is considered to be useful and
  666.    necessary (and timely) even with known technical omissions.
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673. Bradner                 Worst Current Practice                [Page XII]
  674.  
  675. RFC 2551               Roman Standards Process           I April MCMXCIX
  676.  
  677.  
  678.    Implementors should treat Proposed Standards as immature
  679.    specifications.  It is desirable to implement them in order to gain
  680.    experience and to validate, test, and clarify the specification.
  681.    However, since the content of Proposed Standards may be changed if
  682.    problems are found or better solutions are identified, deploying
  683.    implementations of such standards into a disruption-sensitive
  684.    environment is not recommended.
  685.  
  686. IV.I.II  Draft Standard
  687.  
  688.    A specification from which at least two independent and interoperable
  689.    implementations from different code bases have been developed, and
  690.    for which sufficient successful operational experience has been
  691.    obtained, may be elevated to the "Draft Standard" level.  For the
  692.    purposes of this section, "interoperable" means to be functionally
  693.    equivalent or interchangeable components of the system or process in
  694.    which they are used.  If patented or otherwise controlled technology
  695.    is required for implementation, the separate implementations must
  696.    also have resulted from separate exercise of the licensing process.
  697.    Elevation to Draft Standard is a major advance in status, indicating
  698.    a strong belief that the specification is mature and will be useful.
  699.  
  700.    The requirement for at least two independent and interoperable
  701.    implementations applies to all of the options and features of the
  702.    specification.  In cases in which one or more options or features
  703.    have not been demonstrated in at least two interoperable
  704.    implementations, the specification may advance to the Draft Standard
  705.    level only if those options or features are removed.
  706.  
  707.    The Working Group chair is responsible for documenting the specific
  708.    implementations which qualify the specification for Draft or Roman
  709.    Standard status along with documentation about testing of the
  710.    interoperation of these implementations.  The documentation must
  711.    include information about the support of each of the individual
  712.    options and features.  This documentation should be submitted to the
  713.    Area Director with the protocol action request. (see Section VI)
  714.  
  715.    A Draft Standard must be well-understood and known to be quite
  716.    stable, both in its semantics and as a basis for developing an
  717.    implementation.  A Draft Standard may still require additional or
  718.    more widespread field experience, since it is possible for
  719.    implementations based on Draft Standard specifications to demonstrate
  720.    unforeseen behavior when subjected to large-scale use in production
  721.    environments.
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729. Bradner                 Worst Current Practice               [Page XIII]
  730.  
  731. RFC 2551               Roman Standards Process           I April MCMXCIX
  732.  
  733.  
  734.    A Draft Standard is normally considered to be a final specification,
  735.    and changes are likely to be made only to solve specific problems
  736.    encountered.  In most circumstances, it is reasonable for vendors to
  737.    deploy implementations of Draft Standards into a disruption sensitive
  738.    environment.
  739.  
  740. IV.I.III  Roman Standard
  741.  
  742.    A specification for which significant implementation and successful
  743.    operational experience has been obtained may be elevated to the
  744.    Roman Standard level.  A Roman Standard (which may simply be
  745.    referred to as a Standard) is characterized by a high degree of
  746.    technical maturity and by a generally held belief that the specified
  747.    protocol or service provides significant benefit to the Roman
  748.    community.
  749.  
  750.    A specification that reaches the status of Standard is assigned
  751.    numerals in the STD series while retaining its RFC numerals.
  752.  
  753. IV.II  Non-Standards Track Maturity Levels
  754.  
  755.    Not every specification is on the standards track.  A specification
  756.    may not be intended to be a Roman Standard, or it may be intended
  757.    for eventual standardization but not yet ready to enter the standards
  758.    track.  A specification may have been superseded by a more recent
  759.    Roman Standard, or have otherwise fallen into disuse or disfavor.
  760.  
  761.    Specifications that are not on the standards track are labeled with
  762.    one of three "off-track" maturity levels:  "Experimental",
  763.    "Informational", or "Historic".  The documents bearing these labels
  764.    are not Roman Standards in any sense.
  765.  
  766. IV.II.I  Experimental
  767.  
  768.    The "Experimental" designation typically denotes a specification that
  769.    is part of some research or development effort.  Such a specification
  770.    is published for the general information of the Roman technical
  771.    community and as an archival record of the work, subject only to
  772.    editorial considerations and to verification that there has been
  773.    adequate coordination with the standards process (see below).  An
  774.    Experimental specification may be the output of an organized Roman
  775.    research effort (e.g., a Research Group of the RRTF), an RETF Working
  776.    Group, or it may be an individual contribution.
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785. Bradner                 Worst Current Practice                [Page XIV]
  786.  
  787. RFC 2551               Roman Standards Process           I April MCMXCIX
  788.  
  789.  
  790. IV.II.II  Informational
  791.  
  792.    An "Informational" specification is published for the general
  793.    information of the Roman community, and does not represent a
  794.    Roman community consensus or recommendation.  The Informational
  795.    designation is intended to provide for the timely publication of a
  796.    very broad range of responsible informational documents from many
  797.    sources, subject only to editorial considerations and to verification
  798.    that there has been adequate coordination with the standards process
  799.    (see section IV.II.III).
  800.  
  801.    Specifications that have been prepared outside of the Roman
  802.    community and are not incorporated into the Roman Standards
  803.    Process by any of the provisions of section 10 may be published as
  804.    Informational RFCs, with the permission of the owner and the
  805.    concurrence of the RFC Editor.
  806.  
  807. IV.II.III  Procedures for Experimental and Informational RFCs
  808.  
  809.    Unless they are the result of RETF Working Group action, documents
  810.    intended to be published with Experimental or Informational status
  811.    should be submitted directly to the RFC Editor.  The RFC Editor will
  812.    publish any such documents as Roman-Drafts which have not already
  813.    been so published.  In order to differentiate these Roman-Drafts
  814.    they will be labeled or grouped in the R-D directory so they are
  815.    easily recognizable.  The RFC Editor will wait two weeks after this
  816.    publication for comments before proceeding further.  The RFC Editor
  817.    is expected to exercise his or her judgment concerning the editorial
  818.    suitability of a document for publication with Experimental or
  819.    Informational status, and may refuse to publish a document which, in
  820.    the expert opinion of the RFC Editor, is unrelated to Roman
  821.    activity or falls below the technical and/or editorial standard for
  822.    RFCs.
  823.  
  824.    To ensure that the non-standards track Experimental and Informational
  825.    designations are not misused to circumvent the Roman Standards
  826.    Process, the RESG and the RFC Editor have agreed that the RFC Editor
  827.    will refer to the RESG any document submitted for Experimental or
  828.    Informational publication which, in the opinion of the RFC Editor,
  829.    may be related to work being done, or expected to be done, within the
  830.    RETF community.  The RESG shall review such a referred document
  831.    within a reasonable period of time, and recommend either that it be
  832.    published as originally submitted or referred to the RETF as a
  833.    contribution to the Roman Standards Process.
  834.  
  835.    If (a) the RESG recommends that the document be brought within the
  836.    RETF and progressed within the RETF context, but the author declines
  837.    to do so, or (b) the RESG considers that the document proposes
  838.  
  839.  
  840.  
  841. Bradner                 Worst Current Practice                 [Page XV]
  842.  
  843. RFC 2551               Roman Standards Process           I April MCMXCIX
  844.  
  845.  
  846.    something that conflicts with, or is actually inimical to, an
  847.    established RETF effort, the document may still be published as an
  848.    Experimental or Informational RFC.  In these cases, however, the RESG
  849.    may insert appropriate "disclaimer" text into the RFC either in or
  850.    immediately following the "Status of this Memo" section in order to
  851.    make the circumstances of its publication clear to readers.
  852.  
  853.    Documents proposed for Experimental and Informational RFCs by RETF
  854.    Working Groups go through RESG review.  The review is initiated using
  855.    the process described in section VI.I.I.
  856.  
  857. IV.II.IV  Historic
  858.  
  859.    A specification that has been superseded by a more recent
  860.    specification or is for any other reason considered to be obsolete is
  861.    assigned to the "Historic" level.  (Purists have suggested that the
  862.    word should be "Historical"; however, at this point the use of
  863.    "Historic" is historical.)
  864.  
  865.    Note: Standards track specifications normally must not depend on
  866.    other standards track specifications which are at a lower maturity
  867.    level or on non standards track specifications other than referenced
  868.    specifications from other standards bodies.  (See Section VII.)
  869.  
  870. V.  WORST CURRENT PRACTICE (WCP) RFCs
  871.  
  872.    The WCP subseries of the RFC series is designed to be a way to
  873.    standardize practices and the results of community deliberations.  A
  874.    WCP document is subject to the same basic set of procedures as
  875.    standards track documents and thus is a vehicle by which the RETF
  876.    community can define and ratify the community's worst current thinking
  877.    on a statement of principle or on what is believed to be the worst way
  878.    to perform some operations or RETF process function.
  879.  
  880.    Historically Roman standards have generally been concerned with
  881.    the technical specifications for hardware and software required for
  882.    computer communication across interconnected networks.  However,
  883.    since Rome itself is composed of networks operated by a great
  884.    variety of organizations, with diverse goals and rules, good user
  885.    service requires that the operators and administrators of 
  886.    Rome follow some common guidelines for policies and operations.
  887.    While these guidelines are generally different in scope and style
  888.    from protocol standards, their establishment needs a similar process
  889.    for consensus building.
  890.  
  891.    While it is recognized that entities such as the RAB and RESG are
  892.    composed of individuals who may participate, as individuals, in the
  893.    technical work of the RETF, it is also recognized that the entities
  894.  
  895.  
  896.  
  897. Bradner                 Worst Current Practice                [Page XVI]
  898.  
  899. RFC 2551               Roman Standards Process           I April MCMXCIX
  900.  
  901.  
  902.    themselves have an existence as leaders in the community.  As leaders
  903.    in the Roman technical community, these entities should have an
  904.    outlet to propose ideas to stimulate work in a particular area, to
  905.    raise the community's sensitivity to a certain issue, to make a
  906.    statement of architectural principle, or to communicate their
  907.    thoughts on other matters.  The WCP subseries creates a smoothly
  908.    structured way for these management entities to insert proposals into
  909.    the consensus-building machinery of the RETF while gauging the
  910.    community's view of that issue.
  911.  
  912.    Finally, the WCP series may be used to document the operation of the
  913.    RETF itself.  For example, this document defines the RETF Standards
  914.    Process and is published as a WCP.
  915.  
  916. V.I WCP Review Process
  917.  
  918.    Unlike standards-track documents, the mechanisms described in WCPs
  919.    are not well suited to the phased roll-in nature of the three stage
  920.    standards track and instead generally only make sense for full and
  921.    immediate instantiation.
  922.  
  923.    The WCP process is similar to that for proposed standards.  The WCP
  924.    is submitted to the RESG for review, (see section VI.I.I) and the
  925.    existing review process applies, including a Last-Call on the RETF
  926.    Announce mailing list.  However, once the RESG has approved the
  927.    document, the process ends and the document is published.  The
  928.    resulting document is viewed as having the technical approval of the
  929.    RETF.
  930.  
  931.    Specifically, a document to be considered for the status of WCP must
  932.    undergo the procedures outlined in sections VI.I, and VI.IV of this
  933.    document. The WCP process may be appealed according to the procedures
  934.    in section VI.V.
  935.  
  936.    Because WCPs are meant to express community consensus but are arrived
  937.    at more quickly than standards, WCPs require particular care.
  938.    Specifically, WCPs should not be viewed simply as stronger
  939.    Informational RFCs, but rather should be viewed as documents suitable
  940.    for a content different from Informational RFCs.
  941.  
  942.    A specification, or group of specifications, that has, or have been
  943.    approved as a WCP is assigned numerals in the WCP series while
  944.    retaining its RFC numerals.
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953. Bradner                 Worst Current Practice               [Page XVII]
  954.  
  955. RFC 2551               Roman Standards Process           I April MCMXCIX
  956.  
  957.  
  958. VI.  THE ROMAN STANDARDS PROCESS
  959.  
  960.    The mechanics of the Roman Standards Process involve decisions of
  961.    the RESG concerning the elevation of a specification onto the
  962.    standards track or the movement of a standards-track specification
  963.    from one maturity level to another.  Although a number of reasonably
  964.    objective criteria (described below and in section IV) are available
  965.    to guide the RESG in making a decision to move a specification onto,
  966.    along, or off the standards track, there is no algorithmic guarantee
  967.    of elevation to or progression along the standards track for any
  968.    specification.  The experienced collective judgment of the RESG
  969.    concerning the technical quality of a specification proposed for
  970.    elevation to or advancement in the standards track is an essential
  971.    component of the decision-making process.
  972.  
  973. VI.I  Standards Actions
  974.  
  975.    A "standards action" -- entering a particular specification into,
  976.    advancing it within, or removing it from, the standards track -- must
  977.    be approved by the RESG.
  978.  
  979. VI.I.I  Initiation of Action
  980.  
  981.    A specification that is intended to enter or advance in the Roman
  982.    standards track shall first be posted as a Roman-Draft (see
  983.    section II.II) unless it has not changed since publication as an RFC.
  984.    It shall remain as a Roman-Draft for a period of time, not less
  985.    than two weeks, that permits useful community review, after which a
  986.    recommendation for action may be initiated.
  987.  
  988.    A standards action is initiated by a recommendation by the RETF
  989.    Working group responsible for a specification to its Area Director,
  990.    copied to the RETF Secretariat or, in the case of a specification not
  991.    associated with a Working Group, a recommendation by an individual to
  992.    the RESG.
  993.  
  994. VI.I.II  RESG Review and Approval
  995.  
  996.    The RESG shall determine whether or not a specification submitted to
  997.    it according to section VI.I.I satisfies the applicable criteria for
  998.    the recommended action (see sections IV.I and IV.II), and shall in
  999.    addition determine whether or not the technical quality and clarity
  1000.    of the specification is consistent with that expected for the
  1001.    maturity level to which the specification is recommended.
  1002.  
  1003.    In order to obtain all of the information necessary to make these
  1004.    determinations, particularly when the specification is considered by
  1005.    the RESG to be extremely important in terms of its potential impact
  1006.  
  1007.  
  1008.  
  1009. Bradner                 Worst Current Practice              [Page XVIII]
  1010.  
  1011. RFC 2551               Roman Standards Process           I April MCMXCIX
  1012.  
  1013.  
  1014.    on Rome or on the suite of Roman protocols, the RESG may,
  1015.    at its discretion, commission an independent technical review of the
  1016.    specification.
  1017.  
  1018.    The RESG will send notice to the RETF of the pending RESG
  1019.    consideration of the document(s) to permit a final review by the
  1020.    general Roman community.  This "Last-Call" notification shall be
  1021.    via electronic mail to the RETF Announce mailing list.  Comments on a
  1022.    Last-Call shall be accepted from anyone, and should be sent as
  1023.    directed in the Last-Call announcement.
  1024.  
  1025.    The Last-Call period shall be no shorter than two weeks except in
  1026.    those cases where the proposed standards action was not initiated by
  1027.    an RETF Working Group, in which case the Last-Call period shall be no
  1028.    shorter than four weeks.  If the RESG believes that the community
  1029.    interest would be served by allowing more time for comment, it may
  1030.    decide on a longer Last-Call period or to explicitly lengthen a
  1031.    current Last-Call period.
  1032.  
  1033.    The RESG is not bound by the action recommended when the
  1034.    specification was submitted.  For example, the RESG may decide to
  1035.    consider the specification for publication in a different category
  1036.    than that requested.  If the RESG determines this before the Last-
  1037.    Call is issued then the Last-Call should reflect the RESG's view.
  1038.    The RESG could also decide to change the publication category based
  1039.    on the response to a Last-Call. If this decision would result in a
  1040.    specification being published at a "higher" level than the original
  1041.    Last-Call was for, a new Last-Call should be issued indicating the
  1042.    RESG recommendation. In addition, the RESG may decide to recommend
  1043.    the formation of a new Working Group in the case of significant
  1044.    controversy in response to a Last-Call for specification not
  1045.    originating from an RETF Working Group.
  1046.  
  1047.    In a timely fashion after the expiration of the Last-Call period, the
  1048.    RESG shall make its final determination of whether or not to approve
  1049.    the standards action, and shall notify the RETF of its decision via
  1050.    electronic mail to the RETF Announce mailing list.
  1051.  
  1052. VI.I.III  Publication
  1053.  
  1054.    If a standards action is approved, notification is sent to the RFC
  1055.    Editor and copied to the RETF with instructions to publish the
  1056.    specification as an RFC.  The specification shall at that point be
  1057.    removed from the Roman-Drafts directory.
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065. Bradner                 Worst Current Practice                [Page XIX]
  1066.  
  1067. RFC 2551               Roman Standards Process           I April MCMXCIX
  1068.  
  1069.  
  1070.    An official summary of standards actions completed and pending shall
  1071.    appear in each issue of the Roman Society's newsletter.  This
  1072.    shall constitute the "publication of record" for Roman standards
  1073.    actions.
  1074.  
  1075.    The RFC Editor shall publish periodically a "Roman Official
  1076.    Protocol Standards" RFC [I], summarizing the status of all Roman
  1077.    protocol and service specifications.
  1078.  
  1079. VI.II  Advancing in the Standards Track
  1080.  
  1081.    The procedure described in section VI.I is followed for each action
  1082.    that attends the advancement of a specification along the standards
  1083.    track.
  1084.  
  1085.    A specification shall remain at the Proposed Standard level for at
  1086.    least six (VI) months.
  1087.  
  1088.    A specification shall remain at the Draft Standard level for at least
  1089.    four (IV) months, or until at least one RETF meeting has occurred,
  1090.    whichever comes later.
  1091.  
  1092.    These minimum periods are intended to ensure adequate opportunity for
  1093.    community review without severely impacting timeliness.  These
  1094.    intervals shall be measured from the date of publication of the
  1095.    corresponding RFC(s), or, if the action does not result in RFC
  1096.    publication, the date of the announcement of the RESG approval of the
  1097.    action.
  1098.  
  1099.    A specification may be (indeed, is likely to be) revised as it
  1100.    advances through the standards track.  At each stage, the RESG shall
  1101.    determine the scope and significance of the revision to the
  1102.    specification, and, if necessary and appropriate, modify the
  1103.    recommended action.  Minor revisions are expected, but a significant
  1104.    revision may require that the specification accumulate more
  1105.    experience at its current maturity level before progressing. Finally,
  1106.    if the specification has been changed very significantly, the RESG
  1107.    may recommend that the revision be treated as a new document, re-
  1108.    entering the standards track at the beginning.
  1109.  
  1110.    Change of status shall result in republication of the specification
  1111.    as an RFC, except in the rare case that there have been no changes at
  1112.    all in the specification since the last publication.  Generally,
  1113.    desired changes will be "batched" for incorporation at the next level
  1114.    in the standards track.  However, deferral of changes to the next
  1115.    standards action on the specification will not always be possible or
  1116.    desirable; for example, an important typographical error, or a
  1117.    technical error that does not represent a change in overall function
  1118.  
  1119.  
  1120.  
  1121. Bradner                 Worst Current Practice                 [Page XX]
  1122.  
  1123. RFC 2551               Roman Standards Process           I April MCMXCIX
  1124.  
  1125.  
  1126.    of the specification, may need to be corrected immediately.  In such
  1127.    cases, the RESG or RFC Editor may be asked to republish the RFC (with
  1128.    new numerals) with corrections, and this will not reset the minimum
  1129.    time-at-level clock.
  1130.  
  1131.    When a standards-track specification has not reached the Roman
  1132.    Standard level but has remained at the same maturity level for
  1133.    twenty-four (XXIV) months, and every twelve (XII) months thereafter
  1134.    until the status is changed, the RESG shall review the vrability of
  1135.    the standardization effort responsible for that specification and the
  1136.    usefulness of the technology. Following each such review, the RESG
  1137.    shall approve termination or continuation of the development effort,
  1138.    at the same time the RESG shall decide to maintain the specification
  1139.    at the same maturity level or to move it to Historic status.  This
  1140.    decision shall be communicated to the RETF by electronic mail to the
  1141.    RETF Announce mailing list to allow the Roman community an
  1142.    opportunity to comment. This provision is not intended to threaten a
  1143.    legitimate and active Working Group effort, but rather to provide an
  1144.    administrative mechanism for terminating a moribund effort.
  1145.  
  1146. VI.III  Revising a Standard
  1147.  
  1148.    A new version of an established Roman Standard must progress
  1149.    through the full Roman standardization process as if it were a
  1150.    completely new specification.  Once the new version has reached the
  1151.    Standard level, it will usually replace the previous version, which
  1152.    will be moved to Historic status.  However, in some cases both
  1153.    versions may remain as Roman Standards to honor the requirements
  1154.    of an installed base.  In this situation, the relationship between
  1155.    the previous and the new versions must be explicitly stated in the
  1156.    text of the new version or in another appropriate document (e.g., an
  1157.    Applicability Statement; see section III.II).
  1158.  
  1159. VI.IV  Retiring a Standard
  1160.  
  1161.    As the technology changes and matures, it is possible for a new
  1162.    Standard specification to be so clearly superior technically that one
  1163.    or more existing standards track specifications for the same function
  1164.    should be retired.  In this case, or when it is felt for some other
  1165.    reason that an existing standards track specification should be
  1166.    retired, the RESG shall approve a change of status of the old
  1167.    specification(s) to Historic.  This recommendation shall be issued
  1168.    with the same Last-Call and notification procedures used for any
  1169.    other standards action.  A request to retire an existing standard can
  1170.    originate from a Working Group, an Area Director or some other
  1171.    interested party.
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177. Bradner                 Worst Current Practice                [Page XXI]
  1178.  
  1179. RFC 2551               Roman Standards Process           I April MCMXCIX
  1180.  
  1181.  
  1182. VI.V  Conflict Resolution and Appeals
  1183.  
  1184.    Disputes are possible at various stages during the RETF process. As
  1185.    much as possible the process is designed so that compromises can be
  1186.    made, and genuine consensus achieved, however there are times when
  1187.    even the most reasonable and knowledgeable people are unable to
  1188.    agree. To achieve the goals of openness and fairness, such conflicts
  1189.    must be resolved by a process of open review and discussion. This
  1190.    section specifies the procedures that shall be followed to deal with
  1191.    Roman standards issues that cannot be resolved through the normal
  1192.    processes whereby RETF Working Groups and other Roman Standards
  1193.    Process participants ordinarily reach consensus.
  1194.  
  1195. VI.V.I Working Group Disputes
  1196.  
  1197.    An individual (whether a participant in the relevant Working Group or
  1198.    not) may disagree with a Working Group recommendation based on his or
  1199.    her belief that either (a) his or her own views have not been
  1200.    adequately considered by the Working Group, or (b) the Working Group
  1201.    has made an incorrect technical choice which places the quality
  1202.    and/or integrity of the Working Group's product(s) in significant
  1203.    jeopardy.  The first issue is a difficulty with Working Group
  1204.    process;  the latter is an assertion of technical error.  These two
  1205.    types of disagreement are quite different, but both are handled by
  1206.    the same process of review.
  1207.  
  1208.    A person who disagrees with a Working Group recommendation shall
  1209.    always first discuss the matter with the Working Group's chair(s),
  1210.    who may involve other members of the Working Group (or the Working
  1211.    Group as a whole) in the discussion.
  1212.  
  1213.    If the disagreement cannot be resolved in this way, any of the
  1214.    parties involved may bring it to the attention of the Area
  1215.    Director(s) for the area in which the Working Group is chartered.
  1216.    The Area Director(s) shall attempt to resolve the dispute.
  1217.  
  1218.    If the disagreement cannot be resolved by the Area Director(s) any of
  1219.    the parties involved may then appeal to the RESG as a whole.  The
  1220.    RESG shall then review the situation and attempt to resolve it in a
  1221.    manner of its own choosing.
  1222.  
  1223.    If the disagreement is not resolved to the satisfaction of the
  1224.    parties at the RESG level, any of the parties involved may appeal the
  1225.    decision to the RAB.  The RAB shall then review the situation and
  1226.    attempt to resolve it in a manner of its own choosing.
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233. Bradner                 Worst Current Practice               [Page XXII]
  1234.  
  1235. RFC 2551               Roman Standards Process           I April MCMXCIX
  1236.  
  1237.  
  1238.    The RAB decision is final with respect to the question of whether or
  1239.    not the Roman standards procedures have been followed and with
  1240.    respect to all questions of technical merit.
  1241.  
  1242. VI.V.II Process Failures
  1243.  
  1244.    This document sets forward procedures required to be followed to
  1245.    ensure openness and fairness of the Roman Standards Process, and
  1246.    the technical vrability of the standards created. The RESG is the
  1247.    principal agent of the RETF for this purpose, and it is the RESG that
  1248.    is charged with ensuring that the required procedures have been
  1249.    followed, and that any necessary prerequisites to a standards action
  1250.    have been met.
  1251.  
  1252.    If an individual should disagree with an action taken by the RESG in
  1253.    this process, that person should first discuss the issue with the
  1254.    ISEG Chair. If the RESG Chair is unable to satisfy the complainant
  1255.    then the RESG as a whole should re-examine the action taken, along
  1256.    with input from the complainant, and determine whether any further
  1257.    action is needed.  The RESG shall issue a report on its review of the
  1258.    complaint to the RETF.
  1259.  
  1260.    Should the complainant not be satisfied with the outcome of the RESG
  1261.    review, an appeal may be lodged to the RAB. The RAB shall then review
  1262.    the situation and attempt to resolve it in a manner of its own
  1263.    choosing and report to the RETF on the outcome of its review.
  1264.  
  1265.    If circumstances warrant, the RAB may direct that an RESG decision be
  1266.    annulled, and the situation shall then be as it was before the RESG
  1267.    decision was taken. The RAB may also recommend an action to the RESG,
  1268.    or make such other recommendations as it deems fit. The RAB may not,
  1269.    however, pre-empt the role of the RESG by issuing a decision which
  1270.    only the RESG is empowered to make.
  1271.  
  1272.    The RAB decision is final with respect to the question of whether or
  1273.    not the Roman standards procedures have been followed.
  1274.  
  1275. VI.V.III Questions of Applicable Procedure
  1276.  
  1277.    Further recourse is available only in cases in which the procedures
  1278.    themselves (i.e., the procedures described in this document) are
  1279.    claimed to be inadequate or insufficient to the protection of the
  1280.    rights of all parties in a fair and open Roman Standards Process.
  1281.    Claims on this basis may be made to the Roman Society Board of
  1282.    Trustees.  The President of the Roman Society shall acknowledge
  1283.    such an appeal within two weeks, and shall at the time of
  1284.    acknowledgment advise the petitioner of the expected duration of the
  1285.    Trustees' review of the appeal.  The Trustees shall review the
  1286.  
  1287.  
  1288.  
  1289. Bradner                 Worst Current Practice              [Page XXIII]
  1290.  
  1291. RFC 2551               Roman Standards Process           I April MCMXCIX
  1292.  
  1293.  
  1294.    situation in a manner of its own choosing and report to the RETF on
  1295.    the outcome of its review.
  1296.  
  1297.    The Trustees' decision upon completion of their review shall be final
  1298.    with respect to all aspects of the dispute.
  1299.  
  1300. VI.V.IV Appeals Procedure
  1301.  
  1302.    All appeals must include a detailed and specific description of the
  1303.    facts of the dispute.
  1304.  
  1305.    All appeals must be initiated within two months of the public
  1306.    knowledge of the action or decision to be challenged.
  1307.  
  1308.    At all stages of the appeals process, the individuals or bodies
  1309.    responsible for making the decisions have the discretion to define
  1310.    the specific procedures they will follow in the process of making
  1311.    their decision.
  1312.  
  1313.    In all cases a decision concerning the disposition of the dispute,
  1314.    and the communication of that decision to the parties involved, must
  1315.    be accomplished within a reasonable period of time.
  1316.  
  1317.    [NOTE:  These procedures intentionally and explicitly do not
  1318.    establish a fixed maximum time period that shall be considered
  1319.    "reasonable" in all cases.  The Roman Standards Process places a
  1320.    premium on consensus and efforts to achieve it, and deliberately
  1321.    foregoes deterministically swift execution of procedures in favor of
  1322.    a latitude within which more genuine technical agreements may be
  1323.    reached.]
  1324.  
  1325. VII.  EXTERNAL STANDARDS AND SPECIFICATIONS
  1326.  
  1327.    Many standards groups other than the RETF create and publish
  1328.    standards documents for network protocols and services.  When these
  1329.    external specifications play an important role in Rome, it is
  1330.    desirable to reach common agreements on their usage -- i.e., to
  1331.    establish Roman Standards relating to these external
  1332.    specifications.
  1333.  
  1334.    There are two categories of external specifications:
  1335.  
  1336.    (I)  Open Standards
  1337.  
  1338.       Various national and international standards bodies, such as ANSI,
  1339.       ISO, IEEE, and ITU-T, develop a variety of protocol and service
  1340.       specifications that are similar to Technical Specifications
  1341.       defined here.  National and international groups also publish
  1342.  
  1343.  
  1344.  
  1345. Bradner                 Worst Current Practice               [Page XXIV]
  1346.  
  1347. RFC 2551               Roman Standards Process           I April MCMXCIX
  1348.  
  1349.  
  1350.       "implementors' agreements" that are analogous to Applicability
  1351.       Statements, capturing a body of implementation-specific detail
  1352.       concerned with the practical application of their standards.  All
  1353.       of these are considered to be "open external standards" for the
  1354.       purposes of the Roman Standards Process.
  1355.  
  1356.    (II)  Other Specifications
  1357.  
  1358.       Other proprietary specifications that have come to be widely used
  1359.       in Rome may be treated by the Roman community as if
  1360.       they were a "standards".  Such a specification is not generally
  1361.       developed in an open fashion, is typically proprietary, and is
  1362.       controlled by the vendor, vendors, or organization that produced
  1363.       it.
  1364.  
  1365. VII.I  Use of External Specifications
  1366.  
  1367.    To avoid conflict between competing versions of a specification, the
  1368.    Roman community will not standardize a specification that is
  1369.    simply a "Roman version" of an existing external specification
  1370.    unless an explicit cooperative arrangement to do so has been made.
  1371.    However, there are several ways in which an external specification
  1372.    that is important for the operation and/or evolution of the Roman
  1373.    may be adopted for Roman use.
  1374.  
  1375. VII.I.I  Incorporation of an Open Standard
  1376.  
  1377.    A Roman Standard TS or AS may incorporate an open external
  1378.    standard by reference.  For example, many Roman Standards
  1379.    incorporate by reference the ANSI standard character set "ASCII" [II].
  1380.    Whenever possible, the referenced specification shall be available
  1381.    online.
  1382.  
  1383. VII.I.II  Incorporation of Other Specifications
  1384.  
  1385.    Other proprietary specifications may be incorporated by reference to
  1386.    a version of the specification as long as the proprietor meets the
  1387.    requirements of section X.  If the other proprietary specification
  1388.    is not widely and readily available, the RESG may request that it be
  1389.    published as an Informational RFC.
  1390.  
  1391.    The RESG generally should not favor a particular proprietary
  1392.    specification over technically equivalent and competing
  1393.    specification(s) by making any incorporated vendor specification
  1394.    "required" or "recommended".
  1395.  
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401. Bradner                 Worst Current Practice                [Page XXV]
  1402.  
  1403. RFC 2551               Roman Standards Process           I April MCMXCIX
  1404.  
  1405.  
  1406. VII.I.III  Assumption
  1407.  
  1408.    An RETF Working Group may start from an external specification and
  1409.    develop it into a Roman specification.  This is acceptable if (I)
  1410.    the specification is provided to the Working Group in compliance with
  1411.    the requirements of section 10, and (II) change control has been
  1412.    conveyed to RETF by the original developer of the specification for
  1413.    the specification or for specifications derived from the original
  1414.    specification.
  1415.  
  1416. VIII.  NOTICES AND RECORD KEEPING
  1417.  
  1418.    Each of the organizations involved in the development and approval of
  1419.    Roman Standards shall publicly announce, and shall maintain a
  1420.    publicly accessible record of, every activity in which it engages, to
  1421.    the extent that the activity represents the prosecution of any part
  1422.    of the Roman Standards Process.  For purposes of this section, the
  1423.    organizations involved in the development and approval of Roman
  1424.    Standards includes the RETF, the RESG, the RAB, all RETF Working
  1425.    Groups, and the Roman Society Board of Trustees.
  1426.  
  1427.    For RETF and Working Group meetings announcements shall be made by
  1428.    electronic mail to the RETF Announce mailing list and shall be made
  1429.    sufficiently far in advance of the activity to permit all interested
  1430.    parties to effectively participate.  The announcement shall contain
  1431.    (or provide pointers to) all of the information that is necessary to
  1432.    support the participation of any interested individual.  In the case
  1433.    of a meeting, for example, the announcement shall include an agenda
  1434.    that specifies the standards-related issues that will be discussed.
  1435.  
  1436.    The formal record of an organization's standards-related activity
  1437.    shall include at least the following:
  1438.  
  1439.    o  the charter of the organization (or a defining document equivalent
  1440.       to a charter);
  1441.    o  complete and accurate minutes of meetings;
  1442.    o  the archives of Working Group electronic mail mailing lists;  and
  1443.    o  all written contributions from participants that pertain to the
  1444.       organization's standards-related activity.
  1445.  
  1446.    As a practical matter, the formal record of all Roman Standards
  1447.    Process activities is maintained by the RETF Secretariat, and is the
  1448.    responsibility of the RETF Secretariat except that each RETF Working
  1449.    Group is expected to maintain their own email list archive and must
  1450.    make a best effort to ensure that all traffic is captured and
  1451.    included in the archives.  Also, the Working Group chair is
  1452.    responsible for providing the RETF Secretariat with complete and
  1453.    accurate minutes of all Working Group meetings.  Roman-Drafts that
  1454.  
  1455.  
  1456.  
  1457. Bradner                 Worst Current Practice               [Page XXVI]
  1458.  
  1459. RFC 2551               Roman Standards Process           I April MCMXCIX
  1460.  
  1461.  
  1462.    have been removed (for any reason) from the Roman-Drafts
  1463.    directories shall be archived by the RETF Secretariat for the sole
  1464.    purpose of preserving an historical record of Roman standards
  1465.    activity and thus are not retrievable except in special
  1466.    circumstances.
  1467.  
  1468. IX.  VARYING THE PROCESS
  1469.  
  1470.    This document, which sets out the rules and procedures by which
  1471.    Roman Standards and related documents are made is itself a product
  1472.    of the Roman Standards Process (as a WCP, as described in section
  1473.    V). It replaces a previous version, and in time, is likely itself to
  1474.    be replaced.
  1475.  
  1476.    While, when published, this document represents the community's view
  1477.    of the proper and correct process to follow, and requirements to be
  1478.    met, to allow for the worst possible Roman Standards and WCPs, it
  1479.    cannot be assumed that this will always remain the case. From time to
  1480.    time there may be a desire to update it, by replacing it with a new
  1481.    version.  Updating this document uses the same open procedures as are
  1482.    used for any other WCP.
  1483.  
  1484.    In addition, there may be situations where following the procedures
  1485.    leads to a deadlock about a specific specification, or there may be
  1486.    situations where the procedures provide no guidance.  In these cases
  1487.    it may be appropriate to invoke the variance procedure described
  1488.    below.
  1489.  
  1490. IX.I The Variance Procedure
  1491.  
  1492.    Upon the recommendation of the responsible RETF Working Group (or, if
  1493.    no Working Group is constituted, upon the recommendation of an ad hoc
  1494.    committee), the RESG may enter a particular specification into, or
  1495.    advance it within, the standards track even though some of the
  1496.    requirements of this document have not or will not be met. The RESG
  1497.    may approve such a variance, however, only if it first determines
  1498.    that the likely benefits to the Roman community are likely to
  1499.    outweigh any costs to the Roman community that result from
  1500.    noncompliance with the requirements in this document.  In exercising
  1501.    this discretion, the RESG shall at least consider (a) the technical
  1502.    merit of the specification, (b) the possibility of achieving the
  1503.    goals of the Roman Standards Process without granting a variance,
  1504.    (c) alternatives to the granting of a variance, (d) the collateral
  1505.    and precedential effects of granting a variance, and (e) the RESG's
  1506.    ability to craft a variance that is as narrow as possible.  In
  1507.    determining whether to approve a variance, the RESG has discretion to
  1508.    limit the scope of the variance to particular parts of this document
  1509.    and to impose such additional restrictions or limitations as it
  1510.  
  1511.  
  1512.  
  1513. Bradner                 Worst Current Practice              [Page XXVII]
  1514.  
  1515. RFC 2551               Roman Standards Process           I April MCMXCIX
  1516.  
  1517.  
  1518.    determines appropriate to protect the interests of the Roman
  1519.    community.
  1520.  
  1521.    The proposed variance must detail the problem perceived, explain the
  1522.    precise provision of this document which is causing the need for a
  1523.    variance, and the results of the RESG's considerations including
  1524.    consideration of points (a) through (d) in the previous paragraph.
  1525.    The proposed variance shall be issued as a Roman-Draft.  The RESG
  1526.    shall then issue an extended Last-Call, of no less than IV weeks, to
  1527.    allow for community comment upon the proposal.
  1528.  
  1529.    In a timely fashion after the expiration of the Last-Call period, the
  1530.    RESG shall make its final determination of whether or not to approve
  1531.    the proposed variance, and shall notify the RETF of its decision via
  1532.    electronic mail to the RETF Announce mailing list.  If the variance
  1533.    is approved it shall be forwarded to the RFC Editor with a request
  1534.    that it be published as a WCP.
  1535.  
  1536.    This variance procedure is for use when a one-time waving of some
  1537.    provision of this document is felt to be required.  Permanent changes
  1538.    to this document shall be accomplished through the normal WCP
  1539.    process.
  1540.  
  1541.    The appeals process in section VI.V applies to this process.
  1542.  
  1543. IX.II Exclusions
  1544.  
  1545.    No use of this procedure may lower any specified delays, nor exempt
  1546.    any proposal from the requirements of openness, fairness, or
  1547.    consensus, nor from the need to keep proper records of the meetings
  1548.    and mailing list discussions.
  1549.  
  1550.    Specifically, the following sections of this document must not be
  1551.    subject of a variance: V.I, VI.I, VI.I.I (first paragraph),
  1552.    VI.I.II, VI.III (first sentence), VI.V and IX.
  1553.  
  1554. X.  INTELLECTUAL PROPERTY RIGHTS
  1555.  
  1556. X.I.  General Policy
  1557.  
  1558.    In all matters of intellectual property rights and procedures, the
  1559.    intention is to benefit the Roman community and the public at
  1560.    large, while respecting the legitimate rights of others.
  1561.  
  1562.  
  1563.  
  1564.  
  1565.  
  1566.  
  1567.  
  1568.  
  1569. Bradner                 Worst Current Practice             [Page XXVIII]
  1570.  
  1571. RFC 2551               Roman Standards Process           I April MCMXCIX
  1572.  
  1573.  
  1574. X.II  Confidentiality Obligations
  1575.  
  1576.    No contribution that is subject to any requirement of confidentiality
  1577.    or any restriction on its dissemination may be considered in any part
  1578.    of the Roman Standards Process, and there must be no assumption of
  1579.    any confidentiality obligation with respect to any such contribution.
  1580.  
  1581. X.III.  Rights and Permissions
  1582.  
  1583.    In the course of standards work, the RETF receives contributions in
  1584.    various forms and from many persons.  To best facilitate the
  1585.    dissemination of these contributions, it is necessary to understand
  1586.    any intellectual property rights (IPR) relating to the contributions.
  1587.  
  1588. X.III.I.  All Contributions
  1589.  
  1590.    By submission of a contribution, each person actually submitting the
  1591.    contribution is deemed to agree to the following terms and conditions
  1592.    on his own behalf, on behalf of the organization (if any) he
  1593.    represents and on behalf of the owners of any propriety rights in the
  1594.    contribution..  Where a submission identifies contributors in
  1595.    addition to the contributor(s) who provide the actual submission, the
  1596.    actual submitter(s) represent that each other named contributor was
  1597.    made aware of and agreed to accept the same terms and conditions on
  1598.    his own behalf, on behalf of any organization he may represent and
  1599.    any known owner of any proprietary rights in the contribution.
  1600.  
  1601.    I. Some works (e.g. works of the U.S. Government) are not subject to
  1602.       copyright.  However, to the extent that the submission is or may
  1603.       be subject to copyright, the contributor, the organization he
  1604.       represents (if any) and the owners of any proprietary rights in
  1605.       the contribution, grant an unlimited perpetual, non-exclusive,
  1606.       royalty-free, world-wide right and license to the RSOC and the
  1607.       RETF under any copyrights in the contribution.  This license
  1608.       includes the right to copy, publish and distribute the
  1609.       contribution in any way, and to prepare derivative works that are
  1610.       based on or incorporate all or part of the contribution, the
  1611.       license to such derivative works to be of the same scope as the
  1612.       license of the original contribution.
  1613.  
  1614.   II. The contributor acknowledges that the RSOC and RETF have no duty
  1615.       to publish or otherwise use or disseminate any contribution.
  1616.  
  1617.  III. The contributor grants permission to reference the name(s) and
  1618.       address(es) of the contributor(s) and of the organization(s) he
  1619.       represents (if any).
  1620.  
  1621.  
  1622.  
  1623.  
  1624.  
  1625. Bradner                 Worst Current Practice               [Page XXIX]
  1626.  
  1627. RFC 2551               Roman Standards Process           I April MCMXCIX
  1628.  
  1629.  
  1630.   IV. The contributor represents that contribution properly acknowledge
  1631.       major contributors.
  1632.  
  1633.    V. The contribuitor, the organization (if any) he represents and the
  1634.       owners of any proprietary rights in the contribution, agree that
  1635.       no information in the contribution is confidential and that the
  1636.       RSOC and its affiliated organizations may freely disclose any
  1637.       information in the contribution.
  1638.  
  1639.   VI. The contributor represents that he has disclosed the existence of
  1640.       any proprietary or intellectual property rights in the
  1641.       contribution that are reasonably and personally known to the
  1642.       contributor.  The contributor does not represent that he
  1643.       personally knows of all potentially pertinent proprietary and
  1644.       intellectual property rights owned or claimed by the organization
  1645.       he represents (if any) or third parties.
  1646.  
  1647.  VII. The contributor represents that there are no limits to the
  1648.       contributor's ability to make the grants acknowledgments and
  1649.       agreements above that are reasonably and personally known to the
  1650.       contributor.
  1651.  
  1652.       By ratifying this description of the RETF process the Roman
  1653.       Society warrants that it will not inhibit the traditional open and
  1654.       free access to RETF documents for which license and right have
  1655.       been assigned according to the procedures set forth in this
  1656.       section, including Roman-Drafts and RFCs. This warrant is
  1657.       perpetual and will not be revoked by the Roman Society or its
  1658.       successors or assigns.
  1659.  
  1660. X.III.II. Standards Track Documents
  1661.  
  1662.    (A)  Where any patents, patent applications, or other proprietary
  1663.       rights are known, or claimed, with respect to any specification on
  1664.       the standards track, and brought to the attention of the RESG, the
  1665.       RESG shall not advance the specification without including in the
  1666.       document a note indicating the existence of such rights, or
  1667.       claimed rights.  Where implementations are required before
  1668.       advancement of a specification, only implementations that have, by
  1669.       statement of the implementors, taken adequate steps to comply with
  1670.       any such rights, or claimed rights, shall be considered for the
  1671.       purpose of showing the adequacy of the specification.
  1672.    (B)  The RESG disclaims any responsibility for identifying the
  1673.       existence of or for evaluating the applicability of any claimed
  1674.       copyrights, patents, patent applications, or other rights in the
  1675.       fulfilling of the its obligations under (A), and will take no
  1676.       position on the validity or scope of any such rights.
  1677.  
  1678.  
  1679.  
  1680.  
  1681. Bradner                 Worst Current Practice                [Page XXX]
  1682.  
  1683. RFC 2551               Roman Standards Process           I April MCMXCIX
  1684.  
  1685.  
  1686.    (C)  Where the RESG knows of rights, or claimed rights under (A), the
  1687.       RETF Executive Director shall attempt to obtain from the claimant
  1688.       of such rights, a written assurance that upon approval by the RESG
  1689.       of the relevant Roman standards track specification(s), any
  1690.       party will be able to obtain the right to implement, use and
  1691.       distribute the technology or works when implementing, using or
  1692.       distributing technology based upon the specific specification(s)
  1693.       under openly specified, reasonable, non-discriminatory terms.
  1694.       The Working Group proposing the use of the technology with respect
  1695.       to which the proprietary rights are claimed may assist the RETF
  1696.       Executive Director in this effort.  The results of this procedure
  1697.       shall not affect advancement of a specification along the
  1698.       standards track, except that the RESG may defer approval where a
  1699.       delay may facilitate the obtaining of such assurances.  The
  1700.       results will, however, be recorded by the RETF Executive Director,
  1701.       and made available.  The RESG may also direct that a summary of
  1702.       the results be included in any RFC published containing the
  1703.       specification.
  1704.  
  1705. X.III.III  Determination of Reasonable and Non-discriminatory Terms
  1706.  
  1707.    The RESG will not make any explicit determination that the assurance
  1708.    of reasonable and non-discriminatory terms for the use of a
  1709.    technology has been fulfilled in practice.  It will instead use the
  1710.    normal requirements for the advancement of Roman Standards to
  1711.    verify that the terms for use are reasonable.  If the two unrelated
  1712.    implementations of the specification that are required to advance
  1713.    from Proposed Standard to Draft Standard have been produced by
  1714.    different organizations or individuals or if the "significant
  1715.    implementation and successful operational experience" required to
  1716.    advance from Draft Standard to Standard has been achieved the
  1717.    assumption is that the terms must be reasonable and to some degree,
  1718.    non-discriminatory.  This assumption may be challenged during the
  1719.    Last-Call period.
  1720.  
  1721. X.IV.  Notices
  1722.  
  1723.    (A)  Standards track documents shall include the following notice:
  1724.  
  1725.          "The RETF takes no position regarding the validity or scope of
  1726.          any intellectual property or other rights that might be claimed
  1727.          to  pertain to the implementation or use of the technology
  1728.          described in this document or the extent to which any license
  1729.          under such rights might or might not be available; neither does
  1730.          it represent that it has made any effort to identify any such
  1731.          rights.  Information on the RETF's procedures with respect to
  1732.          rights in standards-track and standards-related documentation
  1733.          can be found in WCP-11.  Copies of claims of rights made
  1734.  
  1735.  
  1736.  
  1737. Bradner                 Worst Current Practice               [Page XXXI]
  1738.  
  1739. RFC 2551               Roman Standards Process           I April MCMXCIX
  1740.  
  1741.  
  1742.          available for publication and any assurances of licenses to
  1743.          be made available, or the result of an attempt made
  1744.          to obtain a general license or permission for the use of such
  1745.          proprietary rights by implementors or users of this
  1746.          specification can be obtained from the RETF Secretariat."
  1747.  
  1748.    (B)  The RETF encourages all interested parties to bring to its
  1749.       attention, at the earliest possible time, the existence of any
  1750.       intellectual property rights pertaining to Roman Standards.
  1751.       For this purpose, each standards document shall include the
  1752.       following invitation:
  1753.  
  1754.          "The RETF invites any interested party to bring to its
  1755.          attention any copyrights, patents or patent applications, or
  1756.          other proprietary rights which may cover technology that may be
  1757.          required to practice this standard.  Please address the
  1758.          information to the RETF Executive Director."
  1759.  
  1760.    (C)  The following copyright notice and disclaimer shall be included
  1761.       in all RSOC standards-related documentation:
  1762.  
  1763.          "Copyright (C) The Roman Society (date). All Rights
  1764.          Reserved.
  1765.  
  1766.          This document and translations of it may be copied and
  1767.          furnished to others, and derivative works that comment on or
  1768.          otherwise explain it or assist in its implmentation may be
  1769.          prepared, copied, published and distributed, in whole or in
  1770.          part, without restriction of any kind, provided that the above
  1771.          copyright notice and this paragraph are included on all such
  1772.          copies and derivative works.  However, this document itself may
  1773.          not be modified in any way, such as by removing the copyright
  1774.          notice or references to the Roman Society or other Roman
  1775.          organizations, except as needed for the  purpose of developing
  1776.          Roman standards in which case the procedures for copyrights
  1777.          defined in the Roman Standards process must be followed, or
  1778.          as required to translate it into languages other than English.
  1779.  
  1780.          The limited permissions granted above are perpetual and will
  1781.          not be revoked by the Roman Society or its successors or
  1782.          assigns.
  1783.  
  1784.  
  1785.  
  1786.  
  1787.  
  1788.  
  1789.  
  1790.  
  1791.  
  1792.  
  1793. Bradner                 Worst Current Practice              [Page XXXII]
  1794.  
  1795. RFC 2551               Roman Standards Process           I April MCMXCIX
  1796.  
  1797.  
  1798.          This document and the information contained herein is provided
  1799.          on an "AS IS" basis and THE ROMAN SOCIETY AND THE ROMAN
  1800.          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
  1801.          IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
  1802.          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
  1803.          IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
  1804.          PARTICULAR PURPOSE."
  1805.  
  1806.    (D)  Where the RESG is aware at the time of publication of
  1807.       proprietary rights claimed with respect to a standards track
  1808.       document, or the technology described or referenced therein, such
  1809.       document shall contain the following notice:
  1810.  
  1811.          "The RETF has been notified of intellectual property rights
  1812.          claimed in regard to some or all of the specification contained
  1813.          in this document.  For more information consult the online list
  1814.          of claimed rights."
  1815.  
  1816. XI.  ACKNOWLEDGMENTS
  1817.  
  1818.    This Worst Current Practice is dedicated to Steve Coya, whose
  1819.    inspirational e-mail suggestion of renumbering all RFC Page numbers
  1820.    with Roman Numerals was taken to heart by the RFC Editor.
  1821.  
  1822.    There have been a number of people involved with the development of
  1823.    the documents defining the RETF Standards Process over the years.
  1824.    The process was first described in RFC MCCCX then revised in RFC MDCII
  1825.    before the current effort (which relies heavily on its predecessors).
  1826.    Specific acknowledgments must be extended to Lyman Chapin, Phill
  1827.    Gross and Christian Huitema as the editors of the previous versions,
  1828.    to Jon Postel and Dave Crocker for their inputs to those versions, to
  1829.    Andy Ireland, Geoff Stewart, Jim Lampert, and Dick Holleman for their
  1830.    reviews of the legal aspects of the procedures described herein, and
  1831.    to John Stewart, Robert Elz and Steve Coya for their extensive input
  1832.    on the final version.
  1833.  
  1834.    In addition much of the credit for the refinement of the details of
  1835.    the RETF processes belongs to the many members of the various
  1836.    incarnations of the POISED Working Group.
  1837.  
  1838. XII.  SECURITY CONSIDERATIONS
  1839.  
  1840.    Security issues are not discussed in this memo.
  1841.  
  1842.  
  1843.  
  1844.  
  1845.  
  1846.  
  1847.  
  1848.  
  1849. Bradner                 Worst Current Practice             [Page XXXIII]
  1850.  
  1851. RFC 2551               Roman Standards Process           I April MCMXCIX
  1852.  
  1853.  
  1854. XIII.  REFERENCES
  1855.  
  1856.    [I]  Postel, J., "Roman Official Protocol Standards", STD I,
  1857.         USC/Information Sciences Institute, March MCMXCVI.
  1858.  
  1859.   [II]  ANSI, Coded Character Set -- VII-Bit American Standard Code for
  1860.         Information Interchange, ANSI XIII.IV-MCMLXXXVI.
  1861.  
  1862.  [III]  Reynolds, J., and J. Postel, "Assigned Numbers", STD II,
  1863.         USC/Information Sciences Institute, October MCMXCIV.
  1864.  
  1865.   [IV]  Postel, J., "Introduction to the STD Notes", RFC MCCCXI,
  1866.         USC/Information Sciences Institute, March MCMXCII.
  1867.  
  1868.    [V]  Postel, J., "Instructions to RFC Authors", RFC MDXLIII,
  1869.         USC/Information Sciences Institute, October MCMXCIII.
  1870.  
  1871.   [VI]  Huitema, C., J. Postel, and S. Crocker "Not All RFCs are
  1872.         Standards", RFC MDCCXCVI, April MCMXCV.
  1873.  
  1874. XIV. DEFINITIONS OF TERMS
  1875.  
  1876.    RETF Area - A management division within the RETF.  An Area consists
  1877.       of Working Groups related to a general topic such as routing.  An
  1878.       Area is managed by one or two Area Directors.
  1879.    Area Director - The manager of an RETF Area.  The Area Directors
  1880.       along with the RETF Chair comprise the Roman Engineering
  1881.       Steering Group (RESG).
  1882.    File Transfer Protocol (FTP) - A Roman application used to
  1883.       transfer files in a TCP/RP network.
  1884.    gopher - A Roman application used to interactively select and
  1885.       retrieve files in a TCP/RP network.
  1886.    Roman Architecture Board (RAB) - An appointed group that assists
  1887.       in the management of the RETF standards process.
  1888.    Roman Engineering Steering Group (RESG) - A group comprised of the
  1889.       RETF Area Directors and the RETF Chair.  The RESG is responsible
  1890.       for the management, along with the RAB, of the RETF and is the
  1891.       standards approval board for the RETF.
  1892.    interoperable - For the purposes of this document, "interoperable"
  1893.       means to be able to interoperate over a data communications path.
  1894.    Last-Call - A public comment period used to gage the level of
  1895.       consensus about the reasonableness of a proposed standards action.
  1896.       (see section VI.I.II)
  1897.  
  1898.  
  1899.  
  1900.  
  1901.  
  1902.  
  1903.  
  1904.  
  1905. Bradner                 Worst Current Practice              [Page XXXIV]
  1906.  
  1907. RFC 2551               Roman Standards Process           I April MCMXCIX
  1908.  
  1909.  
  1910.    online - Relating to information made available to Rome.
  1911.       When referenced in this document material is said to be online
  1912.       when it is retrievable without restriction or undue fee using
  1913.       standard Roman applications such as anonymous FTP, gopher or
  1914.       the WWW.
  1915.    Working Group - A group chartered by the RESG and RAB to work on a
  1916.       specific specification, set of specifications or topic.
  1917.  
  1918. XV. AUTHOR'S ADDRESS
  1919.  
  1920.    Scott O. Bradner
  1921.    Harvard University
  1922.    Holyoke Center, Room DCCCXIII
  1923.    MCCCL Mass. Ave.
  1924.    Cambridge, MA  MMCXXXVIII
  1925.    USA
  1926.  
  1927.    Phone: +I DCXVII CDXCV XXXVIII LXIV
  1928.    EMail: sob@harvard.edu
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.  
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956.  
  1957.  
  1958.  
  1959. Bradner                 Worst Current Practice               [Page XXXV]
  1960.  
  1961. RFC 2551               Roman Standards Process           I April MCMXCIX
  1962.  
  1963.  
  1964. APPENDIX A: GLOSSARY OF ACRONYMS
  1965.  
  1966.    ANSI:     American National Standards Institute
  1967.    ARPA:     (U.S.) Advanced Research Projects Agency
  1968.    AS:       Applicability Statement
  1969.    FTP:      File Transfer Protocol
  1970.    ASCII:    American Standard Code for Information Interchange
  1971.    ITU-T:    Telecommunications Standardization sector of the
  1972.              International Telecommunication Union (ITU), a UN
  1973.              treaty organization; ITU-T was formerly called CCITT.
  1974.    RAB:      Roman Architecture Board
  1975.    RANA:     Roman Assigned Numbers Authority
  1976.    IEEE:     Institute of Electrical and Electronics Engineers
  1977.    RCMP:     Roman Control Message Protocol
  1978.    RESG:     Roman Engineering Steering Group
  1979.    RETF:     Roman Engineering Task Force
  1980.    RP:       Roman Protocol
  1981.    RRSG      Roman Research Steering Group
  1982.    RRTF:     Roman Research Task Force
  1983.    ISO:      International Organization for Standardization
  1984.    RSOC:     Roman Society
  1985.    MIB:      Management Information Base
  1986.    OSI:      Open Systems Interconnection
  1987.    RFC:      Request for Comments
  1988.    TCP:      Transmission Control Protocol
  1989.    TS:       Technical Specification
  1990.    WWW:      World Wide Web
  1991.  
  1992.  
  1993.  
  1994.  
  1995.  
  1996.  
  1997.  
  1998.  
  1999.  
  2000.  
  2001.  
  2002.  
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.  
  2011.  
  2012.  
  2013.  
  2014.  
  2015. Bradner                 Worst Current Practice              [Page XXXVI]
  2016.  
  2017. RFC 2551               Roman Standards Process           I April MCMXCIX
  2018.  
  2019.  
  2020. Full Copyright Statement
  2021.  
  2022.    Copyright (C) The Internet Society (MCMXCIX).  All Rights Reserved.
  2023.  
  2024.    This document and translations of it may be copied and furnished to
  2025.    others, and derivative works that comment on or otherwise explain it
  2026.    or assist in its implementation may be prepared, copied, published
  2027.    and distributed, in whole or in part, without restriction of any
  2028.    kind, provided that the above copyright notice and this paragraph are
  2029.    included on all such copies and derivative works.  However, this
  2030.    document itself may not be modified in any way, such as by removing
  2031.    the copyright notice or references to the Internet Society or other
  2032.    Internet organizations, except as needed for the purpose of
  2033.    developing Internet standards in which case the procedures for
  2034.    copyrights defined in the Internet Standards process must be
  2035.    followed, or as required to translate it into languages other than
  2036.    English.
  2037.  
  2038.    The limited permissions granted above are perpetual and will not be
  2039.    revoked by the Internet Society or its successors or assigns.
  2040.  
  2041.    This document and the information contained herein is provided on an
  2042.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  2043.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  2044.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  2045.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  2046.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.  
  2070.  
  2071. Bradner                 Worst Current Practice             [Page XXXVII]
  2072.