Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol
RFC 1915

Document Type RFC - Best Current Practice (February 1996; Errata)
Also known as BCP 3
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized with errata bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1915 (Best Current Practice)
Telechat date
Responsible AD (None)
Send notices to (None)
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.

Kastenholz               Best Current Practice                  [Page 1]
RFC 1915                PPP ECP and CCP Variance           February 1996

   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.

Kastenholz               Best Current Practice                  [Page 2]
RFC 1915                PPP ECP and CCP Variance           February 1996

1.3.  The Solution
Show full document text