home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1900s / rfc1915.txt < prev    next >
Text File  |  1996-02-22  |  14KB  |  396 lines

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