📄 rfc1310.txt
字号:
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 withIAB [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 StandardizationIAB [Page 20]RFC 1310 Internet Standards Process March 1992APPENDIX 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 1992Security 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: 617-873-3133 Fax: 617-873-4086 Email: Lyman@BBN.COMIAB [Page 23]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -