PPP CCP/ECP Variance: Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol
An IESG exception that let two PPP protocols advance despite unresolved patent licensing.
Kastenholz, F., "Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol", BCP 3, RFC 1915, DOI 10.17487/RFC1915, February 1996, <https://www.rfc-editor.org/info/rfc1915>.
@misc{rfc1915,
series = {Request for Comments},
number = 1915,
howpublished = {RFC 1915},
publisher = {RFC Editor},
doi = {10.17487/RFC1915},
url = {https://www.rfc-editor.org/info/rfc1915},
author = {F. Kastenholz},
title = {{Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol}},
pagetotal = 7,
year = 1996,
month = feb,
} RFC text
Contents
Network Working Group F. Kastenholz
Request for Comments: 1915 FTP Software, Inc.
BCP: 3 February 1996
Category: Best Current Practice
Variance for
The PPP Connection Control Protocol
and
The PPP Encryption Control Protocol
Status of this Memo
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.
Table of Contents
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
1. Variance
1.1. The Problem
1.1.1. History
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.
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.
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."
1.1.2. Other Attempted Solutions
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.
1.2. Variance to Procedures in RFC 1602
The variance to the procedures of RFC 1602 are as follows.
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.
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.
1.3. The Solution
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.
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.
1.5. Perceived Risks
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.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Frank Kastenholz
FTP Software, Inc
2 High Street
North Andover, Mass 01845-2620 USA
EMail: kasten@ftp.com
2. Appendix A -- Most Recent Communication from Motorola
The following is an email message received by Steve Coya, Executive
Director of the IETF, presenting Motorola's terms and conditions.
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>
Dear Mr. Coya:
Thank you for your e-mail message of June 1.
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:
***
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:
Mr. John A. Fisher
Vice President and Intellectual Property Licensing Counsel
Motorola, Inc.
1303 E. Algonquin Road
Schaumburg, Ill. 60196
***
I trust that this statement will be satisfactory.
Sincerely,
G. David Forney, Jr.
Vice President
3. APPENDIX B -- Relevant Section of RFC 1602
5.6. Assurances
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:
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.
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.
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.
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.
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.
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.
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.
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.
This agreement shall not be construed to obligate the ISOC to
propose, adopt, develop, or maintain any of the Standards or any
other standard.
AI ELI5
On this page
§1.1The Problem: Patents Block Two Protocols
The PPP Working Group developed two protocols. The Compression Control Protocol (CCP) controls compression on PPP links, and the Encryption Control Protocol (ECP) controls encryption on serial links. Both were finished and sent to the IESG for standardization.
During development, Motorola told the IETF that the protocols may infringe its U.S. patents 5,245,614 and 5,130,993. Because of these claims, the protocols' progress was halted.
Under the procedures of RFC 1602, the IESG Secretariat tried to obtain the required licenses, and in particular tried to acquire a form of the license and make it publicly available on the Internet. Motorola preferred a general statement that licenses will be made available to any party under reasonable terms and conditions that are demonstrably free of unfair discrimination.
Two useful tools were ready, but a company said it owned ideas inside them. The usual paperwork for using such ideas was not finished, so the tools got stuck.
§1.1.2Why Redesigning Was Not the Answer
The working group tried to write revised versions of CCP and ECP that would not infringe the patents. This was technically possible, but some members considered the changes much less desirable than the originals. They said they would implement the original CCP regardless of what the working group or the IESG standardized.
Other members accepted the changes, but mostly because it seemed the only viable alternative rather than because of the technical merit. The memo concludes that the technical changes did not reach the IETF's traditional benchmark of Rough Consensus.
Some kids offered to change the game so nobody owned a piece of it. Others said the new game was worse and they would play the old one anyway, so everyone could not agree.
§1.2What RFC 1602 Normally Requires
Section 5.6 of RFC 1602 sets three conditions for using proprietary technology in an Internet Standard. The holder must agree to give the ISOC a free license and grant others a license on fair and non-discriminatory terms. A form of this license must be made electronically available on the Internet. And anyone must be able to execute it by downloading the form, meeting its requirements, and mailing an executed copy to the licenser.
Standards track documents are not allowed to advance until these conditions are met. The variance lets CCP and ECP advance without meeting them. The community would get only an assurance from the license holder that it will make licenses available.
The normal rule asks the owner to put a ready-to-sign permission form where everyone can find it. The exception skips the form and uses a promise instead.
§1.3The Variance and the Motorola Statement
Using 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. This allows the IESG to adopt CCP and ECP as originally developed.
The IESG accepts a statement by G. David Forney of Motorola, dated 5 June 1995 and attached as Appendix A, that Motorola will make licenses available to use the technology covered by the two patents. In that email Forney called it most unusual to attach a license agreement to a standard, and proposed a short notice with Motorola's licensing contact instead.
The coach agrees to the exception and writes down the owner's promise. The owner also says a long form is not usual and suggests just giving out a phone number.
§5Perceived Benefits and Risks
The stated benefit is that the IESG can standardize CCP and ECP, giving the community a standard way to control data compression and encryption on PPP links. The memo argues the need is real because the protocol had been under development for well over a year.
The stated risk is that licenses might not be granted in a fair and non-discriminatory manner. A license holder could treat each request differently, advancing some and delaying others. The memo says this would run counter to the IETF's tradition of openness and equal access to technology.
The good part is that everyone gets a standard way to squash and scramble data. The worry is that the owner might be nicer to some people than others.
§6The Appendices
Appendix A reproduces the 5 June 1995 email from Forney to Steve Coya, Executive Director of the IETF. It says Motorola has had a license agreement available for some time and has already given it to several requesting companies.
Appendix B quotes section 5.6 of RFC 1602, the assurances agreement that the variance sets aside. Among its terms, the rights holder grants ISOC a cost-free license, and grants members of the Internet community a license for a reasonable royalty. The memo says security issues are not discussed.
At the end, the note attaches the owner's email and a copy of the usual rule, so readers can compare the promise with what was normally required.