RFC 1915

Okay bestie, let's start with the title block 🎀 This is RFC 1915, called Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol. It was written by F. Kastenholz (that's Frank Kastenholz) at FTP Software, Inc., for the Network Working Group, and it's dated February 1996. It's a Best Current Practice (BCP: 3), so the category is Best Current Practice. It doesn't list anything it obsoletes or updates 💅

Here's the table of contents, kept exactly as written:

   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

---

Status of this Memo 📜

This doc is a Best Current Practice for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited.

1. Variance 🎀

1.1. The Problem 😭

1.1.1. History

Okay so the PPP Working Group built two protocols. The first is the Compression Control Protocol (CCP), which controls compression on PPP links, documented in draft-ietf-pppext-compression-04.txt. The second is the Encryption Control Protocol (ECP), which controls encryption on serial links, documented in draft-ietf-pppext-encryption-03.txt. While they were being developed, Motorola Corporation told the IETF they might infringe on certain patents held by Motorola, specifically U.S. patents 5,245,614 and 5,130,993 👀

Once the protocols were finished, they went to the IESG for standardization. But because of those outstanding patent claims, progress got stopped cold 🥶 Following the RFC 1602 procedures, the IESG Secretariat tried to get the licenses RFC 1602 requires. Specifically, under section 5.6 of RFC 1602, they tried to acquire a form of the license and make it publicly available via the Internet.

Motorola prefers to just give a general statement saying 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

Someone tried having the PPP Working Group write revised versions of CCP and ECP that wouldn't infringe. Technically possible ✅, but some working group members felt the changed versions were much less technically desirable than the original CCP and ECP. Those members stated pretty clearly that they'll implement the original CCP regardless of the protocol standardized by the working group or accepted by the IESG. Other members did accept the proposed changes, but mostly because it seemed like the only viable option, not because the changes were technically better. So basically, the changes didn't meet the IETF's traditional benchmark of Rough Consensus 💔

1.2. Variance to Procedures in RFC 1602 📋

Here's the variance to the RFC 1602 procedures. Section 5.6 of RFC 1602 (the relevant bits are in Appendix B) says that to use proprietary technology in an Internet Standard, the holder of the technology needs to:

1. Agree to provide the ISOC a free license to use the technology, and grant others a license to use it on fair and non-discriminatory terms.
2. Make a form of this license electronically available on the Internet.
3. Let anyone execute this license by downloading a copy of the form, fulfilling its requirements, and mailing an executed copy to the licenser.

Standards track documents aren't allowed to advance until these conditions are met. The variance in this request would let CCP and ECP advance onto the standards track without meeting the above conditions. All the community would get is 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. This lets the IESG adopt CCP and ECP as originally developed. The IESG accepts the statement by G. David Forney of Motorola, dated 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 is that the IESG would then be able to standardize CCP and ECP, and the community would gain a standardized method of controlling data compression and encryption on PPP links. The fact that this protocol has been under development for well over a year shows that the capabilities it provides are needed in the community 🧚

1.5. Perceived Risks 🚩

This variance raises the possibility that licenses aren't 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. That 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. 🚨 Read that one twice, bestie: this memo doesn't cover security at all.

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 💌

Steve Coya, Executive Director of the IETF, got this email from Motorola presenting their terms and conditions. Here it is, word for word:

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 📜

This part is the legal text, and it's super precise, so I'm keeping it word for word in a code block so nothing gets lost 🫶

5.6. Assurances 🤝

This is the assurances section from RFC 1602. It says the agreement on assurances will normally be entered into between the owner of rights and ISOC once a standards track document with claimed proprietary rights reaches the "Proposed Standard" stage of maturity. The agreement goes like this:

     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 whenever it's needed or desirable for operating under the Standards 🔥 (literally the whole point, bestie 💖). Every license has to include a clause that automatically tweaks its terms so they're as favorable as the terms of any other license under the Rights that the Rights Holder has granted previously or will grant later 👑.

A form of the license shall always be publicly accessible on the Internet (no hiding, periodt 💅). It becomes effective immediately once the member of the Internet community executes it and posts it to the Rights Holder, either by mail or electronically 📬✨. The initial version of the license is the form attached as Schedule B 🎀.

The Rights Holder says and promises (represents and warrants 🫶) that its rights are enough to let it grant the licenses and give the other assurances recited in this agreement. It also represents and warrants that it doesn't know of any rights held by any other party, in any country, that would block or impede the ability of ISOC and the Internet community to implement or operate under the Standards, or that would stop 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 🌸.