rfc1310.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,291 行 · 第 1/4 页

      cognizant Working Group, a document that is expected to enter or
      advance in the Internet standardization process shall be made
      available as an Internet Draft.  It shall remain as an Internet
      Draft for a period of time that permits useful community review,
      at least two weeks, before submission to the IESG.

      An Internet Draft that is published as an RFC is removed from the
      Internet Draft directory.  A document that has remained unchanged
      in the Internet Drafts directory for more than six months without
      being recommended by the IESG for publication as an RFC is simply
      removed from the Internet Draft directory.  At any time, an



IAB                                                             [Page 6]

RFC 1310               Internet Standards Process             March 1992


      Internet Draft may be replace by a more recent version of the same
      specification, restarting the six-month timeout period.

      An Internet Draft is NOT a means of "publishing" a specification;
      specifications are published through the RFC mechanism described
      in the next section.  Internet Drafts have no formal status, and
      are not part of the permanent archival record of Internet
      activity, and they are subject to change or removal at any time.
      Under no circumstances should an Internet Draft be referenced by
      any paper, report, or Request for Proposal.

   2.5.  Internet Assigned Number Authority (IANA)

      Many protocol specifications include numbers, keywords, and other
      parameters that must be uniquely assigned.  Examples include
      version numbers, protocol numbers, port numbers, and MIB numbers.
      The IAB has delegated to the Internet Assigned Numbers Authority
      (IANA) the task of assigning such protocol parameters for the
      Internet.  The IANA publishes tables of all currently assigned
      numbers and parameters in RFCs titled "Assigned Numbers" [8].

      Each category of assigned numbers typically arises from some
      protocol that is on the standards track or is an Internet
      Standard.  For example, TCP port numbers are assigned because TCP
      is a Standard.  A particular value within a category may be
      assigned in a variety of circumstances; the specification
      requiring the parameter may be in the standards track, it may be
      Experimental, or it may be private.

      Chaos could result from accidental conflicts of parameter values,
      so we urge that every protocol parameter, for either public or
      private usage, be explicitly assigned by the IANA.  Private
      protocols often become public.  Programmers are often tempted to
      choose a "random" value, or guess the next unassigned value of a
      parameter; both are hazardous.

      The IANA is tasked to avoid frivolous assignments and to
      distinguish different assignments uniquely.  The IANA accomplishes
      both goals by requiring a technical description of each protocol
      or service to which a value is to be assigned.  Judgment on the
      adequacy of the description resides with the IANA.  In the case of
      a standards track or Experimental protocol, the corresponding
      technical specifications provide the required documentation for
      IANA.  For a proprietary protocol, the IANA will keep confidential
      any writeup that is supplied, but at least a short (2 page)
      writeup is still required for an assignment.

      To contact the IANA for information or to request a number,



IAB                                                             [Page 7]

RFC 1310               Internet Standards Process             March 1992


      keyword or parameter assignment send an email message to
      "[e-mail]".

   2.6.  Review and Approval

      A standards action -- entering a particular specification into, or
      advancing it within, the standards track -- shall be recommended
      to the appropriate IETF Area Director, or to the Chairman of the
      IETF, by the individual or group that is responsible for the
      specification.  Usually, the recommendation will come from an IETF
      Working Group.  The Area Director or IETF chairman, in
      consultation with the IESG, shall determine if an independent
      technical review of the specification is required, and shall
      commission one if necessary.

      When a specification is sufficiently important in terms of its
      potential impact on the Internet or on the suite of Internet
      protocols, the IESG shall form a special review and analysis
      committee to prepare an evaluation of the specification.  Such a
      committee is commissioned to provide an objective basis for
      agreement within the Internet community that the specification is
      ready for advancement.  Furthermore, when the criteria for
      advancement along the standards track for an important class of
      specifications (e.g., routing protocols [6]) are not universally
      recognized, the IESG shall commission the development and
      publication of category-specific acceptance criteria.

      The IESG shall determine whether a specification satisfies the
      applicable criteria for the recommended action (see Sections 3.2
      and 3.3 of this document) and shall communicate its findings to
      the IETF to permit a final review by the general Internet
      community.  This IETF notification shall be via electronic mail to
      the IETF mailing list; in addition, there will often be a
      presentation or statement by the appropriate working group or Area
      Director during an IETF plenary meeting.  Any significant issues
      that have not been resolved satisfactorily during the development
      of the specification may be raised at this time for final
      resolution by the IESG.

      The IESG shall communicate to the IAB its recommendation for
      action, with a citation to the most current version of the
      document.  The IETF shall be notified by email of any such
      recommendation.  If the IAB finds a significant problem, or needs
      clarification on a particular point, it shall resolve the matter
      with the Working Group and its chairperson and/or the document
      author, with the assistance and concurrence of the IESG and the
      relevant IETF Area Director.




IAB                                                             [Page 8]

RFC 1310               Internet Standards Process             March 1992


      Following IAB approval and any necessary editorial work, the RFC
      Editor shall publish the specification as an RFC.  The
      specification shall then be removed from the Internet Drafts
      directory.

   2.7.  Entering the Standards Track

      A specification that is potentially an Internet Standard may
      originate from:

      (a)  an IAB-sponsored effort (typically an IETF Working Group),

      (b)  independent activity by individuals, or

      (c)  an external organization.

      In cases (b) and (c), the work might be tightly integrated with
      the work of an existing IETF Working Group, or it might be offered
      for standardization without prior IETF involvement.  In most
      cases, a specification resulting from an effort that took place
      outside of an IETF Working Group context will be submitted to an
      appropriate Working Group for evaluation and refinement; if
      necessary, an appropriate Working Group will be created.

      For externally-developed specifications that are well-integrated
      with existing Working Group efforts, a Working Group is assumed to
      afford adequate community review of the accuracy and applicability
      of the specification.  If a Working Group is unable to resolve all
      technical and usage questions, additional independent review may
      be necessary.  Such reviews may be done within a Working Group
      context, or by an ad hoc review committee established specifically
      for that purpose.  It is the responsibility of the appropriate
      IETF Area Director to determine what, if any, review of an
      external specification is needed and how it shall be conducted.

   2.8.  Advancing in the Standards Track

      A specification shall remain at the Proposed Standard level for at
      least 6 months and at the Draft Standard level for at least 4
      months.

      A specification may be (indeed, is likely to be) revised as it
      advances through the standards track.  At each stage, the IESG
      shall determine the scope and significance of the revision to the
      specification, and, if necessary and appropriate, modify the
      recommended action.  Minor revisions are expected, and they will
      not affect advancement through the standards track.  A significant
      revision may require that the specification accumulate more



IAB                                                             [Page 9]

RFC 1310               Internet Standards Process             March 1992


      experience at its current maturity level before progressing.
      Finally, if the specification has been changed very significantly,
      the IESG may decide to treat the revision as if it were a new
      document, re-entering the standards track at the beginning.

      A specification that has not reached the maturity level of
      Standard within twenty-four months of first becoming a Proposed
      Standard shall be reviewed for viability by the IESG, which shall
      recommend either termination or continuation of the development
      effort to the IAB.  Such a recommendation shall be communicated to
      the IETF via electronic mail to the IETF mailing list, to allow
      the Internet community an opportunity to comment.  This provision
      is not intended to threaten legitimate and active Working Group
      efforts, but rather to provide an administrative mechanism for
      terminating a moribund effort.

   2.9.  Revising a Standard

      A recommendation to revise an established Internet Standard shall
      be evaluated by the IESG with respect to the operational impact of
      introducing a new version while the previous version is still in
      use.  If the IESG accepts the recommendation, the new version must
      progress through the full Internet standardization process as if
      it were a completely new specification.

      Once the new version has reached the Standard level, it may
      immediately replace the previous version.  In some cases, both
      versions may remain as Internet Standards to honor the
      requirements of an installed base; however, the relationship
      between the previous and the new versions must be explicitly
      stated in the text of the new version or in another appropriate
      document (e.g., an Applicability Statement; see Section 3.1.2).

3.  NOMENCLATURE

   3.1.  Types of Specifications

      The specifications subject to the Internet standardization process
      fall into two categories:  Technical Specifications (TS) and
      Applicability Statements (AS).

      3.1.1.  Technical Specification (TS)

         A Technical Specification is any description of a protocol,
         service, procedure, convention, or format.  It may completely
         describe all of the relevant aspects of its subject, or it may
         leave one or more parameters or options unspecified.  A TS may
         be completely self-contained, or it may incorporate material



IAB                                                            [Page 10]

RFC 1310               Internet Standards Process             March 1992


         from other specifications by reference to other documents
         (which may or may not be Internet Standards).

         A TS shall include a statement of its scope and the general
         intent for its use (domain of applicability).  Thus, a TS that
         is inherently specific to a particular context shall contain a
         statement to that effect.  However, a TS does not specify
         requirements for its use within the Internet; these
         requirements, which depend on the particular context in which
         the TS is incorporated by different system configurations, is
         defined by an Applicability Statement.

      3.1.2.  Applicability Statement (AS)

         An Applicability Statement specifies how, and under what
         circumstances, one or more TSs are to be applied to support a
         particular Internet capability. An AS may specify uses for TSs
         that are not Internet Standards, as discussed in Section 4.

         An AS identifies the relevant TSs and the specific way in which
         they are to be combined, and may also specify particular values
         or ranges of TS parameters or subfunctions of a TS protocol
         that must be implemented.  An AS also specifies the
         circumstances in which the use of a particular TS is required,
         recommended, or elective.

         An AS may describe particular methods of using a TS in a
         restricted "domain of applicability", such as Internet routers,
         terminal servers, Internet systems that interface to Ethernets,
         or datagram-based database servers.

         The broadest type of AS is a comprehensive conformance
         specification, commonly called a "requirements document", for a
         particular class of Internet systems [3,4,5], such as Internet
         routers or Internet hosts.

         An AS may not have a higher maturity level in the standards
         track than any TS to which the AS applies.  For example, a TS
         at Draft Standard level may be referenced by an AS at the
         Proposed Standard or Draft Standard level, but not an AS at the
         Standard level.  Like a TS, an AS does not come into effect
         until it reaches Standard level.

      Although TSs and ASs are conceptually separate, in practice an
      Internet Standard RFC may include elements of both an AS and one
      or more TSs in a single document.  For example, Technical
      Specifications that are developed specifically and exclusively for
      some particular domain of applicability, e.g., for mail server



IAB                                                            [Page 11]

RFC 1310               Internet Standards Process             March 1992


      hosts, often contain within a single specification all of the
      relevant AS and TS information.  In such cases, no useful purpose
      would be served by deliberately distributing the information among
      several documents just to preserve the formal AS/TS distinction.
      However, a TS that is likely to apply to more than one domain of
      applicability should be developed in a modular fashion, to
      facilitate its incorporation by multiple ASs.

   3.2.  Standards Track Maturity Levels

      ASs and TSs go through stages of development, testing, and
      acceptance.  Within the Internet standards process, these stages
      are formally labeled "maturity levels".

      This section describes the maturity levels and the expected
      characteristics of specifications at each level.  The general
      procedures for developing a specification and processing it
      through the maturity levels along the standards track were
      discussed in Section 2 above.

      3.2.1. Proposed Standard

         The entry-level maturity for the standards track is "Proposed
         Standard".  A Proposed Standard specification is generally