doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1915.txt b/doc/rfc/rfc1915.txt
new file mode 100644
index 0000000..a2dab80
--- /dev/null
+++ b/doc/rfc/rfc1915.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+Kastenholz               Best Current Practice                  [Page 3]
+
+RFC 1915                PPP ECP and CCP Variance           February 1996
+
+
+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
+
+
+
+
+
+
+Kastenholz               Best Current Practice                  [Page 4]
+
+RFC 1915                PPP ECP and CCP Variance           February 1996
+
+
+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.
+
+
+
+Kastenholz               Best Current Practice                  [Page 5]
+
+RFC 1915                PPP ECP and CCP Variance           February 1996
+
+
+     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.
+
+
+
+
+
+
+
+
+
+Kastenholz               Best Current Practice                  [Page 6]
+
+RFC 1915                PPP ECP and CCP Variance           February 1996
+
+
+     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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kastenholz               Best Current Practice                  [Page 7]
+