From ietf-ppp-request@MERIT.EDU Wed Jul 5 15:21:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA13158; Wed, 5 Jul 1995 15:21:32 -0400 Resent-Date: Wed, 5 Jul 1995 15:21:32 -0400 Date: Wed, 05 Jul 95 13:54:56 CST From: "Kenneth Peirce" Message-Id: <9506058049.AA804979411@robogate.usr.com> To: ietf-ppp@MERIT.EDU Subject: MP ISDN modes draft Resent-Message-ID: <"ESF5E1.0.ED3.COk-l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/564 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The following is a draft proposal for the ISDN community re: MP. It is the result of several NIUF and CIUG meetings. Please direct all flames and/or smiles to me. This proposal doesn't modify MP, it's an attempt to clarify interoperability issues for the user community. Ken 7/5/95 Ken Peirce kpeirce@usr.com Multilink PPP over ISDN: Operational Modes Recommendation Author: Kenneth Peirce, Project Leader, U.S. Robotics Access Corp 1. Motivation The goal of this creating these modes is to provide a small number of logically grouped MP option sets which will simplify user setup and reduce the number of option combinations required in vendor interoperability testing. It would also assist network administrators/buyers who need to specify an rfc compliant product in their bids. Two MP implementations can be rfc compliant, but not interoperate because the implementors chose to support different endpoint identifiers. It should be noted by the reader that these option sets are being chosen to suit ISDN. At both the NIUF and CIUG it is has been noted that suppliers were hesitant to claim interoperability between products. Reasons given included the possibility of software revision differences and the huge test matrix required given all of Multilink PPP's options. The problem of the huge matrix can be greatly reduced by the creation of specific setups that the author has chosen to call modes. Using modes, suppliers and users can quickly test the interoperability of equipment. The CIUG has agreed to post all test results that are voluntarily submitted with signatures by both suppliers. In addition to test results, code revision identifiers and equipment settings will be provided by both suppliers. A decision was made not to place any restrictions on the availability of tested equipment. The identification of code revisions will allow a user to inquire as to the current release status of a product. 2. Scope This document describes a set of operational modes for Multilink PPP(MP) when used over ISDN. These modes are effected by the utilization of certain MP options. Also, there will be a separate, similar document for PPP compression. 3. References 1. Recommendation v.120 Support by an ISDN of Data Terminal Equipment with V-series Type interface with provision for statistical multiplexing, 1992, CCITT. 2. RFC1717 The PPP Multilink Protocol(MP), Skower, Lloyd, McGregor & Carr, November 1994., available via anonymous ftp @ ds.internic.net, rfc/rfc1717.txt. 3. RFC1661 The Point-to-Point Protocol (PPP), Simpson, July 1994, available via anonymous ftp @ ds.internic.net, rfc/rfc1661.txt. 4. RFC1662 PPP in HDLC-like Framing, Simpson, July 1994, available via anonymous ftp @ ds.internic.net, rfc/rfc1662.txt. 5. RFC1618 PPP over ISDN, Simpson, July 1994, available via anonymous ftp @ ds.internic.net, rfc/rfc1618.txt. 4. Abbreviations CCP - Compression Control Protocol for PPP MP - Multilink PPP LCP - Link Control Protocol for PPP FCS - Frame Check Sum TA - ISDN Terminal Adapter NIUF - North American ISDN Users Forum CIUG - California ISDN Users Group 5. Application In this section modes are defined and the environments in which they are used are characterized. 5.1 Mode 0 Environment: ISDN Multiple B channels running synchronous PPP. ___________ _______ ___________ | System 1 |--B1--| ISDN |----|System 2 | | TE1 |__B2__| |____|TE 1 | ----------- -------- ---------- The following option set will be used with the noted values: Option Status Default Value ACCM Disabled FCS Enabled CCITT 16-bit FCS Magic Number Disabled Link Quality Monitoring Disabled Address and Field Enabled Compression Protocol Field Disabled Compression Compound Frames Disabled Self Describing Padding Disabled Maximum Receive Unit Default 1500 Max. Reconstructed Rcv. Default Size of MRU Unit Multilink Short Sequence Disabled Number Header Format by Default Endpoint Discriminator Enabled Public Switched Network Option Directory Number - Class 5 Field - by - Field Justification Note that if the following option explanations have an asterisk next to them, this indicated that the option setting is recommended in the MP RFC. 1. ACCM - The ACCM is used for octet stuffing(AKA control character escapement). The ACCM is not used in an HDLC bit stuffed environment. 2. FCS - The 16- bit CCITT checksum is the most commonly implemented and is a defacto default for PPP. 3.* Magic Number - Loopback detection is used primarily for older serial line connections. ISDN connections are virtually guaranteed never to be looped back. 4. * Link Quality Monitoring - LQM is used to monitor the quality of a point to point link. It does use the connection bandwidth to report line statistics. ISDN connections are of high enough quality that the loss of bandwidth for monitoring is not justified. 5. * Address and Control Field Compression - This compression is the omission of the two bytes of address and control information in the HDLC encapsulation of a PPP frame. The values of these bytes are static, so there is no value in transmitting them in every packet. 6. * Protocol Field compression - This compression consists of omitting a zero value protocol id byte from a packet. This byte is not subject to change so it is a logical bandwidth savings. 7. * Compound Frames - This option is not commonly implemented. 8. * Self - Describing Padding - This option is used primarily by vendors with hardware that unable to tolerate unaligned data. This option pads a packet with specially coded padding which the receiver can strip off. It is generally understood that sending unnecessary information across a WAN link is undesirable. 9. MRU - This is the default value. 10. MRRU - This is by default the current negotiated value of the MRU. 11. SSNHFO - This option allows for shorter sequence numbers in the MP packet header to save a byte in every packet. This option is not commonly implemented at this time and the savings of one byte per packet is a questionable gain for the expense of testing an additional option. 12. Endpoint Discriminator - This option allows for 6 different options. The PSNDN option could be configured by a user. Note that the calling number could be a user setup parameter and this gets around using the ANI(privacy problem). The IEEE 802.1 Globally Assigned MAC Address is also an excellent unique identifier, but this would require the inclusion of MAC EPROMS on TAs, possibly raising the cost of the TA. 5.2 Mode 1 Environments: ISDN Multiple B channels using asynchronous -to- synchronous PPP conversion TAs. ________ ____ _____ ___ _______ | W/S 1 |-----|TA|------|ISDN|------|TA|------| W/S 2| | TE2 | | |------| |------| | | TE2 | --------- ---- ------ ---- -------- async sync sync async PPP MP MP PPP The following option set will be used with the noted values: Option Status Default Value ACCM Enabled 0x00 FCS Enabled CCITT 16-bit FCS Magic Number Disabled n/a Link Quality Monitoring Disabled n/a Address and Field Enabled Compression Protocol Field Disabled Compression Compound Frames Disabled Self Describing Padding Disabled Maximum Receive Unit Default 1500 Max. Reconstructed Rcv. Default Size of MRU Unit Multilink Short Sequence Disabled n/a Number Header Format by Default Endpoint Discriminator Enabled Public Switched Network Option Directory Number - Class 5 Field - by - Field Justification Note that if the following option explanations have an asterisk next to them, this indicated that the option setting is recommended in the MP RFC. 1. ACCM - The ACCM is used for octet stuffing(AKA control character escapement). Here the ACCM exists, but uses none of the escapement mechanism. The reason it is included here is that an async-to-sync PPP converter can allow the negotiation of a null ACCM map so as to avoid having to actually monitor the asynchronous stream for escapements. This allows an older TE2 to use a serial port without the bandwidth expense of using terminal adaption such as v.120. Please see the discussion in (5)the section entitled Asynchronous to Synchronous Conversion for a full explanation. All other options are the same as in Mode 0. 5.3 Mode 2 Environments: ISDN Multiple B channels running v.120 rate adaption ________ ____ _____ ___ _______ | W/S 1 |-----|TA|------|ISDN|------|TA|------| W/S 2| | | | |------| |------| | | | --------- ---- ------ ---- -------- async v.120 v.120 async PPP MP MP PPP The following option set will be used with the noted values: Option Status Default Value ACCM Enabled 0xff FCS Enabled CCITT 16-bit FCS Magic Number Disabled n/a Link Quality Monitoring Disabled n/a Address and Field Enabled Compression Protocol Field Disabled Compression Compound Frames Disabled Self Describing Padding Disabled Maximum Receive Unit Default 1500 Max. Reconstructed Rcv. Default Size of MRU Unit Multilink Short Sequence Disabled n/a Number Header Format by Default Endpoint Discriminator Enabled Public Switched Network Option Directory Number - Class 5 Field - by - Field Justification 1. ACCM - The ACCM is used for octet stuffing(AKA control character escapement). All other options are the same as in Mode 0. 6. Operating Behavior Recommendations The following recommendations are made both to assist in avoiding peer conflicts and to allow implementors and users to choose options in an informed manner. 1. There is currently no determination made in MP as to which peer should control the creation or destruction of additional links in a bundle. The logical choice is to allow the initiator of the bundle(AKA the peer which opened the first link) to hold these rights. Additionally, if the bundle is created via a callback scheme, the peer placing the initial call should hold these rights. 2. Authentication for ISDN users should be accomplished using CHAP, as PAP has now been relegated to historical status by the IETF. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 6 17:30:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA23865; Thu, 6 Jul 1995 17:30:20 -0400 Resent-Date: Thu, 6 Jul 1995 17:30:20 -0400 From: Karl Fox Date: Thu, 6 Jul 95 17:28:03 -0400 Message-Id: <9507062128.AA01753@gefilte.MorningStar.Com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP Patent Issues In-Reply-To: <199506282338.QAA23438@combinet.com> References: <9506272036.AA02126@gefilte.MorningStar.Com> <199506282338.QAA23438@combinet.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"wlvVC.0.-n5.HN5_l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/565 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Jim Fenton writes: > In message <9506272036.AA02126@gefilte.MorningStar.Com>, Karl Fox writes: > >Does anybody know how to get the actual patent text? Does the patent > >office have a web page? :-) > > I took my copy of the patent and had it scanned in and placed on our > Web server. If you're interested in looking at the whole thing, > look in http://www.combinet.com/patent.html Thanks Jim, this helps a lot. I finally got around to reading the patent and it's now apparent to me that all the worry about what is or isn't covered by the Codex patent can easily be answered simply by reading the abstract. Here it is: Information encoded by data compression (or another data encoding technique, e.g., encryption, requiring synchronization between the encoder and decoder) is transmitted over an unreliable network by checking for transmission errors after decoding. If an error is detected, the encoder is reset, using a reset protocol which may operate over an unreliable reverse channel by using a timer to generate further reset requests when the receive does not acknowledge them in a timely fashion. The phrase `by checking for transmission errors *AFTER* decoding' is key to their claim. Without that restriction, their patent would cover not only CCP, but nearly every reliable data transmission protocol ever invented. It is clear from reading the rest of the text that they did not intend to claim any such thing. :-) However, this also means that most of the error detection schemes defined by the various CCP compression algorithms are covered by the patent, although CCP itself is not. Consequently, we (Morning Star Technologies) intend to implement Stac compression using only the Sequence-Number option of the Check-Mode parameter. We do not think that the CCP layering idea outlined in my previous message is necessary. We also hope that the authors of the various drafts will cooperate in adding such an option to their Internet Drafts so as to not offend Motorola. Of course, Vernon Schryver's BSD compress already does this, and Robert Lutz's Stac document already allows for the possibility. I especially hope Dave Rand will consider this change for Predictor, which I expect will be the most widely supported compression algorithm. If it were my choice, I would eliminate all possible schemes except for those not checked after decoding. This would mean eliminating the LCB and CRC schemes from the Stac parameters. Of course others may wish to negotiate a license with Motorola, but we currently do not, and unfortunately will not interoperate with those who will not use sequence numbers. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 6 20:51:57 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA29003; Thu, 6 Jul 1995 20:51:57 -0400 Resent-Date: Thu, 6 Jul 1995 20:51:57 -0400 Date: Thu, 6 Jul 1995 18:51:27 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507070051.SAA00896@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP Patent Issues Resent-Message-ID: <"uVImB2.0.y47.gK8_l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/566 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Karl Fox > ... We also hope that the authors of the > various drafts will cooperate in adding such an option to their > Internet Drafts so as to not offend Motorola. ... > ... I especially hope Dave > Rand will consider this change for Predictor, which I expect will be > the most widely supported compression algorithm. > ... I hope so too, but I also hope that new option numbers are chosen for such new versions of Predictor to minimize mysterious problems between old and new implementations. (There are already a lot of Predictor installations.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 7 09:38:55 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA16858; Fri, 7 Jul 1995 09:38:55 -0400 Resent-Date: Fri, 7 Jul 1995 09:38:55 -0400 From: Karl Fox Date: Fri, 7 Jul 95 09:38:05 -0400 Message-Id: <9507071338.AA01807@gefilte.MorningStar.Com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: CCP Patent Issues In-Reply-To: <199507070051.SAA00896@mica.denver.sgi.com> References: <199507070051.SAA00896@mica.denver.sgi.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"4DQQ02.0.B74.cZJ_l"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/567 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > > From: Karl Fox > > ... I especially hope Dave > > Rand will consider this change for Predictor, which I expect will be > > the most widely supported compression algorithm. > > I hope so too, but I also hope that new option numbers are chosen for > such new versions of Predictor to minimize mysterious problems between > old and new implementations. (There are already a lot of Predictor > installations.) I agree completely, unless the CCP configuration option format for Predictor also changes. We've got to have *some* way to tell the two versions apart. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 10 02:34:41 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id CAA12678; Mon, 10 Jul 1995 02:34:41 -0400 Resent-Date: Mon, 10 Jul 1995 02:34:41 -0400 From: Fred Baker Date: Sun, 9 Jul 1995 23:31:52 -0700 Message-Id: <199507100631.XAA02911@fred-ss20.cisco.com> To: ietf-ppp@MERIT.EDU Subject: PPP WG Stockholm Agenda Cc: minutes@cnri.reston.va.us Resent-Message-ID: <"1lPyn.0.j53.5dC0m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/568 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU It should come as no surprise that our agenda in Stockholm consists of: - review of intellectual property issues with our illustrious area director, Frank Kastenholtz (PPP WG Members are encouraged to have a similar discussion with the POISED working group, hint hint) - effect of same on the compression and encryption drafts - updated multilink draft - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 10 03:18:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id DAA13767; Mon, 10 Jul 1995 03:18:56 -0400 Resent-Date: Mon, 10 Jul 1995 03:18:56 -0400 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Jul 1995 00:18:11 -0700 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: Rewvised PPP WG Stockholm Agenda Cc: minutes@cnri.reston.va.us Resent-Message-ID: <"ppxln.0.uM3.UHD0m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/569 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU It should come as no surprise that our agenda in Stockholm consists of: - review of intellectual property issues with our illustrious area director, Frank Kastenholtz (PPP WG Members are encouraged to have a similar discussion with the POISED working group, hint hint) - effect of same on the compression and encryption drafts - updated encryption draft - DES encryption algorithm draft - updated multilink draft =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you're looking to find the key to the Universe, I have some bad news and some good news. The bad news is -- there is no key to the Universe. The good news is -- it has been left unlocked. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 13 17:46:44 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA26885; Thu, 13 Jul 1995 17:46:44 -0400 Resent-Date: Thu, 13 Jul 1995 17:46:44 -0400 Date: Thu, 13 Jul 95 14:46:50 PST From: Michael Zheng Message-ID: <9507131446.A16511@snail.combinet.com> To: listproc@lists.pipex.com, ietf-ppp@MERIT.EDU Subject: Callback Option of PPP Resent-Message-ID: <"O4xy_2.0.iZ6.7GP1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/570 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Text item: Text_1 I wonder if anyone can clarify a couple of things for me about the callback option of the LCP. 1. The use of conf-nak for callback: If an implementation doesn't like the "operation" in a callback confreq, presumably it confnak's it with the desired operation and leaves the "message" portion blank. Can anybody confirm this? Also, are there any implementations out there that use confnak to suggest a callback request from the peer? 2. The use of conf-rej for callback: Some of the operations (e.g., 0 and 2) are designed to work with the authentication information, which is available only after the authentication phase finishes. Therefore, the validity of the callback request is not determined till the authentication is done. As a result, those confreq should always be ack'd. And later on, depending on whether the callback is authorized or not, the callback may or may not happen. Some other operations (e.g, 1, 3 and 4) contains complete information to determine the validity of the request. If those requests are invalid (e.g., operation 1 contains unknown syntax to the called unit), should a confrej be sent right away? Notice that this behavior is different than the one above. 3. Could someone please provide a little more information about operations 2 and 4? How is operation 4 intended to be used? Thank you for your help. -mz - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 13 19:22:53 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA29798; Thu, 13 Jul 1995 19:22:53 -0400 Resent-Date: Thu, 13 Jul 1995 19:22:53 -0400 Date: Thu, 13 Jul 1995 16:22:44 -0700 Message-Id: <199507132322.QAA22580@gaia.internex.net> X-Sender: bob/larribeau.com@internex.net X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU From: bob@larribeau.com (Bob Larribeau) Subject: CIUG PPP MP Workshop Resent-Message-ID: <"eKPnl3.0.NH7.AhQ1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/571 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU To ISDN Networking Product Developers: The second California ISDN Users' Group ISDN PPP Interoperability Workshop will be held Monday, September 11 through Friday, September 15 at Pacific Bell's San Ramon Headquarters. This Workshop will be open to companies with ISDN products implementing PPP Multilink Protocol (PPP MP) and/or PPP Compression Control Protocol (PPP CCP). It will provide these companies with the opportunity to test the interoperability of their products against products from the other companies attending. The only requirement for attending this Workshop is that you bring a product implementing PPP MP and/or a PPP CCP with you test. This product must be at beta or near beta level of operation. This is not an appropriate place to test basic ISDN network connection issues. Except for the limited events on Friday described below, this Workshop will be closed to just the participants. This is an event to participate in; it is not open to observers. Some participants will be working with unreleased products and the participants are expected to respect the privacy of others. There will be no press release or publication of results from this Workshop by the CIUG. There is no charge to participate in this workshop. Participants will be responsible for bringing their own workstations, ISDN equipment, and NT1s. Pacific Bell will provide one BRI for each participant. A limited number of PRI and analog lines will also be available on request. We will focus the testing on PPP MP on Monday and Tuesday. Wednesday and Thursday will be for testing PPP CCP. Monday through Thursday will be attended only by the organizers and participants of the Workshop. Friday will include several events that will be open to other groups as described below. Fill out the attached form and email it to me at to register. Our last Workshop was attended by 25 companies. They found it to be invaluable in moving the interoperability of their products forward. We are expecting more attendees this time and may very well run out of space. Get your reservation in early to assure yourself a place. On Friday, September 15 we are planning to have three events. Participation in these events is optional. From 9 AM to 11 AM we will have a joint meeting with the North American ISDN Users' Forum (NIUF) NDIF Group. NDIF is a group of users and vendors that have been working over the last several years on PPP MP, PPP CCP, and other ISDN networking interoperability issues. Let me know if you would like to make a short presentation in this NDIF meeting on your PPP MP and CCP product plans. From 11 AM to 1 PM we will give the local press the opportunity to attend the workshop and have informal discussions with you about your plans for introducing PPP MP and PPP CCP products. There will be no press release or publication of the results of this workshop by the CIUG. The participants are free to make any announcements about their products that they wish. From 1 PM to 4 PM Pacific Bell will invite their ISDN resellers to come in to talk with you and see demonstrations of your PPP MP and PPP CCP products. Attendance on Monday through Thursday is for a couple of your engineering people who are actually working on implementing your PPP products. The sessions on Friday are open to your marketing people as well. There are a number of hotels in the San Ramon area. The San Ramon Marriott is conveniently located to Pacific Bell. Pacific Bell is at 2600 Camino Ramon in San Ramon. Camino Ramon is parallel to and just east of the 680 Freeway between the Bollinger Canyon and the Crow Canyon turn offs. You can ship your equipment to: Brent Reid Pacific Bell Room 3S451 2600 Camino Ramon San Ramon, CA 94583 Please mark "For PPP MP Testing". Schedule your equipment to arrive on September 8 or 9. Send me email or call me if you have any questions. Bob Larribeau bob@larribeau.com 415-241-9920 ---------Return-this-application-by-email--------------------------------- Name: Company: Address: Phone & Fax: email address: Describe Product: PPP options to be tested: NCP (BCP, IPCP, IPXCP, etc.): PPP MP (Yes or No): PPP CCP (Yes or No): The following lines will needed: Full time access to BRI (Yes or No): Part time access to PRI (Yes or No): Part time access to POTS (Yes or No): Participation in events on Friday, September 15: We would like to make a presentation to the NDIF group (Yes or No). We would like to meet with the press (Yes or No). We would like to participate in the Pacific Bell reseller demonstrations(Yes or No). Other comments or requirements: ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 13 21:44:02 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA03505; Thu, 13 Jul 1995 21:44:02 -0400 Resent-Date: Thu, 13 Jul 1995 21:44:02 -0400 Date: Fri, 14 Jul 1995 10:42:20 +0900 Message-Id: <199507140142.KAA04803@chisato.nd.net.fujitsu.co.jp> From: Yoshinobu Inoue To: michael@combinet.com, listproc@lists.pipex.com, ietf-ppp@MERIT.EDU Mime-Version: 1.0 Subject: Re: Callback Option of PPP Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Winbiff [version 1.07 (On Trial)] Resent-Message-ID: <"kZIyj.0.Us.VlS1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/572 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello. My comments about following issues. michael> 1. The use of conf-nak for callback: michael> michael> If an implementation doesn't like the "operation" in a callback michael> confreq, presumably it confnak's it with the desired operation and michael> leaves the "message" portion blank. Can anybody confirm this? I can't confirm but I agree. May be, only "operation" has meaning in negotiation, and "message" is a kind of advisory information. The side who don't know the adequate value of the "message" will leave it blank. michael> 2. The use of conf-rej for callback: michael> michael> Some of the operations (e.g., 0 and 2) are designed to work with michael> the authentication information, which is available only after the michael> authentication phase finishes. Therefore, the validity of the michael> callback request is not determined till the authentication is done. michael> As a result, those confreq should always be ack'd. And later on, michael> depending on whether the callback is authorized or not, the callback michael> may or may not happen. I agree. And I also think that there should be some conceptual time period between authentication phase and network layer protocol phase where it is decided if callback should happen or not as the obtained information. michael> Some other operations (e.g, 1, 3 and 4) contains complete michael> information to determine the validity of the request. If those michael> requests are invalid (e.g., operation 1 contains unknown syntax to the michael> called unit), should a confrej be sent right away? Notice that this michael> behavior is different than the one above. IMHO, it is a burden for usual machine to check syntax of the dialing string. It will be simpler if every dialing string error (including syntax error, wrong dialing number, etc) is checked on actual callback. Requester of callback will notice there is some problem if it is not called back at last. michael> 3. Could someone please provide a little more information about michael> operations 2 and 4? How is operation 4 intended to be used? RFC1700's PPP protocol number portion includes more clear difinition about those numbers. Regards, -- Yoshinobu Inoue shin@nd.net.fujitsu.co.jp Architecture Department Network Division Fujitsu Limited - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 14 10:00:24 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA22159; Fri, 14 Jul 1995 10:00:24 -0400 Resent-Date: Fri, 14 Jul 1995 10:00:24 -0400 Message-Id: <199507141333.JAA02758@funk.Funk.COM> X-Sender: ken@funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Jul 1995 10:10:15 -0400 To: ietf-ppp@MERIT.EDU From: ken@funk.com (Ken Culbert) Subject: Re: Callback Option of PPP Cc: Michael Zheng Resent-Message-ID: <"X-gqn1.0.lP5.kXd1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/573 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I wonder if anyone can clarify a couple of things for me about the > callback option of the LCP. > > 1. The use of conf-nak for callback: > > If an implementation doesn't like the "operation" in a callback > confreq, presumably it confnak's it with the desired operation and > leaves the "message" portion blank. Can anybody confirm this? We do this in our implementation (WanderLink). > Also, are there any implementations out there that use confnak to > suggest a callback request from the peer? Yes, we do this as well. > 2. The use of conf-rej for callback: > > Some of the operations (e.g., 0 and 2) are designed to work with > the authentication information, which is available only after the > authentication phase finishes. Therefore, the validity of the > callback request is not determined till the authentication is done. > As a result, those confreq should always be ack'd. And later on, > depending on whether the callback is authorized or not, the callback > may or may not happen. > > Some other operations (e.g, 1, 3 and 4) contains complete > information to determine the validity of the request. If those > requests are invalid (e.g., operation 1 contains unknown syntax to the > called unit), should a confrej be sent right away? Notice that this > behavior is different than the one above. We only support operations 0 amd 1, and will NAK for them (unless the operation is > 5 (which means 6, Microsoft's Callback Control Protocol, to which we respond with CONFIG_REJECT, since they won't negotiate anything else). When negotiating CB between our own client and server, we include user identification in a special option (assigned number 20) within the client's LCP CONFIG_REQUEST, and the server uses this information to verify the callback number, responding as appropriate. Other servers generally ACK (more or less blindly) if they support callback, then perform authentication and then callback, terminate or continue. The problem with this is that the client won't know what went wrong in the latter two cases. I had been under the impression that MS's CBCP draft was allowed to expire because the callback procedure would be revisited by the list, but there has been less than stunning enthusiasm for doing so. ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 14 13:06:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA27736; Fri, 14 Jul 1995 13:06:50 -0400 Resent-Date: Fri, 14 Jul 1995 13:06:50 -0400 Date: Fri, 14 Jul 1995 11:06:21 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507141706.LAA02911@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: CIUG PPP MP Workshop Resent-Message-ID: <"LJn7s.0.5n6.dGg1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/574 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: bob@larribeau.com (Bob Larribeau) > > To ISDN Networking Product Developers: > > The second California ISDN Users' Group ISDN PPP Interoperability Workshop > will be held Monday, September 11 through Friday, September 15 at Pacific > Bell's San Ramon Headquarters. This Workshop will be open to companies with > ISDN products implementing PPP Multilink Protocol (PPP MP) and/or PPP > Compression Control Protocol (PPP CCP). It will provide these companies > with the opportunity to test the interoperability of their products against > products from the other companies attending. > ... Gathering with other developers to test can be quite useful. However, without wanting to argue against the next CIUG workshop, there is another way that has its own attractions. A workshop lets you talk to other knowledgable people and test against many other vendors quickly, but it has some disadvangates. Less serious problems tend to be intentionally overlooked during workshop tests. Many problems, even serious ones, are not encountered during the necessarily short and simply workshop test scenarios. PPP has so many combinations of MTU, authentication, number of MP links, flavors of CCP compression, MTU, NCP, timeouts and so forth and so on that it is desirable to spend at least a day or two testing your system with each implementation before letting paying customers take their shot at it. For example, an operational part of Silicon Graphics recently got some hardware from a major hub vendor. Although at the previous San Ramon tests, SGI box and this vendor's box worked fine (although for some reason that is not reflected in the published matrix), a bug was found in the hub related to RFC 1717 and demand bandwidth. The bug, while a showstopper (and now fixed), would was unlikely to be seen in any 1-week workshop. A workshop is useful, but it is not a replacement for days of testing. In the last few weeks I've spent some time with a very few other vendors first looking for interoperatibility issues and then to resolving them. It has been handy to be able stop testing for a few days in order figure out a fix, build it, test it privately, and then test with the other vendor. It is also possible to test PPP over the Internet. For example, testing CCP-"BSD Compress" California and Austrailia over rlogin was quite effective. It was wasy to run a test and find a problem, think and make changes, and then test again days later, all on your own schedule. It was also a lot cheaper than even one airplane ticket. Besides attending workshops, I think it would be good if all vendors would have a telephone number or two available for other vendors dial up and test. MorningStar was the first that I know to have done so. There is also http://www.sgi.com/Technology/Indy_ISDN_interop_howto.html Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 14 15:42:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA02964; Fri, 14 Jul 1995 15:42:50 -0400 Resent-Date: Fri, 14 Jul 1995 15:42:50 -0400 Message-Id: Date: Fri, 14 Jul 95 12:42 PDT From: Michael Gersten To: ietf-ppp@MERIT.EDU Subject: ppp rfc's Reply-To: michael@stb.info.com Resent-Message-ID: <"agMyq1.0.5k.sYi1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/575 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ok, what is the current list of ppp relavent rfc's? Please, sort by section, i.e., all the basic protocol stuff (1661), all the framing items (1662, 1619, 1618, 1598), all the NCP's (ipcp 1663, are there others?), and any other groups that I haven't seen yet. And I thought "I speak PPP" was all I needed to know :-) Michael -- Michael Gersten michael@stb.info.com Without Prejudice, UCC 1-207 NeXT Registered Developer (NeRD) # 3860 -- Hire me! (Ready _NOW_) *** Wanted: People who are willing to work on passing an initiative in California to allow independent yes-or-no voting on each candidate for president, seperately; to replace the current vote-yes-on-one, and-no- on-all-the-others scheme. Lets end the two party system. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 14 18:08:27 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA07282; Fri, 14 Jul 1995 18:08:27 -0400 Resent-Date: Fri, 14 Jul 1995 18:08:27 -0400 Date: Fri, 14 Jul 95 15:08:20 PST From: Michael Zheng Message-ID: <9507141508.A16539@snail.combinet.com> To: ietf-ppp@MERIT.EDU, ken@funk.com Subject: Re[2]: Callback Option of PPP Resent-Message-ID: <"y2k1H2.0.Ln1.cgk1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/576 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ken, It's better to be able to reject the callback during the lcp negotiation than to ack it and then perform the authentication and probably not callback without telling the requester why. However, in order to do so, the identification of the requester must be known during the lcp phase. I like your idea of using the proprietary option 20 for that purpose. Too bad there is no generic mechanism for doing that, which would have allowed for more interoperability in that case. -mz ______________________________ Reply Separator _________________________________ Subject: Re: Callback Option of PPP Author: ken@funk.com (Ken Culbert) at Internet-Mail Date: 7/14/95 10:10 AM Received: from snail.combinet.com by cc:Mail (1.30/SMTPLink) From ken@funk.com Fri 14 Jul 1995 09:55 X-Envelope-To: michael@snail.combinet.com. Return-Path: Received: from combinet.com ([198.95.216.10]) by snail.combinet.com (SMTPSRV); F id GAA17385; Fri, 14 Jul 1995 06:59:44 -0700 Received: from ken.funk.com (machine-133.Funk.COM [198.186.160.133]) by funk.Fun Message-Id: <199507141333.JAA02758@funk.Funk.COM> X-Sender: ken@funk.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Jul 1995 10:10:15 -0400 To: ietf-ppp@merit.edu From: ken@funk.com (Ken Culbert) Subject: Re: Callback Option of PPP Cc: Michael Zheng > I wonder if anyone can clarify a couple of things for me about the > callback option of the LCP. > > 1. The use of conf-nak for callback: > > If an implementation doesn't like the "operation" in a callback > confreq, presumably it confnak's it with the desired operation and > leaves the "message" portion blank. Can anybody confirm this? We do this in our implementation (WanderLink). > Also, are there any implementations out there that use confnak to > suggest a callback request from the peer? Yes, we do this as well. > 2. The use of conf-rej for callback: > > Some of the operations (e.g., 0 and 2) are designed to work with > the authentication information, which is available only after the > authentication phase finishes. Therefore, the validity of the > callback request is not determined till the authentication is done. > As a result, those confreq should always be ack'd. And later on, > depending on whether the callback is authorized or not, the callback > may or may not happen. > > Some other operations (e.g, 1, 3 and 4) contains complete > information to determine the validity of the request. If those > requests are invalid (e.g., operation 1 contains unknown syntax to the > called unit), should a confrej be sent right away? Notice that this > behavior is different than the one above. We only support operations 0 amd 1, and will NAK for them (unless the operation is > 5 (which means 6, Microsoft's Callback Control Protocol, to which we respond with CONFIG_REJECT, since they won't negotiate anything else). When negotiating CB between our own client and server, we include user identification in a special option (assigned number 20) within the client's LCP CONFIG_REQUEST, and the server uses this information to verify the callback number, responding as appropriate. Other servers generally ACK (more or less blindly) if they support callback, then perform authentication and then callback, terminate or continue. The problem with this is that the client won't know what went wrong in the latter two cases. I had been under the impression that MS's CBCP draft was allowed to expire because the callback procedure would be revisited by the list, but there has been less than stunning enthusiasm for doing so. ============================================ Ken Culbert ken@funk.com Funk Software, Inc. voice: +1 617 497-6339 222 Third Street fax: +1 617 547-1031 Cambridge, MA 02142 http://www.funk.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 14 19:40:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA09869; Fri, 14 Jul 1995 19:40:58 -0400 Resent-Date: Fri, 14 Jul 1995 19:40:58 -0400 Date: Fri, 14 Jul 1995 17:39:13 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507142339.RAA03768@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re[2]: Callback Option of PPP Resent-Message-ID: <"dHYOY2.0.-P2.42m1m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/577 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Michael Zheng > It's better to be able to reject the callback during the lcp > negotiation than to ack it and then perform the authentication and > probably not callback without telling the requester why. However, in > order to do so, the identification of the requester must be known > during the lcp phase. I like your idea of using the proprietary > option 20 for that purpose. Too bad there is no generic mechanism for > doing that, which would have allowed for more interoperability in that > case. > ... This is not the only place where having Authentication be a separate phase from Establish is a royal pain. Other cases include MP (RFC 1717). Many things would be cleaned up if we only could use LCP Configure- Requests, -Acks and -Naks to authenticate the peer. Technically, it would be easy to put CHAP into LCP. Simply define a new option that looks a lot like a CHAP request or response, but using the LCP ID instead of the CHAP ID. The full exchange would look like: Configure-Request without new option ---> <--- Configure-Nak with new option containing name and value Configure-Ack with new option ---> containing response value and name The boundary cases of bad credentials, names, or lack of implementation on the peer are obvious. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Jul 15 17:26:04 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA08730; Sat, 15 Jul 1995 17:26:04 -0400 Resent-Date: Sat, 15 Jul 1995 17:26:04 -0400 From: bryce@bryce.com Date: Sat, 15 Jul 1995 16:25:50 -0500 Message-Id: <199507152125.QAA29026@freeside.fc.net> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Compression and Multilink To: ietf-ppp@MERIT.EDU X-Mailer: SPRY Mail Version: 04.00.06.17 Resent-Message-ID: <"B3nQh2.0.A82.Y932m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/578 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am completing a book on ISDN. A chapter concerns PPP. I need to be sure I have the most recent information on the compression issue (Motorola patent et al) and suggestions on sorces to check my understanding of compression and multilink. Thanks for your help. -- Jim ------------------------------------------------------------------ JAMES Y. BRYCE bryce@bryce.com COMMUNICATIONS TECHNOLOGY FORECASTING ISDN 512 377-4225 6103 Shoal Creek Boulevard FAX 512 454-4060 Austin, Texas 78757-3129 Voice 512 454-6788 http://www.bryce.com/~bryce PRESENTATIONS + DOCUMENTATION + CONSULTATION + SYSTEMS INTEGRATION ------------------------------------------------------------------ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 17 03:21:10 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id DAA23391; Mon, 17 Jul 1995 03:21:10 -0400 Resent-Date: Mon, 17 Jul 1995 03:21:10 -0400 From: hariram@wipinfo.soft.net (R K Hariram) Message-Id: <9507170724.AA07443@comm10.> Subject: doubts... To: ietf-ppp@MERIT.EDU Date: Mon, 17 Jul 1995 12:54:07 +0530 (IST) Reply-To: hariram@wipinfo.soft.net X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2156 Resent-Message-ID: <"oTy_C3.0.Ej5.xyW2m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/579 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, I have the following doubts regarding the rfc1717 and the MP's new internet draft. Can somebody please help me to clear the doubts? Document - rfc1717, Page - 12: "Whether or not reliable delivery is employed over member links, an implementation MUST present a signal to the NCP's running over the multilink arrangement that a loss has occurred." Question : Is this para applicable only if "PPP reliable transmission" is negotiated ? Should the signal be sent to NCP or network protocol? Also, if the B-bit fragment is lost, we can't find the network protocol of that packet and hence we cannot send a signal to any network protocol. ------------------- Document - rfc1717, Page - 14: "(1) No authentication, no discriminator: All new links MUST be joined to one bundle." Question : Why should MP allow this case? Won't it cause chaos when 2 systems communicate with a third system? Because, as per the third system, all the links correspond to one bundle (but they connect to two different systems). ------------------- Document - Internet Draft, Page - 16 : "This option is not required for multilink operation. If a system does not receive either of the Multilink MRRU or Short Sequence options, but does receive the Endpoint Discriminator Option, and there is no manual configuration providing outside information, the implementation MUST NOT assume that multilink operation is being requested on this basis alone." Question : As SSHN option alone cannot be used for negotiating MP operation in the new draft unlike in the rfc1717, the phrase "either of the Multilink MRRU or Short Sequence options" can be replaced with just "Multilink MRRU option". Is it correct? hariram.r.k. (hariram@wipinfo.soft.net) ================================================================= Office : Sr. Engr, R&D, 5th floor, Residence : c/o. R.K.Kumar, WiproInfotech, 18,Type III, CPRI Quarters, 88, MG Road, New Bel Road, Bangalore-1. Bangalore-12. Project Group : Communications Quotation : It's now or never. ================================================================= - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 17 08:41:29 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id IAA00983; Mon, 17 Jul 1995 08:41:29 -0400 Resent-Date: Mon, 17 Jul 1995 08:41:29 -0400 Date: Mon, 17 Jul 1995 05:41:09 -0700 (PDT) From: Keith Sklower Message-Id: <199507171241.FAA16154@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re: doubts ... (concerning RFC1717 revision) Resent-Message-ID: <"SsCln2.0.8F.sfb2m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/580 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RH == hariram@wipinfo.soft.net (R K Hariram) RH> Document - rfc1717, Page - 12: RH> RH> "Whether or not reliable delivery is employed over member links, an RH> implementation MUST present a signal to the NCP's running over the RH> multilink arrangement that a loss has occurred." RH> Is this para applicable only if "PPP reliable transmission" RH> is negotiated? This paragraph is applicable in ALL cases. The multilink procedure can determine that packet loss has occured due to the receipt of higher numbered packets on all links. One would hope that use of "PPP reliable transmission" would greatly reduce the instances of packet loss! (and its specification suggests that the packets Would not be delievered out of sequence to the Mutlilink Protocol). RH> Should the signal be sent to NCP or network protocol? The nature of signals and the distinction of whether it is the control or network protocols is not specified to any greater degree in the base PPP document. My understanding of it is that there is an *implementation* which forwards packets in a network protocol and uses the NCP to communicate with the peer *implementation*, so that the signal is delivered to the *implementation*. However, my reading of other PPP documents led me to believe that it was an acceptible abbreviation to use this convention. RH> Also, if the B-bit fragment is lost, we can't find the network RH> protocol of that packet and hence we cannot send a signal to any network RH> protocol. You must notify all network level protocols. RH> Document - rfc1717, Page - 14: RH> "(1) No authentication, no discriminator: RH> All new links MUST be joined to one bundle." RH> Why should MP allow this case? Won't it cause chaos when 2 systems RH> communicate with a third system? Chaos would not necessarily result in situations where the systems were connected by leased lines, or where there was some other means (such as X.25 calling party indications) to determine what the peer implementations were. In proposing protocols, one of my design tradeoffs is to allow very *simple* implmentations which can interroperate in sufficiently limited environments. If your design goal is to provide implementations which will work correctly in all environments, then you can refuse a user's instructions to attempt to set up multilink unless the user provides authentication or a discriminator. However, I will bring up the point for discussion at tomorrows PPP working group meeting. RH> Document - Internet Draft, Page - 16 : RH> "This option is not required for multilink operation. If a system RH> does not receive either of the Multilink MRRU or Short Sequence RH> options, but does receive the Endpoint Discriminator Option, and RH> there is no manual configuration providing outside information, the RH> implementation MUST NOT assume that multilink operation is being RH> requested on this basis alone." RH>Question : RH> As SSHN option alone cannot be used for negotiating MP operation in the rH> new draft unlike in the rfc1717, the phrase "either of the Multilink MRRU RH> or Short Sequence options" can be replaced with just "Multilink MRRU RH> option". Is it correct? This section was written by Tom Coradetti, so I did not remember that it needed revising once it was determined that one would never use SSHN alone. However, while your version would also be correct, the statement as it stands is not incorrect, though possibly misleading. Certainly, there is a principal of defensive programming, which suggests that you attempt to respond rationally to a system using the older, incorrect, method of indicating via SSHN alone (even though it is forbidden). - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 17 10:46:06 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA04808; Mon, 17 Jul 1995 10:46:06 -0400 Resent-Date: Mon, 17 Jul 1995 10:46:06 -0400 Date: Mon, 17 Jul 1995 08:45:36 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507171445.IAA23471@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: doubts ... (concerning RFC1717 revision) Resent-Message-ID: <"DwZFT1.0.vA1.gUd2m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/581 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Keith Sklower > RH == hariram@wipinfo.soft.net (R K Hariram) > RH> "Whether or not reliable delivery is employed over member links, an > RH> implementation MUST present a signal to the NCP's running over the > RH> multilink arrangement that a loss has occurred." > > RH> Is this para applicable only if "PPP reliable transmission" > RH> is negotiated? > > This paragraph is applicable in ALL cases. .. > RH> Should the signal be sent to NCP or network protocol? > ... > You must notify all network level protocols. The wise implementor reads such standards implementation injunctions and requirements as advice that can be freely ignored if the resulting behavor cannot be detected by a remote system. Consider a few cases: - VJ header decompression If you are receiving compressed slot numbers, you must know when a packet is lost. In this case, the "notification" can be the same as that between you HDLC hardware or software and your VJ header decompresser. In Van Jacobson's 4.3-BSD code, that notification consists of setting one bit that is checked when the next VJ header-compressed packet is decompressed. - PPP none of the PPP control protocols that I can think of care in the least to know that one of their packets has been lost. - IP Why would for your PPP code notify your IP code when PPP has lost a packet? - CCP Depending on the compression mechanism, your compression code might care or not care about such a notification. A new compression algorithm with inter-packet history might rely upon MP for sequencing and packet lost detection and not have its own. > ... > RH> "(1) No authentication, no discriminator: > RH> All new links MUST be joined to one bundle." > > RH> Why should MP allow this case? Won't it cause chaos when 2 systems > RH> communicate with a third system? > > Chaos would not necessarily result in situations where the systems > were connected by leased lines, or where there was some other means > ... Consider some cases: - you have neither discriminators nor PPP authentication but you do have authentication outside of PPP from the familiar UNIX getty/login, and you are not using MP. What does your implementation do when the peer is known to be the same or different as a peer on another non-MP link? - you have none of authentication, a discriminator, or external indications from hardware (leased line) or software (x.25 or getty), and you are not using MP? How do you know whether a new link is to a new peer or from an existing peer but where the modem has not gotten around to telling you that the link is dead? - you support a non-RFC 1717 multilink scheme such as the classic "round-robin" or "BF&I", and you rely upon address negotiation in IPCP packets to identify the peer. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jul 18 04:48:41 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id EAA03679; Tue, 18 Jul 1995 04:48:41 -0400 Resent-Date: Tue, 18 Jul 1995 04:48:41 -0400 From: hariram@wipinfo.soft.net (R K Hariram) Message-Id: <9507180851.AA01607@comm10.> Subject: NCPs in MP To: ietf-ppp@MERIT.EDU Date: Tue, 18 Jul 1995 14:21:39 +0530 (IST) Reply-To: hariram@wipinfo.soft.net X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 854 Resent-Message-ID: <"2prPf.0.Dv.wKt2m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/582 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, Does rfc1717 strictly speak that NCP MUST be run only once for a bundle and not everytime adding a link to the bundle? I could only see some loose statements like, Page 19 : "In the common case, LCP, and the Authentication Control Protocol would be negotiated over each member link. The Network Protocols themselves and associated control exchanges would normally have been conducted once, on the bundle". hariram.r.k. (hariram@wipinfo.soft.net) ================================================================= Office : Sr. Engr, R&D, 5th floor, Residence : c/o. R.K.Kumar, WiproInfotech, 18,Type III, CPRI Quarters, 88, MG Road, New Bel Road, Bangalore-1. Bangalore-12. Project Group : Communications Quotation : It's now or never. ================================================================= - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jul 18 06:26:15 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id GAA06110; Tue, 18 Jul 1995 06:26:15 -0400 Resent-Date: Tue, 18 Jul 1995 06:26:15 -0400 Date: Tue, 18 Jul 1995 03:25:52 -0700 (PDT) From: Keith Sklower Message-Id: <199507181025.DAA22969@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: re: "loose" statments concerning frequency of NCP neg. / bundle Resent-Message-ID: <"3ukhW1.0.FV1.1nu2m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/583 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: hariram@wipinfo.soft.net (R K Hariram) Hello, Does rfc1717 strictly speak that NCP MUST be run only once for a bundle and not everytime adding a link to the bundle? I could only see some loose statements like, Page 19 : "In the common case, LCP, and the Authentication Control Protocol would be negotiated over each member link. The Network Protocols themselves and associated control exchanges would normally have been conducted once, on the bundle". Sir: The statement seems pretty clear to me. I really don't understand what is loose about it. The conceptual model is that the bundle is the logical equivalent of a single PPP link layer. Adding a physical link to the bundle does not change the PPP state of the bundle. In PPP, in the single link case, you are free to renogitate a network control protocol whenever the lower-level link is in the open state. The "normal" mode of operation is that once a link reaches the open state, the network level control protocol is negotiated only once. There is no MUST in the cited paragraph. If you don't like the way something is worded, I suggest you provide an alternative. Many people have provided suggestions for alternative text on the mailing list here; sometimes I've Even adopted them ;-) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jul 18 07:38:03 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id HAA08190; Tue, 18 Jul 1995 07:38:03 -0400 Resent-Date: Tue, 18 Jul 1995 07:38:03 -0400 From: hariram@wipinfo.soft.net (R K Hariram) Message-Id: <9507181141.AA00568@comm10.> Subject: Re:Re:NCPs in MP...public domain MP? To: ietf-ppp@MERIT.EDU Date: Tue, 18 Jul 1995 17:11:43 +0530 (IST) Reply-To: hariram@wipinfo.soft.net X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1802 Resent-Message-ID: <"UFMw81.0.f_1.Jqv2m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/584 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> From: hariram@wipinfo.soft.net (R K Hariram) >> >> Hello, >> >> Does rfc1717 strictly speak that NCP MUST be run only once for a bundle >> and not everytime adding a link to the bundle? >> >> I could only see some loose statements like, >> >> Page 19 : >> "In the common case, LCP, and the Authentication Control Protocol >> would be negotiated over each member link. The Network Protocols >>themselves and associated control exchanges would normally have been >>conducted once, on the bundle". > Keith Sklower's reply : > The statement seems pretty clear to me. I really don't understand > what is loose about it. The conceptual model is that the bundle > is the logical equivalent of a single PPP link layer. Adding a > physical link to the bundle does not change the PPP state of the > bundle. In PPP, in the single link case, you are free to renogitate > a network control protocol whenever the lower-level link is in the > open state. The "normal" mode of operation is that once a link > reaches the open state, the network level control protocol is > negotiated only once. There is no MUST in the cited paragraph. > > If you don't like the way something is worded, I suggest you > provide an alternative. Many people have provided suggestions > for alternative text on the mailing list here; sometimes I've > Even adopted them ;-) > I am sorry that I didn't know, " .... In PPP, in the single link case, you are free to renogitate a network control protocol whenever the lower-level link is in the open state..... " Since I (wrongly) thought that renegotiating NCP has to bring down the link as in the case of LCP, I expected a "MUST" in the above mentioned paragraph. By the way, is anybody planning to release MP software for public domain? hariram.r.k. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 11:19:06 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA28102; Thu, 20 Jul 1995 11:19:06 -0400 Resent-Date: Thu, 20 Jul 1995 11:19:06 -0400 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jul 1995 08:17:28 -0700 To: ietf-ppp@MERIT.EDU From: fred@cisco.com (Fred Baker) Subject: PPP Minutes Resent-Message-ID: <"duMMG3.0.ms6.rEd3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/585 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Minutes of PPP WG 33 IETF 1) Frank Kastenholtz: Motorola Patent Claim Motorola has not met the requirements of RFC 1602; they have not given the IESG a blanket license for the use of their patent claims. Within the context of RFC 1602, the working group has two choices: continue to hope that the situation will change, or change the CCP and ECP drafts so that they do not infringe on the patent claims. The consensus of the working group is to remove references to the HISTORY RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all reference to resetting the history buffer is believed to obviate any claim Motorola has regarding these drafts. Action: Dave Rand to modify the CCP draft accordingly Authors of compression algorithm drafts to update drafts if necessary. Gerry Meyer to modify the ECP draft accordingly. 2) Keith Sklower: DES Electronic Codebook Encryption Algorithm Keith described his draft; the consensus was that the draft was acceptable and standardization of ECP should continue based on it. DESE is an informational draft supporting ECP. Keith indicates that the key is "derived" from the authentication/EID information; it is "derived" in the sense that one of some number of perviously configured keys is selected on the basis of that information. Consensus: change the word to "selected". If there are no other more substantive changes required (and at this point there does not appear to be) this can be handled by the RFC editor. Dave Carrel suggested that we need a way to specify and perhaps execute a key exchange algorithm in ECP; we discussed an option of the general form: +-------+-------+-------+------- | Type | Length| Code | 0 or more bytes of data +-------+-------+-------+------- Code = 1 use hard coded keys, perhaps selected via authentication/EID information (default) Code = 2 key exchange algorithm involving the data If there are several possible key exchange algorithms, they should be enumerated. This detail to be clarified in list discussion. The draft explicitly does NOT define a key exchange algorithm, and we don't particularly want to get into defining the key exchange; the objective is to enable a key exchange defined by the IP Security Group to be used. There is some belief that the EBC Mode is inadequate, that Cypher Block Feedback should be used or at least defined. This will be discussed on the list. Action: Dave to discuss key exchange on the list; if favorable consensus is formed, Gerry to update draft appropriately Upon closure of this item, Updated ECP draft ==> Proposed Standard, DESE ==> Informational 3) Keith Sklower: PPP Multilink Revision Keith reported that the california Multilink/ISDN interoperability testing prior to the Danvers indicated the desireability of a call-back control protocol to mitigate line-flapping when different systems have different criteria of when a second B-channel is needed. (Keith had volunteered to participate in such work, but not do it unilaterally). No progress has been made. Vern Schryver, in a private communication, suggested to Keith that Ascend be contacted to see if they would be willing to disclose their protocol to be used (even if only as a basis for discussion). Consensus was not to hold up RFC1717bis for inclusion of any such protocol. Revisions that the current draft embodies: Clarify: must use MMRU or MMRU+SSNHF: cannot use SSNHF alone to negotiate M/L Sequence numbers start from zero No default for MMRU; implementations MUST support MMRU=1500 No NAK of EID Must use same SNHF on all links to same peer; other links may use same or different SNHF. Revisions needed: OK to stop using M/L headers if only one link up in certain cases When second link passes LCP and Authentication, must use M/L headers and assign next fragment number to new link. Draft specifies one anonymous bundle to be used in the case of no authentication and no EID provided. RK Hariram comented on the list that this would fail in the case of one system connected to two others. The consensus already had been to allow (multiple) manually configured bundles, but the draft didn't actually say this. The draft should be change to make this clear. 4) Kevin Pierce's MP ISDN modes comment Kevin sent a longish note to the list asking for clarification of certain operating modes in PPP M/L. Some of the modes are problematic, and there seems to be no reason to include the discussion in the draft itself. Action: Keith and Kevin to correspond and settle issues. 5) Dave Carrel: EAP Draft An EAP draft was posted too late to discuss at the IETF, and the relevant people were for the most part not present. Discuss on the list. Action: Take to the list Fred Baker Chair =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you're looking to find the key to the Universe, I have some bad news and some good news. The bad news is -- there is no key to the Universe. The good news is -- it has been left unlocked. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 11:59:44 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id LAA29900; Thu, 20 Jul 1995 11:59:44 -0400 Resent-Date: Thu, 20 Jul 1995 11:59:44 -0400 From: sgw@sgw.xyplex.com (sgw) Message-Id: <9507201559.AA04726@sgw.xyplex.com> Subject: Re: PPP Minutes To: fred@cisco.com (Fred Baker) Date: Thu, 20 Jul 95 11:59:24 EDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: ; from "Fred Baker" at Jul 20, 95 8:17 am X-Mailer: ELM [version 2.3 PL8] Resent-Message-ID: <"mJ_Vi.0.zI7.krd3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/586 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU According to Fred Baker: > > Minutes of PPP WG 33 IETF > > 1) Frank Kastenholtz: Motorola Patent Claim > > Motorola has not met the requirements of RFC 1602; they have not given the > IESG a blanket license for the use of their patent claims. Within the > context of RFC 1602, the working group has two choices: continue to hope > that the situation will change, or change the CCP and ECP drafts so that > they do not infringe on the patent claims. > > The consensus of the working group is to remove references to the HISTORY > RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and > indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all > reference to resetting the history buffer is believed to obviate any claim > Motorola has regarding these drafts. > > Action: > Dave Rand to modify the CCP draft accordingly > > Authors of compression algorithm drafts to update drafts if > necessary. > > Gerry Meyer to modify the ECP draft accordingly. > (!!!Mixed emotions of shock and grief!!!) It is my belief that Stac compression, when using sequence number checkvalues, does not violate the Motorola Patent Claim. If anyone has firm evidence to the contrary, I'd like to hear it. Otherwise, I'd REALLY like Stac compression to be allowed to use sequence number checkvalues and send Reset-Req's and Reset-Ack's. No LAPB required. Issues? +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 13:47:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA03711; Thu, 20 Jul 1995 13:47:28 -0400 Resent-Date: Thu, 20 Jul 1995 13:47:28 -0400 Date: Thu, 20 Jul 1995 11:46:51 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507201746.LAA01044@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: CCP concensus Resent-Message-ID: <"sbDfg3.0.mv.eQf3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/587 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: fred@cisco.com (Fred Baker) > Minutes of PPP WG 33 IETF > > 1) Frank Kastenholtz: Motorola Patent Claim > > Motorola has not met the requirements of RFC 1602; they have not given the > IESG a blanket license for the use of their patent claims. Within the > context of RFC 1602, the working group has two choices: continue to hope > that the situation will change, or change the CCP and ECP drafts so that > they do not infringe on the patent claims. > > The consensus of the working group is to remove references to the HISTORY > RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and > indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all > reference to resetting the history buffer is believed to obviate any claim > Motorola has regarding these drafts. > > Action: > Dave Rand to modify the CCP draft accordingly > > Authors of compression algorithm drafts to update drafts if > necessary. > > Gerry Meyer to modify the ECP draft accordingly. > ... It is regularly said that the IETF is unlike other standards groups. One item in those claims is that the IETF operates by consensus and that consensus is not determined only at meetings in distant cities, that email is a major part of reaching concensus. In this case, how was it determined that consensus on requiring LAPB for CCP was reached? Who attended the Stockholm meeting? Was there any consideration of the alternative of having the CCP standard say that HISTORY RESET REQUEST and HISTORY RESET RESPONSE should be handled in the order that avoids the Motorola patent? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 14:55:42 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA06144; Thu, 20 Jul 1995 14:55:42 -0400 Resent-Date: Thu, 20 Jul 1995 14:55:42 -0400 Date: Thu, 20 Jul 95 14:51:29 EDT Message-Id: <9507201851.AA20829@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: PPP Minutes. From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: kasten+iesg@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Jul 20 14:51:19 1995] Originating-Client: d-cell.ftp.com Content-Length: 992 Resent-Message-ID: <"DMrb63.0.gV1.5Qg3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/588 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > The consensus of the working group is to remove references to the HISTORY > > RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and > > indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all > > reference to resetting the history buffer is believed to obviate any claim > > Motorola has regarding these drafts. > > (!!!Mixed emotions of shock and grief!!!) > > It is my belief that Stac compression, when using sequence number checkvalues, > does not violate the Motorola Patent Claim. If anyone has firm evidence to > the contrary, I'd like to hear it. Otherwise, I'd REALLY like Stac compression > to be allowed to use sequence number checkvalues and send Reset-Req's > and Reset-Ack's. No LAPB required. Issues? steve the patent problem is with ccp. it is not with ccp-running-compression-type-x. any proposal to resolve this impasse must get ccp published, not just ccp-running-x i'm terribly sorry. frank kastenholz internet area co-director - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 15:10:24 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA07086; Thu, 20 Jul 1995 15:10:24 -0400 Resent-Date: Thu, 20 Jul 1995 15:10:24 -0400 From: sgw@sgw.xyplex.com (sgw) Message-Id: <9507201910.AA05390@sgw.xyplex.com> Subject: Re: PPP Minutes. To: kasten@ftp.com Date: Thu, 20 Jul 95 15:10:24 EDT Cc: ietf-ppp@MERIT.EDU, kasten+iesg@ftp.com In-Reply-To: <9507201851.AA20829@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jul 20, 95 2:51 pm X-Mailer: ELM [version 2.3 PL8] Resent-Message-ID: <"l5fpI3.0.Jk1.Seg3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/589 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU According to Frank Kastenholz: > > > the patent problem is with ccp. > it is not with ccp-running-compression-type-x. > any proposal to resolve this impasse must get ccp published, > not just ccp-running-x > > i'm terribly sorry. > > frank kastenholz > internet area co-director > > Does this mean that draft-ietf-pppext-stacker-XX.txt could/should specify Reset-Request and Reset-Ack? Basically move the lingo from CCP to CCP-Stac? +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 15:35:20 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA08187; Thu, 20 Jul 1995 15:35:20 -0400 Resent-Date: Thu, 20 Jul 1995 15:35:20 -0400 Date: Thu, 20 Jul 1995 15:34:44 -0400 From: John Shriver Message-Id: <199507201934.PAA13061@shiva-dev.shiva.com> To: ietf-ppp@MERIT.EDU Subject: Re: CCP concensus Resent-Message-ID: <"s8DE21.0.i_1.r_g3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/590 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We have no intention of implementing HDLC under CCP. We don't have the compute or memory resources available. (The compressors and decompressors use quite enough memory and computes, thank you.) This decision leaves what may become the CCP RFC a complete sham, which will have no bearing on reality, which is that everyone will implement the present Internet Draft. Who are we to judge that HDLC is not an unreliable link? If the link reorders packets, HDLC is VERY unreliable. When it fails, the CCP's will be reinitialized. Is that not a "resetting of said method"? Why can we make these judgements relative, but not others relative to, the applicability or validity of this patent? We have judged that HDLC is a not a "unreliable network". Why can't we judge that we do not add error detection information "to said data prior to encoding said data"? Any of these judgements of the validity or relevance of a patent appears to violate RFC 1602 section 5.4.2(B). Shall we publish an informational RFC with the "deprecated" Reset Request and Reset Response messages? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 15:36:49 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA08369; Thu, 20 Jul 1995 15:36:49 -0400 Resent-Date: Thu, 20 Jul 1995 15:36:49 -0400 From: Karl Fox Date: Thu, 20 Jul 95 15:35:56 -0400 Message-Id: <9507201935.AA09370@gefilte.MorningStar.Com> To: kasten@ftp.com Cc: ietf-ppp@MERIT.EDU, kasten+iesg@ftp.com Subject: PPP Minutes. In-Reply-To: <9507201851.AA20829@mailserv-D.ftp.com> References: <9507201851.AA20829@mailserv-D.ftp.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"CEK4P.0.W22.E1h3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/591 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank Kastenholz writes: > the patent problem is with ccp. > it is not with ccp-running-compression-type-x. ... > frank kastenholz > internet area co-director This is incorrect; the problem is with any CCP-running-compression-type-x that uses information after decoding in its decision to send Reset-Request packets. The Codex patent clearly states this. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 16:46:37 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA11155; Thu, 20 Jul 1995 16:46:37 -0400 Resent-Date: Thu, 20 Jul 1995 16:46:37 -0400 Date: Thu, 20 Jul 1995 14:45:01 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507202045.OAA01796@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: the other Motorola patent Resent-Message-ID: <"zaE_N2.0._j2.f2i3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/592 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Is it true that everyone agrees that the other Motorola patent covers Van Jacobson TCP/IP header compression? Why don't we need to remove the negotiation of VJ header compression from IPCP? This is not a rhetorical question. If the right answer for CCP and ECP is not just to avoid the Motorola patent but to remove all vestiges of what might have infringed if things were not changed, then why isn't something similar necessary for VJ header compression, where no one claims there is a way to avoid the patent? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 16:58:36 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id QAA11635; Thu, 20 Jul 1995 16:58:36 -0400 Resent-Date: Thu, 20 Jul 1995 16:58:36 -0400 Date: Thu, 20 Jul 1995 16:57:46 -0400 From: John Shriver Message-Id: <199507202057.QAA16386@shiva-dev.shiva.com> To: karl@MorningStar.Com CC: ietf-ppp@MERIT.EDU, kasten+iesg@ftp.com In-reply-to: <9507201935.AA09370@gefilte.MorningStar.Com> (message from Karl Fox on Thu, 20 Jul 95 15:35:56 -0400) Subject: Re: PPP Minutes. Resent-Message-ID: <"7q7mQ1.0.ar2.vDi3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/593 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The ugly reality is that CCP is the Internet Draft that Motorola filed its claim on. Given the weakenesses of the RFC 1602 procedures, we are forced to lobotomize or abandon the Internet Draft. (Not that I agree with this, but the bug isn't here, it's in POISED!) I suppose we could put the reset packets in each of the compressor drafts, and if Motorola fails to object before they reach full standard, we can ignore it by the same broken RFC 1602 rules. (The rules only state that you can't go to standard AFTER someone files a patent claim on the draft/RFC.) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 17:05:08 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA12222; Thu, 20 Jul 1995 17:05:08 -0400 Resent-Date: Thu, 20 Jul 1995 17:05:08 -0400 From: Karl Fox Date: Thu, 20 Jul 95 17:04:24 -0400 Message-Id: <9507202104.AA10203@gefilte.MorningStar.Com> To: John Shriver Cc: ietf-ppp@MERIT.EDU, kasten+iesg@ftp.com Subject: Re: PPP Minutes. In-Reply-To: <199507202057.QAA16386@shiva-dev.shiva.com> References: <9507201935.AA09370@gefilte.MorningStar.Com> <199507202057.QAA16386@shiva-dev.shiva.com> Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"ui5SN2.0.d-2.0Ki3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/594 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU John Shriver writes: > The ugly reality is that CCP is the Internet Draft that Motorola filed > its claim on. > > Given the weakenesses of the RFC 1602 procedures, we are forced to > lobotomize or abandon the Internet Draft. (Not that I agree with > this, but the bug isn't here, it's in POISED!) I posted a sketch of a mechanism that would solve this. Everyone would have to change their implementations, and all the drafts would have to change, but the general architecture would remain largely the same. > I suppose we could put the reset packets in each of the compressor > drafts, and if Motorola fails to object before they reach full > standard, we can ignore it by the same broken RFC 1602 rules. (The > rules only state that you can't go to standard AFTER someone files a > patent claim on the draft/RFC.) I'm fairly sure they wouldn't object if we removed the part about resetting based on decoded information. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 17:15:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id RAA12818; Thu, 20 Jul 1995 17:15:19 -0400 Resent-Date: Thu, 20 Jul 1995 17:15:19 -0400 Date: Thu, 20 Jul 1995 17:14:38 -0400 From: John Shriver Message-Id: <199507202114.RAA17065@shiva-dev.shiva.com> To: vjs@mica.denver.sgi.com CC: ietf-ppp@MERIT.EDU In-reply-to: <199507202045.OAA01796@mica.denver.sgi.com> (vjs@mica.denver.sgi.com) Subject: Re: the other Motorola patent Resent-Message-ID: <"K5DqU2.0.383.aTi3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/595 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Date: Thu, 20 Jul 1995 14:45:01 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) To: ietf-ppp@MERIT.EDU Subject: the other Motorola patent Is it true that everyone agrees that the other Motorola patent covers Van Jacobson TCP/IP header compression? Well, if the patent is valid (big assumption), it probably does apply. Why don't we need to remove the negotiation of VJ header compression from IPCP? Because Motorola chose not to file a "claim" against that RFC. (Probably they didn't see any potential commercial gain by doing so, or excessive political scorn within the IETF.) Also, the RFC 1602 procedures were developed by people too naive to think of the issue of stealth (unissued) patents, etc. They idealistically assume that nobody could file a claim against an RFC after it is published, or reaches Internet Standard state. You can't attain "patent purity." Also, RFC 1144 was published 2/1/1990. I'm sure it was available as an Internet Draft for some time before that. The source code in it is Copyright 1989. The application date of the offensive Motorola patent is 12/29/1989. Thus, the VJ stuff is almost certainly prior art. (Interesting that it is not cited as such -- that's another fault in the patent -- failing to cite relevant prior art!) Therefore, as prior art, they can't do a thing about it. (You DON'T need to go to patent court over that. The court would throw it out.) On the other hand, VJ's code may also invalidate some claims of the Motorola patent... This is not a rhetorical question. If the right answer for CCP and ECP is not just to avoid the Motorola patent but to remove all vestiges of what might have infringed if things were not changed, then why isn't something similar necessary for VJ header compression, where no one claims there is a way to avoid the patent? Because RFC 1602 is silly, and POISED needs to get off their butt and come up with something more pragmatic and realistic. Vernon Schryver, vjs@sgi.com John Shriver, jas@shiva.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 19:07:58 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id TAA16594; Thu, 20 Jul 1995 19:07:58 -0400 Resent-Date: Thu, 20 Jul 1995 19:07:58 -0400 Message-Id: <199507202306.QAA02307@anik.skylinetech.com> X-Sender: abbott@anik.skylinetech.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jul 1995 16:08:06 -0800 To: bob@larribeau.com From: ken@anik.skylinetech.com (Kenneth Abbott) Subject: Which CCP are we testing? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"CcT_Q2.0.234.x6k3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/596 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The PPP Working Group minutes just arrived, and the recommendation for CCP is to have it run over LAPB. Yuck, but OK---we have LAPB code. The question is: what will we be testing in September at the MP bake-off? I am interested in testing compression interoperability, but I don't know what other vendors are planning to test. Can you act as a clearinghouse for what vendors will be testing with respect to this Motorola patent claim on the current draft CCP? Ken Abbott >Minutes of PPP WG 33 IETF ... >The consensus of the working group is to remove references to the HISTORY >RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and >indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all >reference to resetting the history buffer is believed to obviate any claim >Motorola has regarding these drafts. Ken Abbott ken@skylinetech.com Skyline Technology, Inc. voice: (408) 457-5636 Santa Cruz, CA fax: (408) 457-5637 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 20:58:23 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id UAA19646; Thu, 20 Jul 1995 20:58:23 -0400 Resent-Date: Thu, 20 Jul 1995 20:58:23 -0400 Date: Thu, 20 Jul 1995 18:57:40 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507210057.SAA03056@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Which CCP are we testing? Cc: bob@larribeau.com Resent-Message-ID: <"Q9-Rk3.0.ko4.gkl3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/597 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > To: bob@larribeau.com > From: ken@anik.skylinetech.com (Kenneth Abbott) > Cc: ietf-ppp@MERIT.EDU > > The PPP Working Group minutes just arrived, and the recommendation for CCP > is to have it run over LAPB. Yuck, but OK---we have LAPB code. The > question is: what will we be testing in September at the MP bake-off? I am > interested in testing compression interoperability, but I don't know what > other vendors are planning to test. Can you act as a clearinghouse for > what vendors will be testing with respect to this Motorola patent claim on > the current draft CCP? > ... - anyone at any vendor working on CCP that has not already dealt with the Motorola patents has failed to do due diligence. I have no reason to think that anyone has been that derelict. - Silicon Graphics will not support LAPB PPP encapsulation in the foreseeable future. - Silicon Graphics will continue to ship CCP code with Reset-Request/Ack. - I bet the freeware ppp-2.1.2 continues to support Reset-Request/Ack. - I bet Silicon Graphics is typical, but if not, we'll make the most of the consequent advantage in the market. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Jul 20 21:52:40 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA21405; Thu, 20 Jul 1995 21:52:40 -0400 Resent-Date: Thu, 20 Jul 1995 21:52:40 -0400 X-Sender: larribeau-1@menlopark01.pop.internex.net X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ken@anik.skylinetech.com (Kenneth Abbott), bob@larribeau.com From: "Bob Larribeau" Subject: Re: Which CCP are we testing? Cc: ietf-ppp@MERIT.EDU Date: Thu, 20 Jul 1995 16:58:49 -0700 Message-ID: <19950720235848.AAA28692@junior> Resent-Message-ID: <"eir0e2.0.AE5.bXm3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/598 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I will collect the information for this information for the participants in the CIUG workshop. I will add a question to the application form asking if CCP will be run over LAPB or not. Let me know if I should ask anything else. Bob Larribeau CIUG At 04:08 PM 7/20/95 -0800, Kenneth Abbott wrote: >The PPP Working Group minutes just arrived, and the recommendation for CCP >is to have it run over LAPB. Yuck, but OK---we have LAPB code. The >question is: what will we be testing in September at the MP bake-off? I am >interested in testing compression interoperability, but I don't know what >other vendors are planning to test. Can you act as a clearinghouse for >what vendors will be testing with respect to this Motorola patent claim on >the current draft CCP? > >Ken Abbott > >>Minutes of PPP WG 33 IETF >... >>The consensus of the working group is to remove references to the HISTORY >>RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and >>indicate that CCP SHOULD run over reliable PPP (LAPB). Removing all >>reference to resetting the history buffer is believed to obviate any claim >>Motorola has regarding these drafts. > >Ken Abbott ken@skylinetech.com >Skyline Technology, Inc. voice: (408) 457-5636 >Santa Cruz, CA fax: (408) 457-5637 > > > ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 01:15:56 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id BAA26603; Fri, 21 Jul 1995 01:15:56 -0400 Resent-Date: Fri, 21 Jul 1995 01:15:56 -0400 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jul 1995 22:14:26 -0800 To: John Shriver From: fred@cisco.com (Fred Baker) Subject: Re: PPP Minutes. Cc: karl@morningstar.com, ietf-ppp@MERIT.EDU, kasten+iesg@ftp.com Resent-Message-ID: <"V_Vfn1.0.SV6.8Wp3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/600 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 4:57 PM 7/20/95, John Shriver wrote: >Not that I agree with >this, but the bug isn't here, it's in POISED! Please help POISED get the rules right. Please. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you're looking to find the key to the Universe, I have some bad news and some good news. The bad news is -- there is no key to the Universe. The good news is -- it has been left unlocked. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 01:15:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id BAA26573; Fri, 21 Jul 1995 01:15:38 -0400 Resent-Date: Fri, 21 Jul 1995 01:15:38 -0400 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Jul 1995 22:14:46 -0800 To: sgw@sgw.xyplex.com (sgw) From: fred@cisco.com (Fred Baker) Subject: Re: PPP Minutes Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"kgagm2.0.-U6.tVp3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/599 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:59 AM 7/20/95, sgw wrote: >(!!!Mixed emotions of shock and grief!!!) don't ask... >It is my belief that Stac compression, when using sequence number checkvalues, >does not violate the Motorola Patent Claim. If anyone has firm evidence to >the contrary, I'd like to hear it. Otherwise, I'd REALLY like Stac compression >to be allowed to use sequence number checkvalues and send Reset-Req's >and Reset-Ack's. No LAPB required. Issues? If someone can put together an argument that is guaranteed to stand up in a court of law, I'm all ears. Seriously. The recommendation of the AD is to change things so that CCP+procedures do not infringe on the patent claims *regardless*of*anyones*opinion*of*their*validity*. If this does not infringe, it is a better way forward. But it really truly has to not infringe. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you're looking to find the key to the Universe, I have some bad news and some good news. The bad news is -- there is no key to the Universe. The good news is -- it has been left unlocked. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 02:45:52 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id CAA29380; Fri, 21 Jul 1995 02:45:52 -0400 Resent-Date: Fri, 21 Jul 1995 02:45:52 -0400 Date: Fri, 21 Jul 95 02:44:57 EDT From: rms@zircon.acc.com (Ron Stoughton) Message-Id: <9507210644.AA04516@zircon.acc.com> To: bob@larribeau.com, ken@anik.skylinetech.com Subject: Re: Which CCP are we testing? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"IF43e3.0.rA7.Tqq3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/601 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > The PPP Working Group minutes just arrived, and the recommendation for CCP > is to have it run over LAPB. Yuck, but OK---we have LAPB code. We have LAPB code too, but I sure don't want to have to run it under CCP in order to do data compression on PPP links. ACC runs the same STAC-based compression algorithm over all WAN links, not just PPP. In the case of PPP, we use CCP for negotiation and encapsulation, but have no need for RESET/RESET ACK (we have our own in-band mechanism to maintain history synchronization). We would not be happy to have to run CCP over LAPB. This should be dependent on the actual compression algorithm negotiated. If the problem is with RESET/RESET ACK, remove it from CCP and let the individual compression algorithms deal with synchronization. Some may require a reliable undercarriage, some may not. There have already been suggestions how one might tap dance around the specifics of the Motorola patent. Ron Stoughton - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 03:58:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id DAA01350; Fri, 21 Jul 1995 03:58:19 -0400 Resent-Date: Fri, 21 Jul 1995 03:58:19 -0400 Message-Id: <199507210756.AA08840@keks.netcs.com> Subject: CCP and LAPB To: ietf-ppp@MERIT.EDU Date: Fri, 21 Jul 1995 09:56:41 +0200 (MEST) From: Oliver Korfmacher X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 472 Resent-Message-ID: <"o1G5W3.0.pK.Our3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/602 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What happens to the CCP if the LAPB code says reset due to unrecoverable losses? I.e., if the LAPB stack generates an reset indication to the upper layer indicating that some data was lost. Probably, a CCP reset procedure follows. Does this violate any patent issue? Or shouldn't I mention this? Oliver Gruesse, Oliver Korfmacher Oliver Korfmacher (okorf@netcs.com, whois OK11 URL: http://www.netcs.com/PEOPLE/okorf.html) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 04:13:43 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id EAA02160; Fri, 21 Jul 1995 04:13:43 -0400 Resent-Date: Fri, 21 Jul 1995 04:13:43 -0400 Date: Fri, 21 Jul 1995 01:13:19 -0700 (PDT) From: Keith Sklower Message-Id: <199507210813.BAA10288@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Forwarded request (Possible for bilateral testing?) Resent-Message-ID: <"5ZjYL1.0.XX.q6s3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/603 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Please reply to this fellow directly, not to me From uunet-in!uuimas!aranya.hclhprnd.uunet.in!bbm@uunet.uu.net Thu Jul 20 08:58:03 1995 Subject: A request..... To: sklower@CS.Berkeley.EDU Date: Thu, 20 Jul 1995 16:37:59 +0530 (IST) From: "Bharathi Mohan" Cc: bbm@aranya.hclhprnd.uunet.in (Bharathi Mohan) Content-Type: text Dear Keith Sklower, I am B. Bharathi Mohan working in HCL-Hewlett Packard(R & D), Madras(India). We are looking forward to implement the PPP-Multi Link protocol. We are also looking for a product which has implemented the PPP-Multi Link Protocol. We have searched in some of the leading magazines and product manuals. But we couldn't get any concrete information. I would be happy if you could provide any information regarding this. My e-mail address is bbm@aranya.hclhprnd.uunet.in Looking forward to your reply, Regards, B. Bharathi Mohan (bbm@aranya.hclhprnd.uunet.in) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 09:32:15 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id JAA10290; Fri, 21 Jul 1995 09:32:15 -0400 Resent-Date: Fri, 21 Jul 1995 09:32:15 -0400 From: Karl Fox Date: Fri, 21 Jul 95 09:30:57 -0400 Message-Id: <9507211330.AA15164@gefilte.MorningStar.Com> To: fred@cisco.com (Fred Baker) Cc: sgw@sgw.xyplex.com (sgw), ietf-ppp@MERIT.EDU Subject: Re: PPP Minutes In-Reply-To: References: Reply-To: Karl Fox Organization: Morning Star Technologies, Inc. Resent-Message-ID: <"crsFZ2.0.SW2.Qnw3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/604 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Fred Baker writes: > At 11:59 AM 7/20/95, sgw wrote: > >It is my belief that Stac compression, when using sequence number > >checkvalues, does not violate the Motorola Patent Claim. > > If someone can put together an argument that is guaranteed to stand up in a > court of law, I'm all ears. Seriously. The recommendation of the AD is to > change things so that CCP+procedures do not infringe on the patent claims > *regardless*of*anyones*opinion*of*their*validity*. If this does not > infringe, it is a better way forward. But it really truly has to not > infringe. This is an impossible recommendation, which, by the way, is one that neither you nor the AD have followed. We have no ultimate control over the opinions of others, so we must most reasonably do what Jesus said to do concerning compression patents: "Stop judging by mere appearances, and make a right judgment." If one reads the patent summary and its claims, it becomes clear that 1) CCP using Reset Request/Ack does not infringe if the Reset Request is not sent based on information that becomes available after decoding, and 2) CCP over a reliable protocol does not infringe. We therefore have at least two reasonable choices, one that clearly does not infringe but requires LAP-B, or one that clearly does not infringe but requires only minimal changes which have been described in this forum before. Why would we choose the harder road? What possible reason could cause such a choice? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 10:35:54 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA12342; Fri, 21 Jul 1995 10:35:54 -0400 Resent-Date: Fri, 21 Jul 1995 10:35:54 -0400 From: sgw@sgw.xyplex.com (sgw) Message-Id: <9507211434.AA18619@sgw.xyplex.com> Subject: Re: PPP Minutes To: fred@cisco.com (Fred Baker) Date: Fri, 21 Jul 95 10:34:56 EDT Cc: ietf-ppp@MERIT.EDU In-Reply-To: ; from "Fred Baker" at Jul 20, 95 10:14 pm X-Mailer: ELM [version 2.3 PL8] Resent-Message-ID: <"hvvTK3.0.O03.Xix3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/605 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU According to Fred Baker: > > If someone can put together an argument that is guaranteed to stand up in a > court of law, I'm all ears. Seriously. The recommendation of the AD is to > change things so that CCP+procedures do not infringe on the patent claims > *regardless*of*anyones*opinion*of*their*validity*. If this does not > infringe, it is a better way forward. But it really truly has to not > infringe. > Has anyone thought about what happens when you do CCP above Multilink? Multilink is hardly a reliable protocol. Do all the member links of the bundle have to run LAPB? Is Multilink then "reliable"? +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Scott G. Wasson sgwasson@eng.xyplex.com | | Xyplex, Internetworking & Media Voice: (508) 952-4746 | | 295 Foster St. Littleton, MA 01460 Fax: (508) 952-4887 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Jul 21 14:40:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id OAA19955; Fri, 21 Jul 1995 14:40:28 -0400 Resent-Date: Fri, 21 Jul 1995 14:40:28 -0400 Date: Fri, 21 Jul 1995 12:39:45 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507211839.MAA04585@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PPP Minutes. Resent-Message-ID: <"S1zkc1.0.at4.PI_3m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/606 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ] From: fred@cisco.com (Fred Baker) ] ] Please help POISED get the rules right. Please. POISED has been dragging on for a very long time with no apparent result. Could anyone be interested in retaining the current rules? | From: fred@cisco.com (Fred Baker) | | >It is my belief that Stac compression, when using sequence number checkvalues, | >does not violate the Motorola Patent Claim. If anyone has firm evidence to | >the contrary, I'd like to hear it. ... | If someone can put together an argument that is guaranteed to stand up in a | court of law, I'm all ears. Seriously. The recommendation of the AD is to | change things so that CCP+procedures do not infringe on the patent claims | *regardless*of*anyones*opinion*of*their*validity*. If this does not | infringe, it is a better way forward. But it really truly has to not | infringe. No such guarantee is possible without going to court. If you cannot read the patent and see what it says about the order of error detection and decoding, nothing short of a court judgement will do. I received a suggestion that Silicon Graphics sue Motorola. My answer was that if I were to push the SGI lawyers, it would be against the IETF/IESG/ISOC, not just Motorola. Remember the saga: - after a long effort, a standard is developed. - Motorola quietly tells the IESG about a bogus patent. - the IESG very quietly blocks progress on the standard. - word of the problem leaks out after about 6 months and the relevant standards are modified to avoid the patent, despite its bogosity. - the IESG drags its feet for a long time. - the IETF tries to destroy the standard. Some time ago I received the following about the Motorola efforts from an inside source: ] I heard it stated that Motorola's goal in ] this whole thing was to prevent compression technology from being used ] in routers, so as to keep it from competing with [Motorola's] compressing ] CSU/DSUs. Obvious questions are whether anyone in the IETF/IESG/ISOC knew that and who is employed by Motorola. Regardless of those thoughts, note that Motorola is not the only outfit threatend by compressing PPP. Consider any outfit in the TCP software, PPP software, or router business without a CCP product. (I currently, personally have no opinion on the validity of those suspicions. They are only speculations to try to explain actions that are otherwise difficult to understand. The cliche about infering malice instead of incompetance is probably relevant.) While I think legal actions would be unprofitable for SGI (my code is free and not part of the main business), the many outfits out here include some that have used the courts to maximize the value of their corporate assets. Think about which stand to lose the most from these IETF/IESG/ISOC actions, the outfits that sell compression licenses. For example, this action by the IETF/IESG/ISOC could prevent Stac from receiving license fees from Silicon Graphics. (This is not a promise to add or not add LZS to the SGI PPP product. This is not a promise to not sue nor a threat to sue. I'm not a lawyer and have not consulted the corporate lawyers on this, and so my guesses about legal issues are unreliable. Consult your lawyers.) > From: Oliver Korfmacher > > What happens to the CCP if the LAPB code says reset due to unrecoverable > losses? I.e., if the LAPB stack generates an reset indication to the upper > layer indicating that some data was lost. > Probably, a CCP reset procedure follows. Does this violate any patent > issue? > Or shouldn't I mention this? You're getting close to some of the evidence for a suit against the IETF/IESG/ISOC. Since I made the same point years ago, so they cannot claim ignorance. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Jul 23 12:55:16 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA22420; Sun, 23 Jul 1995 12:55:16 -0400 Resent-Date: Sun, 23 Jul 1995 12:55:16 -0400 From: cicat@cicat.com Message-Id: <199507231654.MAA22387@merit.edu> X-Sender: cicat@cicat.com X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ietf-ppp@MERIT.EDU Subject: Compression algorithms Date: Sun, 23 Jul 95 12:56:35 Eastern Daylight Time--100 X-Info: CICAT NT Mail Server X-Mailedby: NT SMTP/LISTSERVER v2.10 (ntmail@net-shopper.co.uk) Resent-Message-ID: <"2zwdR.0.zT5.0xd4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/607 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Are there any public domain compression algorithms that can be used over PPP, and if so are there any sources for sample source code for these algorithms (similar to what's available for MD5)? Also, could somebody tell me if it is possible to get the entry points for compression algorithms from companies like Stac without having to buy a license. I just want to know what the interface function calls are. Thanks. Kevin Dunetz CICAT Networks - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Jul 23 13:35:28 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id NAA23624; Sun, 23 Jul 1995 13:35:28 -0400 Resent-Date: Sun, 23 Jul 1995 13:35:28 -0400 Date: Sun, 23 Jul 1995 10:34:46 -0700 From: Fred Baker Message-Id: <199507231734.KAA20899@stilton.cisco.com> To: cicat@cicat.com Subject: Re: Compression algorithms Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"SPkOn3.0.qm5.TXe4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/608 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Are there any public domain compression algorithms that can be used over > PPP, and if so are there any sources for sample source code for these > algorithms (similar to what's available for MD5)? No, there are not. The Predictor Algorithm is probably as close as you're going to get, and its (a) not much of an algorithm and (b) subject to a patent somewhere or another, specifics of which escape me. > Also, could somebody > tell me if it is possible to get the entry points for compression > algorithms from companies like Stac without having to buy a license. I > just want to know what the interface function calls are. Contact Stac and see what you can negotiate. If it were me, I would wonder aloud where you were getting my code if you weren't getting it from me - if you haven't got the code to call, why do you need the interfaces? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Jul 23 15:05:33 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id PAA25888; Sun, 23 Jul 1995 15:05:33 -0400 Resent-Date: Sun, 23 Jul 1995 15:05:33 -0400 Date: Sun, 23 Jul 1995 13:04:47 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507231904.NAA02511@mica.denver.sgi.com> To: cicat@cicat.com Subject: Re: Compression algorithms Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"YaUUe2.0.GK6.srf4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/609 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Fred Baker > To: cicat@cicat.com > Cc: ietf-ppp@MERIT.EDU > > > Are there any public domain compression algorithms that can be used over > > PPP, and if so are there any sources for sample source code for these > > algorithms (similar to what's available for MD5)? > > No, there are not. The Predictor Algorithm is probably as close as you're > going to get, and its (a) not much of an algorithm and (b) subject to a > patent somewhere or another, specifics of which escape me. Predictor is less effective than other choices, but it does about 2:1. Predictor is far better than nothing. Given the choice between a modem using v.42bis (LZW) and doing Predictor in the host, I would probably choose Predictor in the host. Predictor and v.42bis simultaneously is clearly better than v.42bis alone. Predictor may covered by U.S. patent 5,229,768 (Thomas). However, that patent is said by some lawyers to not be drafted very well. It also does not mention what might be the prior art described in the Predictor draft. (i.e. talk to your own lawyers) "BSD Compress" is in the freeware ppp-2.2. The code is free, (as is the code in the BSD Compress draft). It might or might be covered by the Unisys declaration that freeware LZW is free as far as Unisys is concerned. If built for a UNIX box, it might be covered by whatever lets you have BSD `compress` command on the box and use `compress` for network stuff like netnews. (i.e. talk to your own lawyers). Paul Mackerras wrote a few weeks ago in comp.protocols.ppp: ] paulus@cs.anu.edu.au <3svm8h$3du@sirius.anu.edu.au> ] ... The second beta release of ppp-2.2 ] is available now by anonymous ftp from dcssoft.anu.edu.au as ] ppp-2.2b2.tar.gz in directory pub/ppp. There are changes to the ] SunOS, AIX, OSF/1, NetBSD, Linux, Ultrix and Solaris 2 ports. As with ] ppp-2.2b1, for information on the NeXT port, look at the web page ] http://www.thoughtport.com:8080/PPP/ or contact Steve Perkins ] (perkins@cps.msu.edu). > > Also, could somebody > > tell me if it is possible to get the entry points for compression > > algorithms from companies like Stac without having to buy a license. I > > just want to know what the interface function calls are. > > Contact Stac and see what you can negotiate. If it were me, I would wonder > aloud where you were getting my code if you weren't getting it from me - if > you haven't got the code to call, why do you need the interfaces? I have been told by people working for other companies that it is possible to build an over-the-wire-compatible PPP-LZS compatible implementation that does not infringe on the Stac Electronics patents. My response was that while that might be true (or not, I don't know), the Stac license fees are not high enough to risk having to prove as much in court. (i.e. talk to your own lawyers) Vernon Schryver, vjs@sgi.com P.S. remember the good old days when programming did not require spending more time with lawyers than with a keyboard? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 24 00:04:50 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id AAA08580; Mon, 24 Jul 1995 00:04:50 -0400 Resent-Date: Mon, 24 Jul 1995 00:04:50 -0400 Date: Mon, 24 Jul 95 00:03:56 EDT From: rms@zircon.acc.com (Ron Stoughton) Message-Id: <9507240403.AA05279@zircon.acc.com> To: cicat@cicat.com, ietf-ppp@MERIT.EDU Subject: Re: Compression algorithms Resent-Message-ID: <"1Bo_A1.0.r52.Iln4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/610 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Also, could somebody > tell me if it is possible to get the entry points for compression > algorithms from companies like Stac without having to buy a license. I > just want to know what the interface function calls are. The data sheets for the Stac data compression library describe the user interface. I am sure you can obtain these without buying a license. I am at home right now and don't have Stac's phone number or address handy. Bob Lutz reads this mail list, and I assume he will respond to your query. Ron Stoughton - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 24 10:07:19 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA22952; Mon, 24 Jul 1995 10:07:19 -0400 Resent-Date: Mon, 24 Jul 1995 10:07:19 -0400 Date: Mon, 24 Jul 95 10:01:01 EDT Message-Id: <9507241401.AA09332@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: the other Motorola patent From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Jul 24 10:00:42 1995] Originating-Client: d-cell.ftp.com Content-Length: 1495 Resent-Message-ID: <"u6fmD3.0.Ub5.rXw4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/611 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Is it true that everyone agrees that the other Motorola patent covers > Van Jacobson TCP/IP header compression? > > Why don't we need to remove the negotiation of VJ header compression > from IPCP? > > This is not a rhetorical question. If the right answer for CCP and ECP > is not just to avoid the Motorola patent but to remove all vestiges of > what might have infringed if things were not changed, then why isn't > something similar necessary for VJ header compression, where no one > claims there is a way to avoid the patent? Have any formal claims from the patent holder been filed? I hate to say this, but if the patent holder makes a formal claim, (and the issue does not get resolved) then something bad might happen. I'm afraid that I can't say more since since one of the broken parts of 1602 is that it does not cover what happens if someone comes in with a claim _after_ standardization. Vern, all of your issues and concerns _are_ valid and I do agree with your general sentiments. But they affect more than just PPP protocols (eg, someone recently joked to me that he had a patent that covered IPv6 -- which I passed along in humor to some of the IESG. The IESG folks asked me to properly investigate whether this "claim" was for real...) Please, bring these issues and concerns to the poised working group, the IESG (well, I guess I count on that one :-), the IAB and the ISOC Board. While they have been raised before, repetition is the key to learning. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 24 10:07:37 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA22965; Mon, 24 Jul 1995 10:07:37 -0400 Resent-Date: Mon, 24 Jul 1995 10:07:37 -0400 Date: Mon, 24 Jul 95 10:01:16 EDT Message-Id: <9507241401.AA09339@mailserv-D.ftp.com> To: ietf-ppp@MERIT.EDU Subject: CCP concensus From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: kasten+iesg@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Jul 24 10:01:06 1995] Originating-Client: d-cell.ftp.com Content-Length: 1194 Resent-Message-ID: <"IRMq91.0.pb5.7Yw4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/612 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU First, the minutes report what happened in the working group meeting. The consensus at the meeting in Stockholm was exactly as Fred reported. In fact, I think that Fred was being rather understated in his report -- after my presentation and a discussion of the issues, I would say that while there was dislike of the solution (including me) there was no disagreement. Second, before final actions are taken, I as the responsible Area Director, and the IESG as a whole, will need to gauge consensus of the _entire_ working group, including the folks on the mailing list. You can be assured that your comments _will_ figure prominently in this process. Third, I perceive that your basic complaint is not with the "lets change CCP to avoid the patent claim" but rather with the specific approach taken. The approach is because, frankly, being on the IESG, it is not inconceivable that I (along with the rest of the IESG) be named in any possible patent infringement lawsuits over this matter, regardless of who actually infringes. Because of this exposure, I'd prefer that we take as safe a course as we possibly can yet still get a CCP out there. Frank Kastenholz Internet Area Co-Director - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 24 10:10:33 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id KAA23450; Mon, 24 Jul 1995 10:10:33 -0400 Resent-Date: Mon, 24 Jul 1995 10:10:33 -0400 Date: Mon, 24 Jul 95 10:00:39 EDT Message-Id: <9507241400.AA09321@mailserv-D.ftp.com> To: jas@shiva.com Subject: Re: PPP Minutes. From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: karl@MorningStar.Com, ietf-ppp@MERIT.EDU, kasten+iesg@ftp.com Sender: kasten@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Jul 24 10:00:20 1995] Originating-Client: d-cell.ftp.com Content-Length: 891 Resent-Message-ID: <"78A_l2.0.Bk5.Ldw4m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/613 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > The ugly reality is that CCP is the Internet Draft that Motorola filed > its claim on. > > Given the weakenesses of the RFC 1602 procedures, we are forced to > lobotomize or abandon the Internet Draft. (Not that I agree with > this, but the bug isn't here, it's in POISED!) John, This is correct. I urge anyone on the PPP list who is dissatisfied with the current state of affairs with regard to the intellectual property issues in general, or the CCP/ECP patent issues in specific, to make their views known on the POISED working group mailing list (I think that it's poised@tis.com). Suggestions for revisions to 1602 would be even more valuable. The corrolary of this is let's not waste the time of the folks on the PPP mailing list with commentary on 1602. The folks on POISED are much more "useful" targets for these flames :-) Frank Kastenholz Internet Area Co-Director - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Jul 24 18:00:32 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id SAA08516; Mon, 24 Jul 1995 18:00:32 -0400 Resent-Date: Mon, 24 Jul 1995 18:00:32 -0400 Message-Id: <0k51T830GRliALEBRb@chaos> Date: Mon, 24 Jul 1995 14:59:36 -0700 (PDT) From: Jay Laefer To: ietf-ppp@MERIT.EDU Subject: Re: CCP concensus Resent-Message-ID: <"GyLWu.0.j42.jV15m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/614 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Frank Kastenholz writes: : Second, before final actions are taken, I as the responsible Area : Director, and the IESG as a whole, will need to gauge consensus of : the _entire_ working group, including the folks on the mailing list. : You can be assured that your comments _will_ figure prominently in : this process. Well, I can safely say that our company will not implement CCP if we also have to implement LAPB except under extraordinary duress. This is not, to us, an acceptable workaround for the patent. If everyone on in the WG agrees that CCP-over-LAPB is the only way to go, then we'll consider it, but for now we're not implementing either the CCP draft or LAPB. -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Jul 25 12:46:51 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id MAA06773; Tue, 25 Jul 1995 12:46:51 -0400 Resent-Date: Tue, 25 Jul 1995 12:46:51 -0400 Date: Tue, 25 Jul 1995 10:42:55 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199507251642.KAA07210@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: CCP concensus Resent-Message-ID: <"3k2B61.0.bf1.f_H5m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/615 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: kasten@ftp.com (Frank Kastenholz) > First, the minutes report what happened in the working group meeting. > The consensus at the meeting in Stockholm was exactly as Fred > reported. In fact, I think that Fred was being rather understated in > his report -- after my presentation and a discussion of the issues, I > would say that while there was dislike of the solution (including me) > there was no disagreement. I have no doubt that the concensus at the Stockholm meeting was accurately reported. The obvious question is "who was there?" One of the problems with any standards committee meetting is that the attendance tends to be skewed away from implementors and others with knowledge of the issues. Add a few thousand miles, several time zones, an extra day of traveling, several US$1000 extra in travel expenses, and the skew is worse. Is there a list of those present at the PPP working group meeting? From the mailing list, everyone with the exception of Frank Kastenholz and the possible exception of Fred Baker disagrees with the claimed concensus. "No disagreement" might mean no more than that Frank Kastenholz drove a proposal through a group of spectators with only academic interests in the issue. Who thinks it is necessary to use LAPB to avoid the Motorola patent besides Frank Kastenholz and perhaps Fred Baker? Name names. > Second, before final actions are taken, I as the responsible Area > Director, and the IESG as a whole, will need to gauge consensus of > the _entire_ working group, including the folks on the mailing list. > You can be assured that your comments _will_ figure prominently in > this process. > > Third, I perceive that your basic complaint is not with the "lets > change CCP to avoid the patent claim" but rather with the specific > approach taken. The approach is because, frankly, being on the IESG, > it is not inconceivable that I (along with the rest of the IESG) be > named in any possible patent infringement lawsuits over this matter, > regardless of who actually infringes. Because of this exposure, You should think about all of your exposures. There is an obvious theory involving you and FTP Software and no harm to Motorola that might convince a jury. As you know, your proposal to require LAPB is not needed to avoid the Motorola patent. Changing RFC 1602 would not shield you from Motorola lawyers if Motorola had a leg to stand on, so your efforts to kill CCP cannot be rationalized on those grounds. That Motorola has not formally notified the IESG that VJ header compression infringes on their other bogus patent does not shield you from actions by Motorola, since you already know that it infringes. That implies that you do in fact consider the validity of patents when worrying about your exposure. > I'd > prefer that we take as safe a course as we possibly can yet still get > a CCP out there. A CCP protocol that requires LAPB is dead, as well as not necessary to avoid the Motorola patent. You personally have not tried to get a CCP out there, but instead you tried to kill the protocol. Why? The following response is both reasonable and predictable. Consider its effects on Stac Electronics revenues. ] From: Jay Laefer ] Well, I can safely say that our company will not implement CCP if we ] also have to implement LAPB except under extraordinary duress. This is ] not, to us, an acceptable workaround for the patent. ] ] If everyone on in the WG agrees that CCP-over-LAPB is the only way to ] go, then we'll consider it, but for now we're not implementing either ] the CCP draft or LAPB. Talk about POISED is irrelevant to the change you've pushed. The purpose of the PPP working gorup is not to produce documents whose only use is to give the ISEG something to approve. If the Motorola patents and RFC 1602 mean that CCP cannot be advanced, then the right response is to not advance it. It is wrong to try to substitute a useless protocol that was rejected years ago by the working group. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Jul 26 21:48:38 1995 Received: (from slist@localhost) by merit.edu (8.6.12/merit-2.0) id VAA02577; Wed, 26 Jul 1995 21:48:38 -0400 Resent-Date: Wed, 26 Jul 1995 21:48:38 -0400 Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@MERIT.EDU From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-eap-auth-01.txt Date: Wed, 26 Jul 95 17:15:49 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9507261715.aa15788@IETF.CNRI.Reston.VA.US> Resent-Message-ID: <"lM5YZ2.0.2e.T1l5m"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/616 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht Filename : draft-ietf-pppext-eap-auth-01.txt Pages : 20 Date : 07/25/1995 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eap-auth-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eap-auth-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (192.12.192.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-auth-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950725162100.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-auth-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-auth-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950725162100.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - -