rfc1310.txt

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

           applicants desiring to utilize the patented items for the
           purpose of implementing the standard, or

      (2)  a license will be made available to applicants under
           specified reasonable terms and conditions that are, to the
           satisfaction of the IAB, demonstrably free of any unfair
           discrimination.

      The terms and conditions of any license falling under (1) or (2)
      shall be submitted to the IAB for review, together with a
      statement of the number of independent licenses, if any, that have
      accepted or indicated their acceptance of the terms and conditions
      of the license.

      In addition, the letter to the IAB must contain (c) assurance that
      the patent holder does have the right to grant the license, and
      (d) a notification of any other patent licenses that are required,
      or else the assurance that no other licenses are required.

   6.2  Record of Statement

      A record of the patent holder's statement (and a statement from
      the IAB of the basis for considering such terms and conditions to
      be free of any unfair discrimination) shall be placed and retained
      in the files of the IAB.

   6.3  Notice

      When the IAB receives from a patent holder the assurance set forth
      in section 5.1(1) or 5.1(2), the corresponding Internet Standard
      shall include a note as follows:

      "NOTE:  The user's attention is called to the possibility that
      compliance with this standard may require the use of an invention
      or work covered by patent claims.

      "By publication of this standard, no position is taken with



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


      respect to the validity of this claim or of any patent rights in
      connection therewith.  The patent holder has, however, filed a
      statement of willingness to grant a license under these rights, on
      reasonable and nondiscriminatory terms and conditions, to
      applicants desiring to obtain such a license.  Details may be
      obtained from the IAB."

   6.4  Identifying Patents

      The IAB shall not be responsible for identifying all patents for
      which a license may be required by an Internet Standard, nor for
      conducting inquiries into the legal validity or scope of those
      patents that are brought to its attention.

7.  ACKNOWLEDGMENTS AND REFERENCES

   This document represents the combined output of the Internet
   Activities Board and the Internet Engineering Steering Group, the
   groups charged with managing the processes described in this
   document.  Major contributions to the text were made by Bob Braden,
   Vint Cerf, Lyman Chapin, Dave Crocker, and Barry Leiner.  Helpful
   comments and suggestions were made by a number of IETF members.

   [1]  Cerf, V., "The Internet Activities Board", RFC 1160, IAB, May
        1990.

   [2]  Postel, J., "IAB Official Protocol Standards", RFC 1280, IAB,
        March 1992.

   [3]  Braden, R., Editor, "Requirements for Internet Hosts --
        Communication Layers", RFC 1122, IETF, October 1989.

   [4]  Braden, R., Editor, "Requirements for Internet Hosts --
        Application and Support", RFC 1123, IETF, October 1989.

   [5]  Almquist, P., Editor, "Requirements for IP Routers", in
        preparation.

   [6]  Hinden, R., "Internet Engineering Task Force Internet Routing
        Protocol Standardization Criteria", RFC 1264, BBN, October 1991.

   [7]  ANSI, Coded Character Set -- 7-Bit American Standard Code for
        Information Interchange, ANSI X3.4-1986.

   [8]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, ISI,
        March 1990.





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


   [9]  Postel, J., "Introduction to the STD Notes", RFC 1311, ISI,
        March 1992.

APPENDIX A: GLOSSARY

   ANSI:  American National Standards Institute

   CCITT: Consultative Committee for International Telephone and
             Telegraphy.

             A part of the UN Treaty Organization: the International
             Telecommunications Union (ITU).

   DARPA: (U.S.) Defense Advanced Research Projects Agency

   ISO:   International Organization for Standardization



































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


APPENDIX B: FUTURE ISSUES

   This memo resulted from an effort to document the current standards
   procedures in the Internet community.  At the time of publication,
   Sections 5 and 6 are still undergoing legal review.  In addition,
   there are important issues under consideration of how to handle
   copyrights and other issues of intellectual property.  This memo is
   being published with these matters unresolved, due to its importance.

   Pre-publication review of this document resulted in a number of
   useful suggestions from members of the Internet community, and opened
   up several new issues.  The IAB and IESG will continue to consider
   these questions and attempt to resolve these issues; the results will
   be be incorporated in future versions of this memo.

   For future reference, this appendix records the outstanding
   suggestions and issues.

   It has been suggested that additional procedures in the following
   areas should be considered.

   o    Appeals Procedure

        Should there be some formal appeals procedure for correcting
        abuses or procedural failures, at each decision point in the
        process?

   o    Tracking Procedure

        Should there be a formal procedure for tracking problems and
        change requests, as a specification moves through the standards
        track?  Such a procedure might include written responses, which
        were cataloged and disseminated, or simply a database that
        listed changes between versions.

   o    Rationale Documentation

        Should the procedures require written documentation of the
        rationale for the design decisions behind each specification at
        the Draft Standard and Standard levels?

   o    Application-Layer Standards

        Should there be some way to "standardize" application-layer
        protocols that are not going to become Internet Standards?

   There were suggestions for fine-tuning of the existing procedures:




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


   o    Increase minimum time in Internet Draft directory from 2 weeks
        to 1 month.

   o    Place explicit time limit, on IESG and IAB action on suggested
        standards changes.  Limits suggested: three months.

        If it were necessary to extend the time for some reason, the
        IETF would have to be explicitly notified.

   o    Change minimum time at Draft Standard from 4 to 5 months, to
        ensure that an IETF meeting will intervene.

   o    There were differing suggestions on how to balance between early
        implementation of specifications available only as Internet
        Drafts, and ensuring that everyone is clear that such an
        Internet Draft has no official status and is subject to change
        at any time.  One suggestion was that vendors should not claim
        compliance with an Internet Draft.

   Finally, there were suggestions for improvements in the documentation
   of the standards procedures.

   o    Discuss the impact, if any, of export control laws on the
        Internet standardization process.

        It was observed that the Requirements RFCs contain "negative"
        requirement levels: MUST NOT and SHOULD NOT.  Such levels are
        not recognized in this Procedures document.

   o    Document needs to more clearly explain the criteria for choosing
        the Experimental vs. Informational category for an off-track
        specification.  Ref. sections 3.3.2, 3.3.4.

   o    Develop recommended wording for citations to Internet Drafts,
        which makes clear the provisional, unofficial nature of that
        document.

   o    Consider changing the name attached to a fully-adopted standard
        from "Standard" to some qualified term like "Full Standard".

   o    It has been suggested that the document should more strongly
        encourage the use of specifications from other standards bodies,
        with Internet-specific changes to be made only for compelling
        reasons.  Further, the justification of the compelling
        requirement would be subject to special review.






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


Security Considerations

   Security issues are not substantially discussed in this memo.

Author's Address

   A. Lyman Chapin
   BBN Communications Corporation
   150 Cambridge Park Drive
   Cambridge, MA  02140

   Phone: [phone]
   Fax:   [phone]

   Email: [e-mail]




































IAB                                                            [Page 23]