home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1915.txt < prev    next >
Text File  |  1996-05-07  |  15KB  |  199 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      F. Kastenholz Request for Comments: 1915                            FTP Software, Inc. BCP: 3                                                     February 1996 Category: Best Current Practice 
  8.  
  9.                                Variance for                   The PPP Connection Control Protocol                                   and                   The PPP Encryption Control Protocol 
  10.  
  11. Status of this Memo 
  12.  
  13.    This document specifies an Internet Best Current Practices for the    Internet Community, and requests discussion and suggestions for    improvements.  Distribution of this memo is unlimited. 
  14.  
  15. Table of Contents 
  16.  
  17.    1. Variance .............................................    1    1.1 The Problem .........................................    1    1.1.1 History ...........................................    1    1.1.2 Other Attempted Solutions .........................    2    1.2 Variance to Procedures in RFC 1602 ..................    2    1.3 The Solution ........................................    3    1.4 Perceived Benefits ..................................    3    1.5 Perceived Risks .....................................    3    Security Considerations .................................    3    Author's Address ........................................    3    2. Appendix A -- Most Recent Communication from Motorola.    4    3. APPENDIX B -- Relevant Section of RFC 1602 ...........    5 
  18.  
  19. 1.  Variance 
  20.  
  21. 1.1.  The Problem 
  22.  
  23. 1.1.1.  History 
  24.  
  25.    The PPP Working group has developed two protocols, one to control    compression on PPP links; the Compression Control Protocol (CCP),    documented in draft-ietf-pppext-compression-04.txt. The second is the    Encryption Control Protocol (ECP), used to control encryption on    serial links, documented in draft-ietf-pppext-encryption-03.txt.    During the development of these protocols, the Motorola Corporation    informed the IETF that they may infringe on certain patents held by    Motorola, specificlally U.S. patents 5,245,614 and 5,130,993. 
  26.  
  27.  
  28.  
  29.  
  30.  
  31. Kastenholz               Best Current Practice                  [Page 1] 
  32.  RFC 1915                PPP ECP and CCP Variance           February 1996 
  33.  
  34.     After development of the protocols was completed, they were submitted    to the IESG for standardization. At this point, because of the    outstanding patent claims, their progress was halted. Per the    procedures of RFC 1602, the IESG Secretariat attempted to gain the    licenses required by RFC 1602. In particular, per section 5.6 of RFC    1602, an attempt was made to acquire a form of the license and make    it publically available via the Internet. 
  35.  
  36.    Motorola would prefer to provide a general statement indicating that    licenses will be made available "to any party under reasonable terms    and conditions that are demonstrably free of unfair discrimination." 
  37.  
  38. 1.1.2.  Other Attempted Solutions 
  39.  
  40.    An attempt was made to have the PPP working group develop revised    versions of CCP and ECP that would not infringe on the patents. While    technically possible, the proposed technical changes are viewed by    some members of the working group as much less technically desireable    than the original CCP and ECP and, in fact, these members have stated    quite clearly that they will implement the original CCP regardless of    the protocol standardized by the working group or accepted by the    IESG. Note that while other members of the working group accepted the    proposed changes, they did so more out of a sense that it was the    only viable alternative rather than because of the alternative's    technical merits. In short, technical changes did not meet with the    IETF's traditional benchmark of Rough Consensus. 
  41.  
  42. 1.2.  Variance to Procedures in RFC 1602 
  43.  
  44.    The variance to the procedures of RFC 1602 are as follows. 
  45.  
  46.    Section 5.6 of RFC 1602 (relevant portions are included as Appendix    B) requires that, to use proprietary technology in an Internet    Standard, the holder of the technology 1) Agree to provide the ISOC a    free license to use the technology and to grant to others a license    to use the technology on fair and non-discriminatory terms, 2) That a    form of this license be made electronically available on the    Internet, and 3) That anyone may execute this license by downloading    a copy of the form, fulfilling its requirements, and mailing an    executed copy to the licenser. Standards track documents are not    allowed to advance until these conditions are met. 
  47.  
  48.    The variance proposed in this request would allow the CCP and ECP to    advance onto the standards track without meeting the above    conditions. All that the community would obtain would be an assurance    from the license holder that it will make licenses available. 
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Kastenholz               Best Current Practice                  [Page 2] 
  55.  RFC 1915                PPP ECP and CCP Variance           February 1996 
  56.  
  57.  1.3.  The Solution 
  58.  
  59.    Within the Variance Procedure (published as RFC 1871), the IESG    grants a variance on behalf of the PPP Working Group, to the    procedures of RFC 1602 to allow the IESG to adopt the CCP and ECP as    originally developed. The IESG accepts the statement by G.  David    Forney of Motorola, date 5 June 1995, (attached as Appendix A) that    Motorola will make licenses available to use the technology covered    by U.S. patents 5,245,614 and 5,130,993. 
  60.  
  61. 1.4.  Perceived Benefits     The benefit to the community in adopting this procedure is that the    IESG would then be able to standardize the CCP and ECP and the    community would gain a standardized method of controlling data    compression and encryption on PPP links. That this protocol has been    under development for well over a year shows that the capabilities    provided by the protocol are needed in the community. 
  62.  
  63. 1.5.  Perceived Risks 
  64.  
  65.    This variance will raise the possibility that licenses are not    granted in a fair and non-discriminatory manner. The license holder,    if it were so inclined, could treat each request differently,    advancing some, delaying others, and so on. This would be counter to    the IETF's long, honorable, and successful, tradition of openness and    equal access to technology. 
  66.  
  67. Security Considerations 
  68.  
  69.    Security issues are not discussed in this memo. 
  70.  
  71. Author's Address 
  72.  
  73.    Frank Kastenholz    FTP Software, Inc    2 High Street    North Andover, Mass 01845-2620 USA 
  74.  
  75.    EMail: kasten@ftp.com 
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87. Kastenholz               Best Current Practice                  [Page 3] 
  88.  RFC 1915                PPP ECP and CCP Variance           February 1996 
  89.  
  90.  2.  Appendix A -- Most Recent Communication from Motorola 
  91.  
  92.    The following is an email message received by Steve Coya, Executive    Director of the IETF, presenting Motorola's terms and conditions. 
  93.  
  94. From: Dave_Forney-LUSE27@email.mot.com Date: 5 Jun 95 12:08:46 -0600 To: scoya@CNRI.Reston.VA.US Cc: John_Fisher-AJF003@email.mot.com, Dj_Stockley-ADS002@email.mot.com,     Ray_Wood-ARW004@email.mot.com Subject: RE: License agreement for CCP and ECP Message-Id: <"Macintosh */PRMD=MOT/ADMD=MOT/C=US/"@MHS> 
  95.  
  96.  Dear Mr. Coya: 
  97.  
  98.   Thank you for your e-mail message of June 1. 
  99.  
  100. Motorola has had a license agreement for these patents available for some time, and has already provided it to several requesting companies.  It would be most unusual, however, to attach such an agreement to a standard.  Providing contact information should suffice.  It could say something like this: 
  101.  
  102. *** Motorola, Inc. has advised the IETF that it holds two patents that it believes to be essential to the CCP and ECP standards, U.S. 5,245,614 and U.S.  5,130,993, and has declared its willingness to make licenses to these patents available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination. Parties interested in obtaining such a license may contact: 
  103.  
  104. Mr. John A. Fisher Vice President and Intellectual Property Licensing Counsel Motorola, Inc. 1303 E. Algonquin Road Schaumburg, Ill. 60196 *** 
  105.  
  106.   I trust that this statement will be satisfactory. 
  107.  
  108.   Sincerely, 
  109.  
  110.   G. David Forney, Jr.   Vice President 
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  Kastenholz               Best Current Practice                  [Page 4] 
  117.  RFC 1915                PPP ECP and CCP Variance           February 1996 
  118.  
  119.  3.  APPENDIX B -- Relevant Section of RFC 1602 
  120.  
  121. 5.6.  Assurances 
  122.  
  123. The agreement on assurances set forth below will normally be entered into between the owner of rights and ISOC at the time a standards track document in which proprietary rights are claimed reaches the "Proposed Standard" stage of maturity: 
  124.  
  125.      This is an agreement between ______________(hereinafter called "Rights Holder") and the Internet Society on behalf of itself and its trustees, officers, employees, contractors and agents, the Internet Architecture Board, Internet Engineering Steering Group, Internet Engineering Task Force, and other task forces, committees and groups coordinated by the Internet Society (hereinafter called "ISOC"), and for the benefit of all users of the Internet and users of any other networks which implement and use Internet Standards (hereinafter together with ISOC called "Internet community").  This agreement takes effect when signed on behalf of the Rights Holder and the Internet Society. 
  126.  
  127.      The Rights Holder represents that it has or will have rights in patent applications, patents, copyrights, trade secrets, and other proprietary rights in various countries (hereinafter called "Rights") which may block or impede the ability of the Internet community to implement and operate under the standards set forth in ISOC standards document ____,____, and ____(the listed standards and any similar or related standards now existing or later developed are together hereinafter called "Standards").  The Rights as they presently exist are listed on attached Schedule A. The Rights Holder further agrees to review the Rights listed in Schedule A from time to time, and, in particular, immediately prior to the elevation of the Standards to the Internet Standard level of maturity in accordance with the Internet Standards Process, and to inform the Executive Director of the Internet Engineering Task Force Secretariat promptly upon learning of any new Rights in the Standards that should be added to the list in Schedule A. 
  128.  
  129.      The Rights Holder believes and affirms that it will derive benefits by permitting ISOC and the Internet community to implement and operate under the Standards without interference of any of the Rights.  The policy of ISOC is not to propose, adopt, or continue to maintain the Standards unless written assurances are given by the Rights Holder with respect to proprietary rights. Accordingly, in consideration of the benefits noted above and other good and valuable consideration, the Rights Holder makes the assurances set forth herein. 
  130.  
  131.  
  132.  
  133. Kastenholz               Best Current Practice                  [Page 5] 
  134.  RFC 1915                PPP ECP and CCP Variance           February 1996 
  135.  
  136.       The Rights Holder grants to ISOC a cost-free, perpetual, non-exclusive, world-wide license under the Rights with respect to implementing and operating under the Standards.  The license extends to all activities of ISOC involving the Standards without limit, including the rights to reproduce, distribute, propose, test, develop, analyze, enhance, revise, adopt, maintain, withdraw, perform and display publicly, and prepare derivative works in any form whatsoever and in all languages, and to authorize others to do so.  The Rights Holder also grants ISOC permission to use the name and address of Rights Holder in connection with the Standards. 
  137.  
  138.      The Rights Holder relinquishes any right or claim in any trade secret which is part of the Rights, and makes the trade secrets available without restriction to the Internet community. The Rights Holder hereby acknowledges that ISOC assumes no obligation to maintain any confidentiality with respect to any aspect of the Standards, and warrants that the Standards do not violate the rights of others. 
  139.  
  140.      The Rights Holder assures ISOC that the Rights Holder shall grant to any member of the Internet community, as a beneficiary of this agreement, a non-exclusive, perpetual, world-wide license under the Rights, with respect to operating under the Standards for a reasonable royalty and under other terms which are reasonable considering the objective of ISOC to assure that all members of the Internet community will be able to operate under the Standards at a minimal cost.  The license discussed in this paragraph shall permit the licensee to make, have made, test, enhance, implement, and use methods, works, computer programs, and hardware as needed or desirable for operating under the Standards. Every license shall include a clause automatically modifying the terms of the license to be as favorable as the terms of any other license under the Rights previously or later granted by the Rights Holder. 
  141.  
  142.      A form of the license shall always be publicly accessible on the Internet, and shall become effective immediately when the member of the Internet community executes it and posts it for delivery to the Rights Holder either by mail or electronically. The initial version of the license shall be in the form attached as Schedule B. 
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152. Kastenholz               Best Current Practice                  [Page 6] 
  153.  RFC 1915                PPP ECP and CCP Variance           February 1996 
  154.  
  155.       The Rights Holder represents and warrants that its rights are sufficient to permit it to grant the licenses and give the other assurances recited in this agreement.  The Rights Holder further represents and warrants that it does not know of any rights of any other party in any country which would block or impede the ability of ISOC and the Internet community to implement or operate under the Standards, or that would prevent the Rights Holder from granting the licenses and other assurances in this agreement. 
  156.  
  157.      This agreement shall not be construed to obligate the ISOC to propose, adopt, develop, or maintain any of the Standards or any other standard. 
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197. Kastenholz               Best Current Practice                  [Page 7] 
  198.  
  199.