home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1300s / rfc1310.txt < prev    next >
Text File  |  1992-03-12  |  55KB  |  1,291 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                          Internet Activities Board
  8. Request for Comments: 1310                           Lyman Chapin, Chair
  9.                                                               March 1992
  10.  
  11.  
  12.                      The Internet Standards Process
  13.  
  14. Status of this Memo
  15.  
  16.    This informational memo presents the current procedures for creating
  17.    and documenting Internet Standards.  Distribution of this memo is
  18.    unlimited.
  19.  
  20. TABLE OF CONTENTS
  21.  
  22.    1.  INTRODUCTION .................................................  2
  23.       1.1. Internet Standards .......................................  2
  24.       1.2. Organization .............................................  3
  25.    2.  THE INTERNET STANDARDS PROCESS ...............................  4
  26.       2.1. Introduction .............................................  4
  27.       2.2. The Internet Standards Track .............................  5
  28.       2.3. Requests for Comments (RFCs) .............................  5
  29.       2.4. Internet Drafts ..........................................  6
  30.       2.5. Internet Assigned Number Authority (IANA) ................  7
  31.       2.6. Review and Approval ......................................  8
  32.       2.7. Entering the Standards Track .............................  9
  33.       2.8. Advancing in the Standards Track .........................  9
  34.       2.9. Revising a Standard ...................................... 10
  35.    3.  NOMENCLATURE ................................................. 10
  36.       3.1  Types of Specifications .................................. 10
  37.       3.2  Standards Track Maturity Levels .......................... 12
  38.       3.3  Non-Standards Track Maturity Levels ...................... 13
  39.       3.4  Requirement Levels ....................................... 14
  40.    4.  EXTERNAL STANDARDS AND SPECIFICATIONS ........................ 15
  41.    5.  INTELLECTUAL PROPERTY RIGHTS ................................. 17
  42.    6.  PATENT POLICY ................................................ 17
  43.       6.1  Statement from Patent Holder ............................. 18
  44.       6.2  Record of Statement ...................................... 18
  45.       6.3  Notice ................................................... 18
  46.       6.4  Identifying Patents ...................................... 19
  47.    7.  ACKNOWLEDGMENTS AND REFERENCES ............................... 19
  48.    APPENDIX A: GLOSSARY ............................................. 20
  49.    APPENDIX B: UNRESOLVED ISSUES .................................... 21
  50.    Security Considerations .......................................... 23
  51.    Author's Address ................................................. 23
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. IAB                                                             [Page 1]
  59.  
  60. RFC 1310               Internet Standards Process             March 1992
  61.  
  62.  
  63. 1.  INTRODUCTION
  64.  
  65.    1.1  Internet Standards
  66.  
  67.       This memo documents the process currently used for the
  68.       standardization of Internet protocols and procedures.
  69.  
  70.       The Internet, a loosely-organized international collaboration of
  71.       autonomous, interconnected networks, supports host-to-host
  72.       communication through voluntary adherence to open protocols and
  73.       procedures defined by Internet Standards.  There are also many
  74.       isolated internets, i.e., sets of interconnected networks, that
  75.       are not connected to the Internet but use the Internet Standards.
  76.       The architecture and technical specifications of the Internet are
  77.       the result of numerous research and development activities
  78.       conducted over a period of two decades, performed by the network
  79.       R&D community, by service and equipment vendors, and by government
  80.       agencies around the world.
  81.  
  82.       In general, an Internet Standard is a specification that is stable
  83.       and well-understood, is technically competent, has multiple,
  84.       independent, and interoperable implementations with operational
  85.       experience, enjoys significant public support, and is recognizably
  86.       useful in some or all parts of the Internet.
  87.  
  88.       The principal set of Internet Standards is commonly known as the
  89.       "TCP/IP protocol suite".  As the Internet evolves, new protocols
  90.       and services, in particular those for Open Systems Interconnection
  91.       (OSI), have been and will be deployed in traditional TCP/IP
  92.       environments, leading to an Internet that supports multiple
  93.       protocol suites.  This document concerns all protocols,
  94.       procedures, and conventions used in the Internet, not just the
  95.       TCP/IP protocols.
  96.  
  97.       In outline, the process of creating an Internet Standard is
  98.       straightforward: a specification undergoes a period of development
  99.       and several iterations of review by the Internet community and
  100.       perhaps revision based upon experience, is adopted as a Standard
  101.       by the appropriate body (see below), and is published.
  102.  
  103.       In practice, the process is somewhat more complicated, due to (1)
  104.       the number and type of possible sources for specifications; (2)
  105.       the need to prepare and revise a specification in a manner that
  106.       preserves the interests of all of the affected parties;  (3) the
  107.       importance of establishing widespread community agreement on its
  108.       technical content; and (4) the difficulty of evaluating the
  109.       utility of a particular specification for the Internet community.
  110.  
  111.  
  112.  
  113.  
  114. IAB                                                             [Page 2]
  115.  
  116. RFC 1310               Internet Standards Process             March 1992
  117.  
  118.  
  119.       Some specifications that are candidates for Internet
  120.       standardization are the result of organized efforts directly
  121.       within the Internet community; others are the result of work that
  122.       was not originally organized as an Internet effort, but which was
  123.       later adopted by the Internet community.
  124.  
  125.       From its inception, the Internet has been, and is expected to
  126.       remain, an evolving system whose participants regularly factor new
  127.       requirements and technology into the design and implementation of
  128.       the global Internet.  Users of the Internet and providers of the
  129.       equipment, software, and services that support it should
  130.       anticipate and embrace this adaptability as a major tenet of
  131.       Internet philosophy.
  132.  
  133.       The procedures described in this document are the result of three
  134.       years of evolution, driven both by the needs of the growing and
  135.       increasingly diverse Internet community, and by experience.
  136.       Comments and suggestions are invited for improvement in these
  137.       procedures.
  138.  
  139.    1.2  Organization
  140.  
  141.       The Internet Activities Board (IAB) is the primary coordinating
  142.       committee for Internet design, engineering, and management [1].
  143.       The IAB has delegated to its Internet Engineering Task Force
  144.       (IETF) the primary responsibility for the development and review
  145.       of potential Internet Standards from all sources.  The IETF forms
  146.       Working Groups to pursue specific technical issues, frequently
  147.       resulting in the development of one or more specifications that
  148.       are proposed for adoption as Internet Standards.
  149.  
  150.       Final decisions on Internet standardization are made by the IAB,
  151.       based upon recommendations from the Internet Engineering Steering
  152.       Group (IESG), the leadership body of the IETF.  IETF Working
  153.       Groups are organized into areas, and each area is coordinated by
  154.       an Area Director.  The Area Directors and the IETF Chairman are
  155.       included in the IESG.
  156.  
  157.       Any member of the Internet community with the time and interest is
  158.       urged to attend IETF meetings and to participate actively in one
  159.       or more IETF Working Groups.  Participation is by individual
  160.       technical contributors, rather than formal representatives of
  161.       organizations.  The process works because the IETF Working Groups
  162.       display a spirit of cooperation as well as a high degree of
  163.       technical maturity; most IETF members agree that the greatest
  164.       benefit for all members of the Internet community results from
  165.       cooperative development of technically superior protocols and
  166.       services.
  167.  
  168.  
  169.  
  170. IAB                                                             [Page 3]
  171.  
  172. RFC 1310               Internet Standards Process             March 1992
  173.  
  174.  
  175.       A second body under the IAB, the Internet Research Task Force
  176.       (IRTF), investigates topics considered to be too uncertain, too
  177.       advanced, or insufficiently well-understood to be the subject of
  178.       Internet standardization.  When an IRTF activity generates a
  179.       specification that is sufficiently stable to be considered for
  180.       Internet standardization, it is processed through the IETF.
  181.  
  182.       Section 2 of this document describes the process and rules for
  183.       Internet standardization.  Section 3 presents the nomenclature for
  184.       different kinds and levels of Internet standard technical
  185.       specifications and their applicability.  Section 4 defines how
  186.       relevant externally-sponsored specifications and practices that
  187.       are developed and controlled by other bodies or by vendors are
  188.       handled in the Internet standardization process.  Section 5
  189.       presents the requirement for prior disclosure of the existence of
  190.       intellectual property rights.  Section 6 describes the rules for
  191.       Internet Standards that involve patents.
  192.  
  193. 2.  THE INTERNET STANDARDS PROCESS
  194.  
  195.    2.1. Introduction
  196.  
  197.       The procedures described in this document are intended to provide
  198.       a clear, open, and objective basis for developing, evaluating, and
  199.       adopting Internet Standards for protocols and services.  The
  200.       procedures provide ample opportunity for participation and comment
  201.       by all interested parties.  Before an Internet Standard is
  202.       adopted, it is repeatedly discussed (and perhaps debated) in open
  203.       open meetings and/or public electronic mailing lists, and it is
  204.       available for review via world-wide on-line directories.
  205.  
  206.       These procedures are explicitly aimed at developing and adopting
  207.       generally-accepted practices.  Thus, a candidate for Internet
  208.       standardization is implemented and tested for correct operation
  209.       and interoperability by multiple, independent parties, and
  210.       utilized in increasingly demanding environments, before it can be
  211.       adopted as an Internet Standard.
  212.  
  213.       The procedures that are described here provide a great deal of
  214.       flexibility to adapt to the wide variety of circumstances that
  215.       occur in the Internet standardization process.  Experience has
  216.       shown this flexibility to be vital in achieving the following
  217.       goals for Internet standardization:
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. IAB                                                             [Page 4]
  227.  
  228. RFC 1310               Internet Standards Process             March 1992
  229.  
  230.  
  231.  
  232.       *    high quality,
  233.  
  234.       *    prior implementation and testing,
  235.  
  236.       *    openness and fairness, and
  237.  
  238.       *    timeliness.
  239.  
  240.    2.2.  The Internet Standards Track
  241.  
  242.       Specifications that are destined to become Internet Standards
  243.       evolve through a set of maturity levels known as the "standards
  244.       track".  These maturity levels -- "Proposed Standard", "Draft
  245.       Standard", and "Standard" -- are defined and discussed below in
  246.       Section 3.2.
  247.  
  248.       Even after a specification has been adopted as an Internet
  249.       Standard, further evolution often occurs based on experience and
  250.       the recognition of new requirements.  The nomenclature and
  251.       procedures of Internet standardization provide for the replacement
  252.       of old Internet Standards with new ones, and the assignment of
  253.       descriptive labels to indicate the status of "retired" Internet
  254.       Standards.  A set of maturity levels is defined in Section 3.3 to
  255.       cover these and other "off-track" specifications.
  256.  
  257.    2.3.  Requests for Comments (RFCs)
  258.  
  259.       Each distinct version of a specification is published as part of
  260.       the "Request for Comments" (RFC) document series.
  261.  
  262.       RFCs form a series of publications of networking technical
  263.       documents, begun in 1969 as part of the original DARPA wide-area
  264.       networking (ARPANET) project (see Appendix A for glossary of
  265.       acronyms).  RFCs cover a wide range of topics, from early
  266.       discussion of new research concepts to status memos about the
  267.       Internet.  The IAB views the RFC publication process to be
  268.       sufficiently important to warrant including the RFC Editor in the
  269.       IAB membership.
  270.  
  271.       The status of specifications on the Internet standards track is
  272.       summarized periodically in a summary RFC entitled "IAB Official
  273.       Protocol Standards" [2].  This RFC shows the level of maturity and
  274.       other helpful information for each Internet protocol or service
  275.       specification.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. IAB                                                             [Page 5]
  283.  
  284. RFC 1310               Internet Standards Process             March 1992
  285.  
  286.  
  287.              ********************************************************
  288.              *   The "IAB Official Protocol Standards" RFC is the   *
  289.              *   authoritative statement of the status of any       *
  290.              *   particular Internet specification,                 *
  291.              ********************************************************
  292.  
  293.       and it is the "Publication of Record" with respect to Internet
  294.       standardization.
  295.  
  296.       The STD documents form a subseries of the RFC series.  When a
  297.       specification has been adopted as a Standard, its RFC is labeled
  298.       with a STDxxx number [9] in addition to its RFC number.
  299.  
  300.       Not all specifications of protocols or services for the Internet
  301.       should or will become Internet Standards.  Such non-standards
  302.       track specifications are not subject to the rules for Internet
  303.       standardization; generally, they will be published directly as
  304.       RFCs at the discretion of the RFC editor.  These RFCs will be
  305.       marked as "Experimental" or "Informational" (see section 3.3).
  306.  
  307.              ********************************************************
  308.              *   It is important to remember that not all RFCs      *
  309.              *   are standards track documents, and that not all    *
  310.              *   standards track documents reach the level of       *
  311.              *   Standard.                                          *
  312.              ********************************************************
  313.  
  314.    2.4.  Internet Drafts
  315.  
  316.       During the development of a specification, draft versions of the
  317.       document are made available for informal review and comment by
  318.       placing them in the IETF's "Internet Drafts" directory, which is
  319.       replicated on a number of Internet hosts.  This makes an evolving
  320.       working document readily available to a wide audience,
  321.       facilitating the process of review and revision.
  322.  
  323.       After completion to the satisfaction of its author and the
  324.       cognizant Working Group, a document that is expected to enter or
  325.       advance in the Internet standardization process shall be made
  326.       available as an Internet Draft.  It shall remain as an Internet
  327.       Draft for a period of time that permits useful community review,
  328.       at least two weeks, before submission to the IESG.
  329.  
  330.       An Internet Draft that is published as an RFC is removed from the
  331.       Internet Draft directory.  A document that has remained unchanged
  332.       in the Internet Drafts directory for more than six months without
  333.       being recommended by the IESG for publication as an RFC is simply
  334.       removed from the Internet Draft directory.  At any time, an
  335.  
  336.  
  337.  
  338. IAB                                                             [Page 6]
  339.  
  340. RFC 1310               Internet Standards Process             March 1992
  341.  
  342.  
  343.       Internet Draft may be replace by a more recent version of the same
  344.       specification, restarting the six-month timeout period.
  345.  
  346.       An Internet Draft is NOT a means of "publishing" a specification;
  347.       specifications are published through the RFC mechanism described
  348.       in the next section.  Internet Drafts have no formal status, and
  349.       are not part of the permanent archival record of Internet
  350.       activity, and they are subject to change or removal at any time.
  351.       Under no circumstances should an Internet Draft be referenced by
  352.       any paper, report, or Request for Proposal.
  353.  
  354.    2.5.  Internet Assigned Number Authority (IANA)
  355.  
  356.       Many protocol specifications include numbers, keywords, and other
  357.       parameters that must be uniquely assigned.  Examples include
  358.       version numbers, protocol numbers, port numbers, and MIB numbers.
  359.       The IAB has delegated to the Internet Assigned Numbers Authority
  360.       (IANA) the task of assigning such protocol parameters for the
  361.       Internet.  The IANA publishes tables of all currently assigned
  362.       numbers and parameters in RFCs titled "Assigned Numbers" [8].
  363.  
  364.       Each category of assigned numbers typically arises from some
  365.       protocol that is on the standards track or is an Internet
  366.       Standard.  For example, TCP port numbers are assigned because TCP
  367.       is a Standard.  A particular value within a category may be
  368.       assigned in a variety of circumstances; the specification
  369.       requiring the parameter may be in the standards track, it may be
  370.       Experimental, or it may be private.
  371.  
  372.       Chaos could result from accidental conflicts of parameter values,
  373.       so we urge that every protocol parameter, for either public or
  374.       private usage, be explicitly assigned by the IANA.  Private
  375.       protocols often become public.  Programmers are often tempted to
  376.       choose a "random" value, or guess the next unassigned value of a
  377.       parameter; both are hazardous.
  378.  
  379.       The IANA is tasked to avoid frivolous assignments and to
  380.       distinguish different assignments uniquely.  The IANA accomplishes
  381.       both goals by requiring a technical description of each protocol
  382.       or service to which a value is to be assigned.  Judgment on the
  383.       adequacy of the description resides with the IANA.  In the case of
  384.       a standards track or Experimental protocol, the corresponding
  385.       technical specifications provide the required documentation for
  386.       IANA.  For a proprietary protocol, the IANA will keep confidential
  387.       any writeup that is supplied, but at least a short (2 page)
  388.       writeup is still required for an assignment.
  389.  
  390.       To contact the IANA for information or to request a number,
  391.  
  392.  
  393.  
  394. IAB                                                             [Page 7]
  395.  
  396. RFC 1310               Internet Standards Process             March 1992
  397.  
  398.  
  399.       keyword or parameter assignment send an email message to
  400.       "iana@isi.edu".
  401.  
  402.    2.6.  Review and Approval
  403.  
  404.       A standards action -- entering a particular specification into, or
  405.       advancing it within, the standards track -- shall be recommended
  406.       to the appropriate IETF Area Director, or to the Chairman of the
  407.       IETF, by the individual or group that is responsible for the
  408.       specification.  Usually, the recommendation will come from an IETF
  409.       Working Group.  The Area Director or IETF chairman, in
  410.       consultation with the IESG, shall determine if an independent
  411.       technical review of the specification is required, and shall
  412.       commission one if necessary.
  413.  
  414.       When a specification is sufficiently important in terms of its
  415.       potential impact on the Internet or on the suite of Internet
  416.       protocols, the IESG shall form a special review and analysis
  417.       committee to prepare an evaluation of the specification.  Such a
  418.       committee is commissioned to provide an objective basis for
  419.       agreement within the Internet community that the specification is
  420.       ready for advancement.  Furthermore, when the criteria for
  421.       advancement along the standards track for an important class of
  422.       specifications (e.g., routing protocols [6]) are not universally
  423.       recognized, the IESG shall commission the development and
  424.       publication of category-specific acceptance criteria.
  425.  
  426.       The IESG shall determine whether a specification satisfies the
  427.       applicable criteria for the recommended action (see Sections 3.2
  428.       and 3.3 of this document) and shall communicate its findings to
  429.       the IETF to permit a final review by the general Internet
  430.       community.  This IETF notification shall be via electronic mail to
  431.       the IETF mailing list; in addition, there will often be a
  432.       presentation or statement by the appropriate working group or Area
  433.       Director during an IETF plenary meeting.  Any significant issues
  434.       that have not been resolved satisfactorily during the development
  435.       of the specification may be raised at this time for final
  436.       resolution by the IESG.
  437.  
  438.       The IESG shall communicate to the IAB its recommendation for
  439.       action, with a citation to the most current version of the
  440.       document.  The IETF shall be notified by email of any such
  441.       recommendation.  If the IAB finds a significant problem, or needs
  442.       clarification on a particular point, it shall resolve the matter
  443.       with the Working Group and its chairperson and/or the document
  444.       author, with the assistance and concurrence of the IESG and the
  445.       relevant IETF Area Director.
  446.  
  447.  
  448.  
  449.  
  450. IAB                                                             [Page 8]
  451.  
  452. RFC 1310               Internet Standards Process             March 1992
  453.  
  454.  
  455.       Following IAB approval and any necessary editorial work, the RFC
  456.       Editor shall publish the specification as an RFC.  The
  457.       specification shall then be removed from the Internet Drafts
  458.       directory.
  459.  
  460.    2.7.  Entering the Standards Track
  461.  
  462.       A specification that is potentially an Internet Standard may
  463.       originate from:
  464.  
  465.       (a)  an IAB-sponsored effort (typically an IETF Working Group),
  466.  
  467.       (b)  independent activity by individuals, or
  468.  
  469.       (c)  an external organization.
  470.  
  471.       In cases (b) and (c), the work might be tightly integrated with
  472.       the work of an existing IETF Working Group, or it might be offered
  473.       for standardization without prior IETF involvement.  In most
  474.       cases, a specification resulting from an effort that took place
  475.       outside of an IETF Working Group context will be submitted to an
  476.       appropriate Working Group for evaluation and refinement; if
  477.       necessary, an appropriate Working Group will be created.
  478.  
  479.       For externally-developed specifications that are well-integrated
  480.       with existing Working Group efforts, a Working Group is assumed to
  481.       afford adequate community review of the accuracy and applicability
  482.       of the specification.  If a Working Group is unable to resolve all
  483.       technical and usage questions, additional independent review may
  484.       be necessary.  Such reviews may be done within a Working Group
  485.       context, or by an ad hoc review committee established specifically
  486.       for that purpose.  It is the responsibility of the appropriate
  487.       IETF Area Director to determine what, if any, review of an
  488.       external specification is needed and how it shall be conducted.
  489.  
  490.    2.8.  Advancing in the Standards Track
  491.  
  492.       A specification shall remain at the Proposed Standard level for at
  493.       least 6 months and at the Draft Standard level for at least 4
  494.       months.
  495.  
  496.       A specification may be (indeed, is likely to be) revised as it
  497.       advances through the standards track.  At each stage, the IESG
  498.       shall determine the scope and significance of the revision to the
  499.       specification, and, if necessary and appropriate, modify the
  500.       recommended action.  Minor revisions are expected, and they will
  501.       not affect advancement through the standards track.  A significant
  502.       revision may require that the specification accumulate more
  503.  
  504.  
  505.  
  506. IAB                                                             [Page 9]
  507.  
  508. RFC 1310               Internet Standards Process             March 1992
  509.  
  510.  
  511.       experience at its current maturity level before progressing.
  512.       Finally, if the specification has been changed very significantly,
  513.       the IESG may decide to treat the revision as if it were a new
  514.       document, re-entering the standards track at the beginning.
  515.  
  516.       A specification that has not reached the maturity level of
  517.       Standard within twenty-four months of first becoming a Proposed
  518.       Standard shall be reviewed for viability by the IESG, which shall
  519.       recommend either termination or continuation of the development
  520.       effort to the IAB.  Such a recommendation shall be communicated to
  521.       the IETF via electronic mail to the IETF mailing list, to allow
  522.       the Internet community an opportunity to comment.  This provision
  523.       is not intended to threaten legitimate and active Working Group
  524.       efforts, but rather to provide an administrative mechanism for
  525.       terminating a moribund effort.
  526.  
  527.    2.9.  Revising a Standard
  528.  
  529.       A recommendation to revise an established Internet Standard shall
  530.       be evaluated by the IESG with respect to the operational impact of
  531.       introducing a new version while the previous version is still in
  532.       use.  If the IESG accepts the recommendation, the new version must
  533.       progress through the full Internet standardization process as if
  534.       it were a completely new specification.
  535.  
  536.       Once the new version has reached the Standard level, it may
  537.       immediately replace the previous version.  In some cases, both
  538.       versions may remain as Internet Standards to honor the
  539.       requirements of an installed base; however, the relationship
  540.       between the previous and the new versions must be explicitly
  541.       stated in the text of the new version or in another appropriate
  542.       document (e.g., an Applicability Statement; see Section 3.1.2).
  543.  
  544. 3.  NOMENCLATURE
  545.  
  546.    3.1.  Types of Specifications
  547.  
  548.       The specifications subject to the Internet standardization process
  549.       fall into two categories:  Technical Specifications (TS) and
  550.       Applicability Statements (AS).
  551.  
  552.       3.1.1.  Technical Specification (TS)
  553.  
  554.          A Technical Specification is any description of a protocol,
  555.          service, procedure, convention, or format.  It may completely
  556.          describe all of the relevant aspects of its subject, or it may
  557.          leave one or more parameters or options unspecified.  A TS may
  558.          be completely self-contained, or it may incorporate material
  559.  
  560.  
  561.  
  562. IAB                                                            [Page 10]
  563.  
  564. RFC 1310               Internet Standards Process             March 1992
  565.  
  566.  
  567.          from other specifications by reference to other documents
  568.          (which may or may not be Internet Standards).
  569.  
  570.          A TS shall include a statement of its scope and the general
  571.          intent for its use (domain of applicability).  Thus, a TS that
  572.          is inherently specific to a particular context shall contain a
  573.          statement to that effect.  However, a TS does not specify
  574.          requirements for its use within the Internet; these
  575.          requirements, which depend on the particular context in which
  576.          the TS is incorporated by different system configurations, is
  577.          defined by an Applicability Statement.
  578.  
  579.       3.1.2.  Applicability Statement (AS)
  580.  
  581.          An Applicability Statement specifies how, and under what
  582.          circumstances, one or more TSs are to be applied to support a
  583.          particular Internet capability. An AS may specify uses for TSs
  584.          that are not Internet Standards, as discussed in Section 4.
  585.  
  586.          An AS identifies the relevant TSs and the specific way in which
  587.          they are to be combined, and may also specify particular values
  588.          or ranges of TS parameters or subfunctions of a TS protocol
  589.          that must be implemented.  An AS also specifies the
  590.          circumstances in which the use of a particular TS is required,
  591.          recommended, or elective.
  592.  
  593.          An AS may describe particular methods of using a TS in a
  594.          restricted "domain of applicability", such as Internet routers,
  595.          terminal servers, Internet systems that interface to Ethernets,
  596.          or datagram-based database servers.
  597.  
  598.          The broadest type of AS is a comprehensive conformance
  599.          specification, commonly called a "requirements document", for a
  600.          particular class of Internet systems [3,4,5], such as Internet
  601.          routers or Internet hosts.
  602.  
  603.          An AS may not have a higher maturity level in the standards
  604.          track than any TS to which the AS applies.  For example, a TS
  605.          at Draft Standard level may be referenced by an AS at the
  606.          Proposed Standard or Draft Standard level, but not an AS at the
  607.          Standard level.  Like a TS, an AS does not come into effect
  608.          until it reaches Standard level.
  609.  
  610.       Although TSs and ASs are conceptually separate, in practice an
  611.       Internet Standard RFC may include elements of both an AS and one
  612.       or more TSs in a single document.  For example, Technical
  613.       Specifications that are developed specifically and exclusively for
  614.       some particular domain of applicability, e.g., for mail server
  615.  
  616.  
  617.  
  618. IAB                                                            [Page 11]
  619.  
  620. RFC 1310               Internet Standards Process             March 1992
  621.  
  622.  
  623.       hosts, often contain within a single specification all of the
  624.       relevant AS and TS information.  In such cases, no useful purpose
  625.       would be served by deliberately distributing the information among
  626.       several documents just to preserve the formal AS/TS distinction.
  627.       However, a TS that is likely to apply to more than one domain of
  628.       applicability should be developed in a modular fashion, to
  629.       facilitate its incorporation by multiple ASs.
  630.  
  631.    3.2.  Standards Track Maturity Levels
  632.  
  633.       ASs and TSs go through stages of development, testing, and
  634.       acceptance.  Within the Internet standards process, these stages
  635.       are formally labeled "maturity levels".
  636.  
  637.       This section describes the maturity levels and the expected
  638.       characteristics of specifications at each level.  The general
  639.       procedures for developing a specification and processing it
  640.       through the maturity levels along the standards track were
  641.       discussed in Section 2 above.
  642.  
  643.       3.2.1. Proposed Standard
  644.  
  645.          The entry-level maturity for the standards track is "Proposed
  646.          Standard".  A Proposed Standard specification is generally
  647.          stable, has resolved known design choices, is believed to be
  648.          well-understood, has received significant community review, and
  649.          appears to enjoy enough community interest to be considered
  650.          valuable.
  651.  
  652.          Usually, neither implementation nor operational experience is
  653.          required for the designation of a specification as a Proposed
  654.          Standard.  However, such experience is highly desirable, and
  655.          will usually represent a strong argument in favor of a Proposed
  656.          Standard designation.  Furthermore, the IAB may require
  657.          implementation and/or operational experience prior to granting
  658.          Proposed Standard status to a specification that materially
  659.          affects the core Internet protocols or that specifies behavior
  660.          that may have significant operational impact on the Internet.
  661.          Typically, such a specification will be published initially in
  662.          the Experimental state (see below), which is not part of the
  663.          standards track, and moved to the standards track only after
  664.          sufficient implementation or operational experience has been
  665.          obtained.
  666.  
  667.          A Proposed Standard should have no known technical omissions
  668.          with respect to the requirements placed upon it.  In some
  669.          cases, the IESG may recommend that the requirements be
  670.          explicitly reduced in order to allow a protocol to advance into
  671.  
  672.  
  673.  
  674. IAB                                                            [Page 12]
  675.  
  676. RFC 1310               Internet Standards Process             March 1992
  677.  
  678.  
  679.          the Proposed Standard state.  This can happen if the
  680.          specification is considered to be useful and necessary (and
  681.          timely), even absent the missing features.  For example, some
  682.          protocols have been advanced by explicitly deciding to omit
  683.          security features at the Proposed Standard level, since an
  684.          overall security architecture was still under development.
  685.  
  686.       3.2.2. Draft Standard
  687.  
  688.          A specification from which at least two independent and
  689.          interoperable implementations have been developed, and for
  690.          which adequate operational experience has been obtained, may be
  691.          elevated to the "Draft Standard" level.  This is a major
  692.          advance in status, indicating a strong belief that the
  693.          specification is mature and will be useful.
  694.  
  695.          A Draft Standard must be well-understood and known to be quite
  696.          stable, both in its semantics and as a basis for developing an
  697.          implementation.  A Draft Standard may still require additional
  698.          or more widespread field experience, since it is possible for
  699.          implementations based on Draft Standard specifications to
  700.          demonstrate unforeseen behavior when subjected to large-scale
  701.          use in production environments.
  702.  
  703.       3.2.3. Standard
  704.  
  705.          A specification for which significant implementation and
  706.          operational experience has been obtained may be elevated to the
  707.          Standard level.  A Standard is characterized by a high degree
  708.          of technical maturity and by a generally held belief that the
  709.          specified protocol or service provides significant benefit to
  710.          the Internet community.
  711.  
  712.    3.3. Non-Standards Track Maturity Levels
  713.  
  714.       Not every TS or AS is on the standards track.  A TS may not be
  715.       intended to be an Internet Standard, or it may be intended for
  716.       eventual standardization but not yet ready to enter the standards
  717.       track.  A TS or AS may have been superseded by more recent
  718.       Internet Standards, or have otherwise fallen into disuse or
  719.       disfavor.  Such specifications are labeled with one of three
  720.       "non-standards track" maturity levels: "Historic", "Experimental",
  721.       and "Informational".
  722.  
  723.       3.3.1. Historic
  724.  
  725.          A TS or AS that has been superseded by a more recent
  726.          specification or is for any other reason considered to be
  727.  
  728.  
  729.  
  730. IAB                                                            [Page 13]
  731.  
  732. RFC 1310               Internet Standards Process             March 1992
  733.  
  734.  
  735.          obsolete is assigned to the "Historic" level.  (Purists have
  736.          suggested that the word should be "Historical"; however, at
  737.          this point the use of "Historic" is historical.)
  738.  
  739.       3.3.2. Experimental
  740.  
  741.          The "Experimental" designation on a TS permits widespread
  742.          dissemination (through publication according to the procedures
  743.          defined by this document) with explicit caveats:  it may
  744.          specify behavior that has not been thoroughly analyzed or is
  745.          poorly understood;  it may be subject to considerable change;
  746.          it may never be a candidate for the formal standards track;
  747.          and it may be discarded in favor of some other proposal.
  748.  
  749.          Any TS that is not an immediate candidate for Internet
  750.          standardization is appropriate for publication as Experimental.
  751.          Interested parties are thereby given the opportunity to gain
  752.          experience with implementations and to report their findings to
  753.          the community of interest, but the specification is explicitly
  754.          not recommended for general production use.
  755.  
  756.       3.3.3. Informational
  757.  
  758.          An "Informational" specification is published for the general
  759.          information of the Internet community, and does not represent
  760.          an Internet community consensus or recommendation.
  761.  
  762.          Specifications that have been prepared outside of the Internet
  763.          community and are not incorporated into the Internet standards
  764.          process by any of the provisions of Section 4 may be published
  765.          as Informational RFCs, with the permission of the owner.  Such
  766.          a document is not an Internet Standard in any sense.
  767.  
  768.    3.4.  Requirement Levels
  769.  
  770.       An AS may apply one of the following "requirement levels" to each
  771.       of the TSs to which it refers:
  772.  
  773.       (a)  Required:  Implementation of the referenced TS, as specified
  774.            by the AS, is required to achieve minimal conformance.  For
  775.            example, IP and ICMP must be implemented by all Internet
  776.            systems using the TCP/IP Protocol Suite.
  777.  
  778.       (b)  Recommended:  Implementation of the referenced TS is not
  779.            required for minimal conformance, but experience and/or
  780.            generally accepted technical wisdom suggest its desirability
  781.            in the domain of applicability of the AS.  Vendors are
  782.            strongly encouraged to include the functions, features, and
  783.  
  784.  
  785.  
  786. IAB                                                            [Page 14]
  787.  
  788. RFC 1310               Internet Standards Process             March 1992
  789.  
  790.  
  791.            protocols of Recommended TSs in their products, and should
  792.            omit them only if the omission is justified by some special
  793.            circumstance.
  794.  
  795.       (c)  Elective:  Implementation of the referenced TS is optional
  796.            within the domain of applicability of the AS; that is, the AS
  797.            creates no explicit necessity to apply the TS.  However, a
  798.            particular vendor may decide to implement it, or a particular
  799.            user may decide that it is a necessity in a specific
  800.            environment.
  801.  
  802.       As noted in Section 2.5, there are TSs that are not in the
  803.       standards track or that have been retired from the standards
  804.       track, and are therefore not required, recommended, or elective.
  805.       Two additional "requirement level" designations are available for
  806.       such TSs:
  807.  
  808.       (d)  Limited Use:  The TS is considered appropriate for use only
  809.            in limited or unique circumstances.  For example, the usage
  810.            of a protocol with the "Experimental" designation should
  811.            generally be limited to those actively involved with the
  812.            experiment.
  813.  
  814.       (e)  Not Recommended:  A TS that is considered to be inappropriate
  815.            for general use is labeled "Not Recommended".  This may be
  816.            because of its limited functionality, specialized nature, or
  817.            historic status.
  818.  
  819.       The "IAB Official Protocol Standards" RFC lists a general
  820.       requirement level for each TS, using the nomenclature defined in
  821.       this section.  In many cases, more detailed descriptions of the
  822.       requirement levels of particular protocols and of individual
  823.       features of the protocols will be found in appropriate ASs.
  824.  
  825. 4.  EXTERNAL STANDARDS AND SPECIFICATIONS
  826.  
  827.    Many de facto and de jure standards groups other than the IAB/IETF
  828.    create and publish standards documents for network protocols and
  829.    services.  When these external specifications play an important role
  830.    in the Internet, it is desirable to reach common agreements on their
  831.    usage -- i.e., to establish Internet Standards relating to these
  832.    external specifications.
  833.  
  834.    There are two categories of external specifications:
  835.  
  836.    (1)  Open Standards
  837.  
  838.         Accredited national and international standards bodies, such as
  839.  
  840.  
  841.  
  842. IAB                                                            [Page 15]
  843.  
  844. RFC 1310               Internet Standards Process             March 1992
  845.  
  846.  
  847.         ANSI, ISO, IEEE, and CCITT, develop a variety of protocol and
  848.         service specifications that are similar to Technical
  849.         Specifications (see glossary in Appendix A).  These
  850.         specifications are generally de jure standards.  Similarly,
  851.         national and international groups publish "implementors'
  852.         agreements" that are analogous to Applicability Statements,
  853.         capturing a body of implementation-specific detail concerned
  854.         with the practical application of their standards.
  855.  
  856.    (2)  Vendor Specifications
  857.  
  858.         A vendor-specific specification that has come to be widely used
  859.         in the Internet may be treated by the Internet community as a de
  860.         facto "standard".  Such a specification is not generally
  861.         developed in an open fashion, is typically proprietary, and is
  862.         controlled by the vendor or vendors that produced it.
  863.  
  864.    To avoid conflict between competing versions of a specification, the
  865.    Internet community will not standardize a TS or AS that is simply an
  866.    "Internet version" of an existing external specification, unless an
  867.    explicit cooperative arrangement to do so has been made.  There are,
  868.    however, several ways in which an external specification that is
  869.    important for the operation and/or evolution of the Internet may be
  870.    adopted for Internet use:
  871.  
  872.    (a)  Incorporation of an Open Standard
  873.  
  874.         An Internet Standard TS or AS may incorporate an open external
  875.         standard by reference.  The reference must be to a specific
  876.         version of the external standard, e.g., by publication date or
  877.         by edition number, according to the prevailing convention of the
  878.         organization that is responsible for the specification.
  879.  
  880.         For example, many Internet Standards incorporate by reference
  881.         the ANSI standard character set "ASCII" [7].
  882.  
  883.    (b)  Incorporation of a Vendor Specification
  884.  
  885.         Vendor-proprietary specifications may also be incorporated, by
  886.         reference to a specific version of the vendor standard.  If the
  887.         vendor-proprietary specification is not widely and readily
  888.         available, the IAB may request that it be published as an
  889.         Informational RFC.
  890.  
  891.         In order for a vendor-proprietary specification to be
  892.         incorporated within the Internet standards process, the
  893.         proprietor must agree in writing to the IAB that "right to use"
  894.         licenses will be available on a non-discriminatory basis and at
  895.  
  896.  
  897.  
  898. IAB                                                            [Page 16]
  899.  
  900. RFC 1310               Internet Standards Process             March 1992
  901.  
  902.  
  903.         a reasonable cost.  See also Sections 5 and 6.
  904.  
  905.         In addition, the IAB/IETF will generally not favor a particular
  906.         vendor's proprietary specification over the technically
  907.         equivalent and competing specifications of other vendors by
  908.         making it "required" or "recommended".
  909.  
  910.    (c)  Assumption
  911.  
  912.         An IETF Working Group may start with a vendor's (or other
  913.         body's) voluntarily contributed specification, and independently
  914.         evolve the specification into a TS or AS.  Here "independently"
  915.         means that the IETF work is not constrained by conditions
  916.         imposed by the owner of the original specification;  however,
  917.         the continued participation of the original owner in the IETF
  918.         work is likely to be valuable, and is encouraged.  The IAB must
  919.         receive a formal delegation of responsibility from the original
  920.         owner that gives the IAB/IETF responsibility for evolution of
  921.         the specification.
  922.  
  923.    As provided by section 3.1.2, an AS that specifies how an external
  924.    technical specification should be applied in the Internet,
  925.    incorporating the external specification by reference, may become an
  926.    Internet Standard.
  927.  
  928. 5.  INTELLECTUAL PROPERTY RIGHTS
  929.  
  930.    Prior to the approval of a specification as a Proposed Standard, all
  931.    interested parties are required to disclose to the IAB the existence
  932.    of any intellectual property right claims known to them that might
  933.    apply to any aspect of the Proposed Standard.
  934.  
  935.    This requirement refers specifically to disclosure of the *existence*
  936.    of a current or anticipated claim of an intellectual property right,
  937.    not the details of the asserted right itself.
  938.  
  939. 6.  PATENT POLICY
  940.  
  941.    This section is tentative, subject to legal review.
  942.  
  943.    There is no objection in principle to drafting an Internet Standard
  944.    in terms that include an item or items subject to patent rights that
  945.    may have been asserted in one or more countries, if it is considered
  946.    that technical reasons justify this approach.  In such cases the
  947.    procedure described in this section shall be followed.
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. IAB                                                            [Page 17]
  955.  
  956. RFC 1310               Internet Standards Process             March 1992
  957.  
  958.  
  959.    6.1 Statement from Patent Holder
  960.  
  961.       Prior to approval of the specification as a Proposed Standard, the
  962.       IAB shall receive from the known patent holders, in a form
  963.       acceptable to and approved by the IAB, either (a) assurance in the
  964.       form of a general disclaimer to the effect that the patent holder
  965.       does not hold and does not anticipate holding any right that would
  966.       be violated as a consequence of conformance to the standard, or
  967.       (b) assurance that
  968.  
  969.       (1)  a license will be made available without compensation to all
  970.            applicants desiring to utilize the patented items for the
  971.            purpose of implementing the standard, or
  972.  
  973.       (2)  a license will be made available to applicants under
  974.            specified reasonable terms and conditions that are, to the
  975.            satisfaction of the IAB, demonstrably free of any unfair
  976.            discrimination.
  977.  
  978.       The terms and conditions of any license falling under (1) or (2)
  979.       shall be submitted to the IAB for review, together with a
  980.       statement of the number of independent licenses, if any, that have
  981.       accepted or indicated their acceptance of the terms and conditions
  982.       of the license.
  983.  
  984.       In addition, the letter to the IAB must contain (c) assurance that
  985.       the patent holder does have the right to grant the license, and
  986.       (d) a notification of any other patent licenses that are required,
  987.       or else the assurance that no other licenses are required.
  988.  
  989.    6.2  Record of Statement
  990.  
  991.       A record of the patent holder's statement (and a statement from
  992.       the IAB of the basis for considering such terms and conditions to
  993.       be free of any unfair discrimination) shall be placed and retained
  994.       in the files of the IAB.
  995.  
  996.    6.3  Notice
  997.  
  998.       When the IAB receives from a patent holder the assurance set forth
  999.       in section 5.1(1) or 5.1(2), the corresponding Internet Standard
  1000.       shall include a note as follows:
  1001.  
  1002.       "NOTE:  The user's attention is called to the possibility that
  1003.       compliance with this standard may require the use of an invention
  1004.       or work covered by patent claims.
  1005.  
  1006.       "By publication of this standard, no position is taken with
  1007.  
  1008.  
  1009.  
  1010. IAB                                                            [Page 18]
  1011.  
  1012. RFC 1310               Internet Standards Process             March 1992
  1013.  
  1014.  
  1015.       respect to the validity of this claim or of any patent rights in
  1016.       connection therewith.  The patent holder has, however, filed a
  1017.       statement of willingness to grant a license under these rights, on
  1018.       reasonable and nondiscriminatory terms and conditions, to
  1019.       applicants desiring to obtain such a license.  Details may be
  1020.       obtained from the IAB."
  1021.  
  1022.    6.4  Identifying Patents
  1023.  
  1024.       The IAB shall not be responsible for identifying all patents for
  1025.       which a license may be required by an Internet Standard, nor for
  1026.       conducting inquiries into the legal validity or scope of those
  1027.       patents that are brought to its attention.
  1028.  
  1029. 7.  ACKNOWLEDGMENTS AND REFERENCES
  1030.  
  1031.    This document represents the combined output of the Internet
  1032.    Activities Board and the Internet Engineering Steering Group, the
  1033.    groups charged with managing the processes described in this
  1034.    document.  Major contributions to the text were made by Bob Braden,
  1035.    Vint Cerf, Lyman Chapin, Dave Crocker, and Barry Leiner.  Helpful
  1036.    comments and suggestions were made by a number of IETF members.
  1037.  
  1038.    [1]  Cerf, V., "The Internet Activities Board", RFC 1160, IAB, May
  1039.         1990.
  1040.  
  1041.    [2]  Postel, J., "IAB Official Protocol Standards", RFC 1280, IAB,
  1042.         March 1992.
  1043.  
  1044.    [3]  Braden, R., Editor, "Requirements for Internet Hosts --
  1045.         Communication Layers", RFC 1122, IETF, October 1989.
  1046.  
  1047.    [4]  Braden, R., Editor, "Requirements for Internet Hosts --
  1048.         Application and Support", RFC 1123, IETF, October 1989.
  1049.  
  1050.    [5]  Almquist, P., Editor, "Requirements for IP Routers", in
  1051.         preparation.
  1052.  
  1053.    [6]  Hinden, R., "Internet Engineering Task Force Internet Routing
  1054.         Protocol Standardization Criteria", RFC 1264, BBN, October 1991.
  1055.  
  1056.    [7]  ANSI, Coded Character Set -- 7-Bit American Standard Code for
  1057.         Information Interchange, ANSI X3.4-1986.
  1058.  
  1059.    [8]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, ISI,
  1060.         March 1990.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. IAB                                                            [Page 19]
  1067.  
  1068. RFC 1310               Internet Standards Process             March 1992
  1069.  
  1070.  
  1071.    [9]  Postel, J., "Introduction to the STD Notes", RFC 1311, ISI,
  1072.         March 1992.
  1073.  
  1074. APPENDIX A: GLOSSARY
  1075.  
  1076.    ANSI:  American National Standards Institute
  1077.  
  1078.    CCITT: Consultative Committee for International Telephone and
  1079.              Telegraphy.
  1080.  
  1081.              A part of the UN Treaty Organization: the International
  1082.              Telecommunications Union (ITU).
  1083.  
  1084.    DARPA: (U.S.) Defense Advanced Research Projects Agency
  1085.  
  1086.    ISO:   International Organization for Standardization
  1087.  
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. IAB                                                            [Page 20]
  1123.  
  1124. RFC 1310               Internet Standards Process             March 1992
  1125.  
  1126.  
  1127. APPENDIX B: FUTURE ISSUES
  1128.  
  1129.    This memo resulted from an effort to document the current standards
  1130.    procedures in the Internet community.  At the time of publication,
  1131.    Sections 5 and 6 are still undergoing legal review.  In addition,
  1132.    there are important issues under consideration of how to handle
  1133.    copyrights and other issues of intellectual property.  This memo is
  1134.    being published with these matters unresolved, due to its importance.
  1135.  
  1136.    Pre-publication review of this document resulted in a number of
  1137.    useful suggestions from members of the Internet community, and opened
  1138.    up several new issues.  The IAB and IESG will continue to consider
  1139.    these questions and attempt to resolve these issues; the results will
  1140.    be be incorporated in future versions of this memo.
  1141.  
  1142.    For future reference, this appendix records the outstanding
  1143.    suggestions and issues.
  1144.  
  1145.    It has been suggested that additional procedures in the following
  1146.    areas should be considered.
  1147.  
  1148.    o    Appeals Procedure
  1149.  
  1150.         Should there be some formal appeals procedure for correcting
  1151.         abuses or procedural failures, at each decision point in the
  1152.         process?
  1153.  
  1154.    o    Tracking Procedure
  1155.  
  1156.         Should there be a formal procedure for tracking problems and
  1157.         change requests, as a specification moves through the standards
  1158.         track?  Such a procedure might include written responses, which
  1159.         were cataloged and disseminated, or simply a database that
  1160.         listed changes between versions.
  1161.  
  1162.    o    Rationale Documentation
  1163.  
  1164.         Should the procedures require written documentation of the
  1165.         rationale for the design decisions behind each specification at
  1166.         the Draft Standard and Standard levels?
  1167.  
  1168.    o    Application-Layer Standards
  1169.  
  1170.         Should there be some way to "standardize" application-layer
  1171.         protocols that are not going to become Internet Standards?
  1172.  
  1173.    There were suggestions for fine-tuning of the existing procedures:
  1174.  
  1175.  
  1176.  
  1177.  
  1178. IAB                                                            [Page 21]
  1179.  
  1180. RFC 1310               Internet Standards Process             March 1992
  1181.  
  1182.  
  1183.    o    Increase minimum time in Internet Draft directory from 2 weeks
  1184.         to 1 month.
  1185.  
  1186.    o    Place explicit time limit, on IESG and IAB action on suggested
  1187.         standards changes.  Limits suggested: three months.
  1188.  
  1189.         If it were necessary to extend the time for some reason, the
  1190.         IETF would have to be explicitly notified.
  1191.  
  1192.    o    Change minimum time at Draft Standard from 4 to 5 months, to
  1193.         ensure that an IETF meeting will intervene.
  1194.  
  1195.    o    There were differing suggestions on how to balance between early
  1196.         implementation of specifications available only as Internet
  1197.         Drafts, and ensuring that everyone is clear that such an
  1198.         Internet Draft has no official status and is subject to change
  1199.         at any time.  One suggestion was that vendors should not claim
  1200.         compliance with an Internet Draft.
  1201.  
  1202.    Finally, there were suggestions for improvements in the documentation
  1203.    of the standards procedures.
  1204.  
  1205.    o    Discuss the impact, if any, of export control laws on the
  1206.         Internet standardization process.
  1207.  
  1208.         It was observed that the Requirements RFCs contain "negative"
  1209.         requirement levels: MUST NOT and SHOULD NOT.  Such levels are
  1210.         not recognized in this Procedures document.
  1211.  
  1212.    o    Document needs to more clearly explain the criteria for choosing
  1213.         the Experimental vs. Informational category for an off-track
  1214.         specification.  Ref. sections 3.3.2, 3.3.4.
  1215.  
  1216.    o    Develop recommended wording for citations to Internet Drafts,
  1217.         which makes clear the provisional, unofficial nature of that
  1218.         document.
  1219.  
  1220.    o    Consider changing the name attached to a fully-adopted standard
  1221.         from "Standard" to some qualified term like "Full Standard".
  1222.  
  1223.    o    It has been suggested that the document should more strongly
  1224.         encourage the use of specifications from other standards bodies,
  1225.         with Internet-specific changes to be made only for compelling
  1226.         reasons.  Further, the justification of the compelling
  1227.         requirement would be subject to special review.
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. IAB                                                            [Page 22]
  1235.  
  1236. RFC 1310               Internet Standards Process             March 1992
  1237.  
  1238.  
  1239. Security Considerations
  1240.  
  1241.    Security issues are not substantially discussed in this memo.
  1242.  
  1243. Author's Address
  1244.  
  1245.    A. Lyman Chapin
  1246.    BBN Communications Corporation
  1247.    150 Cambridge Park Drive
  1248.    Cambridge, MA  02140
  1249.  
  1250.    Phone: 617-873-3133
  1251.    Fax:   617-873-4086
  1252.  
  1253.    Email: Lyman@BBN.COM
  1254.  
  1255.  
  1256.  
  1257.  
  1258.  
  1259.  
  1260.  
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275.  
  1276.  
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. IAB                                                            [Page 23]
  1291.