From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 3 07:03:02 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11303; Mon, 3 May 93 06:49:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13958; Mon, 3 May 93 06:30:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10665; Mon, 3 May 93 06:01:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10367; Mon, 3 May 93 05:44:36 -0700 Received: by ftp.com id AA21584; Mon, 3 May 93 08:44:08 -0400 Date: Mon, 3 May 93 08:44:08 -0400 Message-Id: <9305031244.AA21584@ftp.com> To: thatcher@rahul.net Subject: Re: some clarification is requested From: kasten@ftp.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.ucdavis.edu, thatcher@rahul.net > 2. Since there is only 1 interface for each instance of PPP, is there > a way to disable bridgePPP (or any other network protocol) while > supporting other network protocols? The PPP/Bridge MIB provides a way > to disable based on mediaType and interface. This is effective only at > the next link restart. Look at pppIpConfigAdminStatus and pppBridgeConfigAdminStatus. These objects inject open and close events into the related NCP's FSM. Presumably, as more NCPs get "mibbed", each will have such an object. > 3. Each network protocol has its own NCP for PPP. I assume that each > NCP has it's own associated mib (as the Bridge and IP do). There does > not seem to be any seperate counters for the various protocol types > processed by the PPP. Are these assumed to be counted by each client? > Is there any need in counting PPP frames by protocol type? Actually, only the IP and Bridge NCPs have been MIB'ed. A year ago the working group considered having lots of counters as you suggest (bytes/packets in/out by protocol type). After some consideration, the idea was dropped as there did not seem that these objects would be useful for diagnosing network problems. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 3 13:26:46 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18136; Mon, 3 May 93 12:33:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20345; Mon, 3 May 93 12:07:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17209; Mon, 3 May 93 11:50:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bolero.rahul.net by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16575; Mon, 3 May 93 11:20:20 -0700 Received: by bolero.rahul.net id AA27006 (5.65c/IDA-1.4.4 for ietf-ppp@ucdavis.edu); Mon, 3 May 1993 11:19:55 -0700 From: Thatcher Consulting Services Message-Id: <199305031819.AA27006@bolero.rahul.net> Subject: Re: some clarification is requested To: ietf-ppp@ucdavis.ucdavis.edu Date: Mon, 3 May 93 11:19:54 PDT Cc: thatcher@rahul.net In-Reply-To: <9305031244.AA21584@ftp.com>; from "Frank Kastenholz" at May 3, 93 8:44 am I appreciate the response to questions 2 and 3. (I was wondering how to interpret 'open' and 'closed' for the pppIpConfigAdminStatus and pppBridgeConfigAdminStatus> I am still looking for some clarification to the first question. Let me ask it in a different way. When incrementing the counters associated with the interface for a PPP instance, do the counters count the information coming from/going to the PPP Client or the info coming from/going to the physical link (RS-232-C for instance)? If the former what about PPP generated traffic? If the latter, do the octet counters include the counts before or after stripping out/adding in any asynchronous control characters (commonly referred to as byte stuffing). Mike Thatcher@rahul.com From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 3 17:37:35 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24699; Mon, 3 May 93 17:11:19 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25083; Mon, 3 May 93 16:42:52 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23374; Mon, 3 May 93 16:11:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22538; Mon, 3 May 93 15:37:17 -0700 Received: by ftp.com id AA27144; Mon, 3 May 93 18:36:56 -0400 Date: Mon, 3 May 93 18:36:56 -0400 Message-Id: <9305032236.AA27144@ftp.com> To: thatcher@rahul.net Subject: Re: some clarification is requested From: kasten@ftp.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.ucdavis.edu, thatcher@rahul.net > I am still looking for some clarification to the first question. Let me ask it > in a different way. When incrementing the counters associated with the > interface for a PPP instance, do the counters count the information > coming from/going to the PPP Client or the info coming from/going to the > physical link (RS-232-C for instance)? If the former what about PPP generated > traffic? If the latter, do the octet counters include the counts before or > after stripping out/adding in any asynchronous control characters (commonly > referred to as byte stuffing). For an interface, the Case diagram looks something like: +-----------------------------------------------------+ | ===OutPackets /|\ | | | === InPackets | | | | | | ===OutOctets | | | \|/ === InOctets | +-----------------------------------------------------+ So, for two "interfaces", stacked "one on top of the other", it would look like: +-----------------------------------------------------+ | ===OutPackets /|\ | | | === InPackets | | | | | | ===OutOctets | | | \|/ === InOctets | +-----------------------------------------------------+ | ===OutPackets /|\ | | | === InPackets | | | | | | ===OutOctets | | | \|/ === InOctets | +-----------------------------------------------------+ So, if the top "interface" represents the PPP protocol engine on an RS-232 port and the bottom "interface" represents the RS-232 port, the answers are: > When incrementing the counters associated with the > interface for a PPP instance, do the counters count the information > coming from/going to the PPP Client or the info coming from/going to the > physical link (RS-232-C for instance)? Packets are those for delivery to the upper layers or received from the upper layers for delivery to the network Byte counts are for the actual bytes received from the net or sent onto the net. The RS-232 layer could be diddled (I suppose) to count packets received from the higher layer or delivered to the higher layer. > If the former what about PPP generated traffic? Only the bytes are counted. > If the latter, do the octet counters include the counts before or > after stripping out/adding in any asynchronous control characters (commonly > referred to as byte stuffing). After. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 4 15:06:30 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08348; Tue, 4 May 93 14:32:12 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07490; Tue, 4 May 93 14:13:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07284; Tue, 4 May 93 13:57:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05866; Tue, 4 May 93 13:02:20 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA14326; Tue, 4 May 93 13:01:50 PDT Date: Tue, 4 May 93 13:01:50 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9305042001.AA14326@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: some clarification is requested >> When the stream goes through a sync/async converter, the async can see >> all of the idle octets, but should not count them. >> >> We need this to be documented somewhere. What is a good place to put >> this information? Each MIB? A separate summary document? The "main" >> LCP MIB document? I would suggest that that be in the MIB description of the octet counter, whether it is somewhere else or not. The other "obvious" place to document it is where sync/async converters are discussed, which I believe would be in the LCP document. My opinion. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 4 15:35:09 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09206; Tue, 4 May 93 15:02:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07923; Tue, 4 May 93 14:39:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07612; Tue, 4 May 93 14:06:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06369; Tue, 4 May 93 13:23:43 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA14357; Tue, 4 May 93 13:23:17 PDT Date: Tue, 4 May 93 13:23:17 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9305042023.AA14357@saffron.acc.com> To: vsp@NSD.3Com.COM Subject: Re: PPP Sessions at July IETF Cc: ietf-ppp@ucdavis.ucdavis.edu >> I would like to know the agenda for PPP and joint PPP/IPLPDN working >> groups sessions for the July meeting in Amsterdam. Venkat: Your private question is of general interest, so I will presume to answer it publicly. In the PPP meeting, we will be discussing status of a number of documents (hopefully short), and going on to discuss: son of RFC 1220 Rich Bowen (IBM) compression Dave Rand (Novell) reliable links Dave Rand (Novell) multi-link procedures Keith Sklower (Berkeley) various AppleTalk Brad Parker (FCR? I thought it was Cayman? Is the whois server broken?) As to the joint meetings, I have not touched base with George Clapp as yet, so he may have agenda items unknown to me. We called the meeting, however, because: IPLPDN is specifically interested in Keith's work, so it may occur during the joint session instead of the PPP session. IPLPDN is also making some modifications to use the PPP state machine; these modifications are the primary purpose of the joint meeting. In both meetings, other subjects may come up. I am specifically expecting some discussion of PPP on ISDN. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 5 08:42:55 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10525; Wed, 5 May 93 08:21:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02871; Wed, 5 May 93 08:00:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09290; Wed, 5 May 93 07:31:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08524; Wed, 5 May 93 07:04:13 -0700 Received: by ftp.com id AA10902; Wed, 5 May 93 10:03:47 -0400 Date: Wed, 5 May 93 10:03:47 -0400 Message-Id: <9305051403.AA10902@ftp.com> To: bill.simpson@um.cc.umich.edu Subject: Re: some clarification is requested From: kasten@ftp.com (Frank Kastenholz) Cc: ietf-ppp@ucdavis.ucdavis.edu Bill, et al, It is not clear that you need to have this information exported via the MIB. Remember, the early version (pre San Diego) of the MIB included a zillion counters for stuff like this. We decided that said MIB was way too big and that these counters really did not provide any useful ability for diagnosing network problems. They fell in the "nice to have" category. Please do not confuse MIB information with "other" information. > We talked about these counters with regard to PPP Link Quality > Monitoring a year and a quarter ago. LQM needs an accurate count of > packets, including PPP generated packets. It also needs a count of > We need this to be documented somewhere. What is a good place to put > this information? Each MIB? A separate summary document? The "main" > LCP MIB document? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 5 18:35:17 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28937; Wed, 5 May 93 18:21:30 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12878; Wed, 5 May 93 18:00:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27630; Wed, 5 May 93 17:32:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from stemwinder.fcr.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26511; Wed, 5 May 93 17:00:24 -0700 Received: from localhost.fcr.com by stemwinder.fcr.com (4.1/SMI-4.1) id AA11776; Wed, 5 May 93 19:50:54 EDT Message-Id: <9305052350.AA11776@stemwinder.fcr.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: LAPB Date: Wed, 05 May 1993 19:50:54 -0400 From: Brad Parker Could the gentleman from Novell who spoke about LAPB at the last IETF please send me email? Sorry, I lost your card. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 7 07:19:04 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18331; Fri, 7 May 93 06:52:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04397; Fri, 7 May 93 06:30:08 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17695; Fri, 7 May 93 06:03:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gateway.ameritech.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17550; Fri, 7 May 93 05:54:43 -0700 Received: from [144.148.1.5] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA04662; Fri, 7 May 93 07:50:24 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Fri, 7 May 93 07:24 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Fri, 7 May 93 07:25 CDT Message-Id: From: clapp@ameris.center.il.ameritech.com (George H. Clapp) Subject: agenda for IPLPDN meeting in Amsterdam To: vsp@NSD.3Com.COM (Venkat Prasad), iplpdn@nri.reston.va.us (IPLPDN WG), ietf-ppp@ucdavis.ucdavis.edu (Point-to-Point Protocol) Date: Fri, 7 May 93 7:25:30 CDT Cc: mdavies@nri.reston.va.us (Megan Davies) >I would like to know the agenda for the July meeting at Amsterdam >for the IPLPDN and joint PPP/IPLPDN sessions At this time, both the IPLPDN and PPPEXT WGs have the same sessions scheduled as during the March IETF meeting in Columbus. I'm not certain, but I hope that the IP over ATM WG and the VC-ROUTING WG (formerly a BOF) will have the same schedules as before so there won't be any overlap. Monday, July 12 4:00-6:00 pm - Status of RFC 1356, Multiprotocol over X.25 - Encapsulation Discrimination over Circuit Switched Services - Simple Multilink Procedure Tuesday, July 13 9:30-12:00 noon - Parameter Negotiation for the Multiprotocol Interconnect 4:00-6:00 pm, Joint Session with PPPEXT WG - Simple Multilink Procedure - Parameter Negotiation for the Multiprotocol Interconnect Wednesday, July 14 9:30-12:00 noon, Joint Session with PPPEXT WG - Simple Multilink Procedure - Parameter Negotiation for the Multiprotocol Interconnect There has been discussion on the mail lists prompted by Joel Halpern about Address Resolution and the "shortcut" issues. Previous discussions had this work going to the IP over ATM WG, with the understanding that solutions must work across the different public data services (Frame Relay, SMDS, ATM, circuit and packet ISDN). Please consider this a first pass at an agenda and let me know if you have any suggested changes. Thanks, George Clapp email: clapp@ameris.center.il.ameritech.com work: 708-248-6507 fax: 708-248-6038 From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 7 12:09:24 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24844; Fri, 7 May 93 11:25:58 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10082; Fri, 7 May 93 10:52:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22760; Fri, 7 May 93 10:00:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gateway.ameritech.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21648; Fri, 7 May 93 09:24:35 -0700 Received: from [144.148.1.5] by gateway.Ameritech.COM with SMTP (5.65/25-eef) id AA05170; Fri, 7 May 93 11:20:18 -0500 Received: by gus.n26.wi.ameritech.com (3.1.18.1) id ; Fri, 7 May 93 11:20 CDT Received: by ameris.center.il.ameritech.com (/\==/\ Smail3.1.22.1 #22.6) id ; Fri, 7 May 93 11:18 CDT Message-Id: Date: Fri, 7 May 93 11:18 CDT To: iplpdn@nri.reston.va.us (IPLPDN WG), ietf-ppp@ucdavis.ucdavis.edu (PPP Extensions WG) From: clapp@ameris.center.il.ameritech.com (George Clapp) Subject: Re: BONDING imux interoperability >This posting is just to announce that the first BONDING inverse >multiplexing interoperability test has completed demonstrating >interoperability among nine (9) vendors using the BONDING inverse >multiplexing specification. I recall that there was some discussion of using BONDING as an alternative to the "Simple Multilink Procedure," which operates at the data link rather than the physical layer. The current proposal for the multilink procedure uses the fragmentation and reassembly scheme in RFC 1294. My concern with the approach is the amount of overhead. RFC 1294 uses a double encapsulation. The packet is first prepended with a SNAP header indicating the protocol. It is then segmented and each segment is prepended with a SNAP header indicating the fragmentation protocol. Also, I understand that many implementors fragment packets regardless of the size of packet. This adds up to a lot of overhead for small packets, and throughput becomes a question. The BONDING approach is done at the physical layer so the protocol overhead is eliminated. Is there any interest in including BONDING in our approach to aggregating multiple B channels? Thanks, George Clapp phone: 708-248-6507 fax: 708-248-6038 email: clapp@ameris.center.il.ameritech.com George Clapp phone: 708-248-6507 fax: 708-248-6038 email: clapp@ameris.center.il.ameritech.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 7 14:33:53 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28458; Fri, 7 May 93 14:02:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12919; Fri, 7 May 93 13:31:38 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27053; Fri, 7 May 93 13:04:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nic.cerf.net by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26379; Fri, 7 May 93 12:33:11 -0700 Received: from [134.24.7.202] (rberger.cerfnet.com) by nic.cerf.net (4.1/CERFnet-1.0) id AA11488; Fri, 7 May 93 12:33:45 PDT Message-Id: <9305071933.AA11488@nic.cerf.net> Date: Fri, 7 May 1993 12:30:07 -0800 To: George Clapp From: rberger@cerf.net (Robert Berger) X-Sender: rberger@nic.cerf.net Subject: Re: BONDING imux interoperability Cc: IPLPDN WG , PPP Extensions WG >The BONDING approach is done at the physical layer so the protocol >overhead is eliminated. > >Is there any interest in including BONDING in our approach to >aggregating multiple B channels? Yes! It makes much sense. From what I understand though, it requires some hardware support and there may be some Terminal Adapter or PRI interfaces that can not handle it. Also I understand that there isn't one BONDING implementation (surprise!) The standard has a mechanism to support several flavors (sound familiar :-). But I do think its very important that the IPLPDN integrate with BONDING, especially for the long run. Robert J. Berger InterNex Information Services 935 College Ave. Menlo Park, CA 94025 Voice: 415-327-6038 FAX: 415-327-6416 Internet: rberger@cerf.net From ietf-ppp-request@ucdavis.ucdavis.edu Sat May 8 14:01:22 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15619; Sat, 8 May 93 13:46:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21655; Sat, 8 May 93 13:30:06 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15149; Sat, 8 May 93 13:01:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from fernwood.mpk.ca.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14942; Sat, 8 May 93 12:46:29 -0700 Received: by fernwood.mpk.ca.us; id AA05354; Sat, 8 May 93 11:53:49 -0700 Received: from localhost by dumbcat.sf.ca.us (4.1/smail-24May90) id AA07797; Sat, 8 May 93 11:47:38 PDT To: Robert Berger Cc: IPLPDN WG , PPP Extensions WG Subject: Re: BONDING imux interoperability In-Reply-To: Your message of "Fri, 07 May 1993 12:30:07 -0800." <9305071933.AA11488@nic.cerf.net> Date: Sat, 08 May 1993 11:47:37 -0700 Message-Id: <7796.736886857@dumbcat.sf.ca.us> From: Marco S Hyman Robert Berger writes: > Yes! It makes much sense. From what I understand though, it requires some > hardware support and there may be some Terminal Adapter or PRI interfaces > that can not handle it. Quite a bit of hardware support (or a medium amount of hardware, a DSP, and some fancy software). Several hard real time constraints. An inverse MUX core adds quite a bit of cost to a product. I don't think the cost can be justified in a pure packet switching environment where you can get almost the same effect at layer two or layer three. I'd have to agree with Fred Baker. He said: > I would like to continue the Multilink Protocol and say nothing pro or > con about BONDING, considering it a fact about some physical layers > analogous to the fact that some physical layers have 193 bit frames of > which data may occupy somewhere between 1 and 192 bits... The net effect of using an inverse mux is that some data links will be faster than others. Robert Berger also writes: > Also I understand that there isn't one BONDING implementation (surprise!) > The standard has a mechanism to support several flavors (sound familiar > :-). Each of the vendors have their own implementation. The recent testing was to insure interoperability of the implementations. You may be thinking about the various BONDING modes. I wasn't involved in the recent BONDING testing so I don't know which of the modes were tested. // marc // primary: marc@dumbcat.sf.ca.us pacbell!dumbcat!marc // secondary: marc@ascend.com uunet!aria!marc From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 10 08:24:08 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10131; Mon, 10 May 93 08:11:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01822; Mon, 10 May 93 07:45:36 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09732; Mon, 10 May 93 07:44:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from babyoil.ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09480; Mon, 10 May 93 07:22:47 -0700 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA16544; Mon, 10 May 93 10:08:22 -0400 Date: Mon, 10 May 93 10:08:22 -0400 Message-Id: <9305101408.AA16544@ftp.com> To: clapp@ameris.center.il.ameritech.com Subject: Re: agenda for IPLPDN meeting in Amsterdam From: stev@ftp.com (stev knowles) Cc: vsp@NSD.3Com.COM, iplpdn@nri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu, mdavies@nri.reston.va.us Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com i would suggest that since you have so may intertwined WG's, you all cut down on the number of meetings, if you want ot make sure there are no overlaps. this helps CNRI, and lets people go to other meetings also. . . From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 11 14:06:35 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07684; Tue, 11 May 93 13:30:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21972; Tue, 11 May 93 12:54:24 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06719; Tue, 11 May 93 12:42:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [130.57.10.190] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06442; Tue, 11 May 93 12:29:05 -0700 Received: from va.SJF.Novell.COM by newsun (4.1/SMI-4.1) id AA00544; Tue, 11 May 93 12:28:33 PDT Received: by va.SJF.Novell.COM (4.1/SMI-4.1) id AA01439; Tue, 11 May 93 12:27:00 PDT Date: Tue, 11 May 93 12:27:00 PDT From: Dave_Rand@Novell.COM (Dave Rand) Message-Id: <9305111927.AA01439@va.SJF.Novell.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP Compression mailing list started As discussed, I have implemented a mailing list for those interested in the actual LAPB/Compression under/over/beside (however you want to look at it) PPP. This mailing list should be subscribed to if you are going to implement compression in your PPP product. To subscribe - mail your request to ppp-comp-request@bungi.com To mail to the list - mail your submission to ppp-comp@bungi.com It is not moderated. The goals of this list are to come to a resolution on the LAPB interface, the minimal compression specification, negotiation parameters, etc. Comments mailed to ppp-comp are archived, and I'll make them available to anyone wanting copies. Thanks! Dave Rand From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 09:09:03 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23083; Wed, 12 May 93 08:53:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03816; Wed, 12 May 93 08:15:20 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22258; Wed, 12 May 93 08:01:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22140; Wed, 12 May 93 07:54:50 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12353; 12 May 93 10:42 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu From: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-pppext-ipcpmib-03.txt Date: Wed, 12 May 93 10:42:08 -0400 Message-Id: <9305121042.aa12353@IETF.CNRI.Reston.VA.US> --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 : The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-ipcpmib-03.txt Pages : 18 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-ipcpmib-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-pppext-ipcpmib-03.txt". 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="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-pppext-ipcpmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ipcpmib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 09:32:11 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23577; Wed, 12 May 93 09:18:00 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04429; Wed, 12 May 93 08:46:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22713; Wed, 12 May 93 08:33:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22346; Wed, 12 May 93 08:09:13 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12403; 12 May 93 10:42 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu From: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-pppext-bridgemib-03.txt Date: Wed, 12 May 93 10:42:43 -0400 Message-Id: <9305121042.aa12403@IETF.CNRI.Reston.VA.US> --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 : The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-bridgemib-03.txt Pages : 23 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the bridge Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-bridgemib-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-pppext-bridgemib-03.txt". 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="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-pppext-bridgemib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bridgemib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 09:33:38 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23696; Wed, 12 May 93 09:26:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04663; Wed, 12 May 93 09:00:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23117; Wed, 12 May 93 08:55:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22663; Wed, 12 May 93 08:30:17 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10683; 12 May 93 10:28 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu From: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-pppext-ipcpmib-03.txt Date: Wed, 12 May 93 10:28:44 -0400 Message-Id: <9305121028.aa10683@IETF.CNRI.Reston.VA.US> --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 : The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-ipcpmib-03.txt Pages : 18 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the IP Network Control Protocol on subnetwork interfaces using the family of Point-to-Point Protocols. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-ipcpmib-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-pppext-ipcpmib-03.txt". 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="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-pppext-ipcpmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-ipcpmib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 10:55:24 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25361; Wed, 12 May 93 10:39:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05540; Wed, 12 May 93 10:01:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24133; Wed, 12 May 93 09:47:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23896; Wed, 12 May 93 09:36:25 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12482; 12 May 93 10:43 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu From: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-pppext-secmib-03.txt Date: Wed, 12 May 93 10:43:21 -0400 Message-Id: <9305121043.aa12482@IETF.CNRI.Reston.VA.US> --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 : The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-secmib-03.txt Pages : 21 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Security Protocols on subnetwork interfaces using the family of Point-to-Point Protocols. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-secmib-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-pppext-secmib-03.txt". 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="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-pppext-secmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-secmib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 10:56:06 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25434; Wed, 12 May 93 10:42:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05933; Wed, 12 May 93 10:17:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24655; Wed, 12 May 93 10:10:57 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24140; Wed, 12 May 93 09:48:21 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12433; 12 May 93 10:43 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu From: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-pppext-lcpmib-03.txt Date: Wed, 12 May 93 10:43:01 -0400 Message-Id: <9305121043.aa12433@IETF.CNRI.Reston.VA.US> --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 : The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol Author(s) : Frank Kastenholz Filename : draft-ietf-pppext-lcpmib-03.txt Pages : 34 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Link Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols. This memo does not specify a standard for the Internet community. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-lcpmib-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-pppext-lcpmib-03.txt". 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="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-pppext-lcpmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lcpmib-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 12:12:28 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26861; Wed, 12 May 93 11:51:09 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06919; Wed, 12 May 93 11:17:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26123; Wed, 12 May 93 11:14:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25599; Wed, 12 May 93 10:49:08 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA04316; Wed, 12 May 93 10:48:37 PDT Date: Wed, 12 May 93 10:48:37 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9305121748.AA04316@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: recent drafts I assert that the CIPX Draft 3 and Frank's recent MIB drafts are ready to ship to the IESG. Anyone who disagrees please holler. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 12:34:02 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27572; Wed, 12 May 93 12:26:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07365; Wed, 12 May 93 12:00:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26812; Wed, 12 May 93 11:48:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26559; Wed, 12 May 93 11:34:46 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14337; 12 May 93 11:23 EDT To: IETF-Announce:;@CNRI.Reston.VA.US Cc: IESG Cc: ietf-ppp@ucdavis.ucdavis.edu From: IESG Secretary Subject: Last Call: The Protocol of the Point-to-Point Protocol MIBs to Proposed Standard Date: Wed, 12 May 93 11:23:13 -0400 Message-Id: <9305121123.aa14337@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider the Internet Drafts o "The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol" o "The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol" o "The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol" o "The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol" as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by May 26th. Greg Vaudreuil IESG Secretary From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 12 14:25:50 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29696; Wed, 12 May 93 14:10:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09333; Wed, 12 May 93 13:45:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29020; Wed, 12 May 93 13:33:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ietf.cnri.reston.va.us by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28778; Wed, 12 May 93 13:22:09 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15809; 12 May 93 12:32 EDT To: IETF-Announce:;@CNRI.Reston.VA.US Cc: IESG@CNRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu From: IESG Secretary Subject: Last Call2: TCP/IP Header Compression to Draft Standard Date: Wed, 12 May 93 12:32:31 -0400 Message-Id: <9305121232.aa15809@IETF.CNRI.Reston.VA.US> The IESG is considering RFC 1144 "Compressing TCP/IP headers for low-speed serial links" for Draft Standard status. RFC 1144 was published as a Proposed Standard in December 1990. The IESG is aware of several errors in the example code. A revised version with version of this RFC will be published upon approval as a Draft Standard. The expected "diffs" are included as an appendix to this message. The IESG plans to issue a recommendation in the next few weeks, and solicits final comments on this elevation. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by May 26th. Greg Vaudreuil IESG Secretary Appendix Line numbers of rfc1144.txt --- 2042,2049 ---- comp->last_cs = lcs; hlen += th->th_off; hlen <<= 2; + if (hlen > m->m_len) return (TYPE_IP); goto uncompressed; found: /* Found it -- move to the front on the connection list. */ if (lastcs == cs) --- 2070,2076 ---- deltaS = hlen; hlen += th->th_off; hlen <<= 2; + if (hlen > m->m_len) return (TYPE_IP); if (((u_short *) ip)[0] != ((u_short *) &cs->cs_ip)[0] || ((u_short *) ip)[3] != ((u_short *) &cs->cs_ip)[3] || ((u_short *) ip)[4] != ((u_short *) &cs->cs_ip) --- 2527,2533 ---- */ comp->last_recv = 255; comp->last_xmit = 255; + comp->flags = SLF_TOSS; } From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 14 09:49:03 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07171; Fri, 14 May 93 09:38:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05677; Fri, 14 May 93 09:15:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06510; Fri, 14 May 93 09:02:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from uu5.psi.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06020; Fri, 14 May 93 08:36:11 -0700 Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA23229 for ; Fri, 14 May 93 11:11:29 -0400 Date: Fri, 14 May 93 11:01:51 EDT From: hhs@teleoscom.com (Chip Sharp 6424) Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.) id AA21763; Fri, 14 May 93 11:01:51 EDT Message-Id: <9305141501.AA21763@teleoscom.com> To: isdn@list.prime.com, iplpdn@cnri.reston.va.us, ietf-ppp@ucdavis.ucdavis.edu Cc: ctc@teleoscom.com, wln@teleoscom.com, jc@teleoscom.com, rpb@teleoscom.com, chris@telco-nac.com Subject: BONDING Specification Availability The BONDING channel aggregation specification Version 1.0 is not available on a file server yet. If anyone wants to volunteer to put it on an "ftp-able" file server, I will be glad to provide a disk. In addition, there is currently no mail list for discussing BONDING or related issues. If there is enough interest, we could set one up or continue any discussion in a current mail list. The BONDING specification is available on Compuserve. See the description below. It is in the telecom forum (GO TELECO) in Library 7 (Data/ISDN). Anyone with access to Compuserve can download this file. I don't know the procedures for proposing RFCs, but if you want to list this as an RFC, I think it qualifies (unless you feel it does not fall under the IETF charter). On the other hand, an RFC could be developed on how to use BONDING in the Internet. All suggestions are welcome. Currently, nine vendors have demonstrated interoperability (at Mode 1): 3NET Adtran Ascend Newbridge Promptus Telco Systems Teleos Tylink UDS ======== Compuserve information [76646,522] BOND01.EXE/Bin Bytes: 530034, Count: 21, 04-Sep-92 Last:29-Apr-93 Title : Version 1 of BONDING's Interoperability Requireme Keywords: BONDING INVERSE MULTIPLEXING CHANNEL AGGREGATION ISDN This is version 1 of BONDING's specification. It is a self-extracting file. To extract, type the following: "bond01 -s bond (or bonding)". This document is in Word for Windows Version 2 format and contains embedded diagrams drawn with Micrografx Designer Version 3.1 with OLE extensions. When decompressed it takes about 1.4 Mbytes of disk space. For more information on joining BONDING, contact Donna Golden at +1 401 683 6100. The document in this file is slightly different than that being standardized in TIA. From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 14 10:34:27 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07990; Fri, 14 May 93 10:25:51 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06119; Fri, 14 May 93 10:00:38 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07351; Fri, 14 May 93 09:48:42 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07153; Fri, 14 May 93 09:37:32 -0700 Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA11022 (5.65c+/IDA-1.4.4); Fri, 14 May 1993 12:36:14 -0400 Date: Fri, 14 May 93 10:47:38 EDT From: "William Allen Simpson" Message-Id: <901.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Cc: iplpdn@cnri.reston.va.us, ISDN@list.prime.com Subject: Re: BONDING imux interoperability > implementation requires some hardware support. This hardware is more > expensive than an Ethernet or HDLC controller. > Thank you. I did not understand that bonding was not possible over our current HDLC chips. When PPP was designed, great care was taken to ensure that it would operate over all current hardware. Therefore, I am in agreement with Fred Baker, that we should treat this as just another physical layer type. We still need a per packet multi-link capability of our own. I am working on a revised "PPP framing" draft. This includes both async and sync, but not other LPDN framing (which are in separate drafts). Could someone send me a bonding spec, so that I can decide whether this is merely an extension of sync, or needs a separate draft? > detect it. It is possible that equipment running TCP/IP over > BONDING could use Mode 1 and detect delay changes as CRC errors on the > line. In this mode, the equipment could then place BONDING framing on > the line, resynchronize and then go back to data mode. This would > require both endpoints to do this in order for it to work, but in > normal operation would require no overhead. > Bonding has its own CRC? It's own framing? You run TCP/IP directly, without a link layer protocol? It sounds like a substitute for HDLC. If this is so, then it's not a physical layer, it's a link layer (like frame relay), and needs its own draft. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 14 17:20:05 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15644; Fri, 14 May 93 17:13:55 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14217; Fri, 14 May 93 16:45:38 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15061; Fri, 14 May 93 16:32:52 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14838; Fri, 14 May 93 16:22:48 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA18811; Fri, 14 May 93 16:21:30 PDT Date: Fri, 14 May 93 16:21:30 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9305142321.AA18811@saffron.acc.com> To: bsimpson@morningstar.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: BONDING imux interoperability Cc: ISDN@list.prime.com, iplpdn@CNRI.Reston.VA.US >> Bonding has its own CRC? It's own framing? You run TCP/IP directly, >> without a link layer protocol? It sounds like a substitute for HDLC. >> If this is so, then it's not a physical layer, it's a link layer (like >> frame relay), and needs its own draft. No, it's a physical layer. The way it works is that there are some number (probably most often two, as in "BRI", but that's not really a requirement) of physical channels running at the same speed. If this were PRI, one could specify the circuit so that the data in the two channels always traversed the world together, and so the channels could be treated as a single bigger channel. These channels are called H1 (392 KBPS), H11 (1.536 MBPS), etc. In the BRI world, the channels might conceivably take different paths through the telco network, so two channels that always are originated together might arrive some (predictable) number of frames apart at the receiving end. But gee whiz, you'd love to treat them as one anyway. What to do? Well, you take one bit every so often and run a predictable pattern down it. Each end locks up on this pattern (much as in figuring out a DS1 or E1 superframe), and then the receiving end can tell for sure what the relationship between the received channels is. It buffers data from N-1 of the channels to synchronize it with the most delayed channel, and then proceeds to deliver the bits in the same order they were originally sent. The *data* bits (all the bits that aren't the predictable pattern) remain a serial bit stream that one can use for whatever one wants. PPP runs HDLC in the data portion. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 14 17:34:08 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15755; Fri, 14 May 93 17:19:15 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14313; Fri, 14 May 93 16:54:07 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15068; Fri, 14 May 93 16:33:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14874; Fri, 14 May 93 16:25:27 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA18817; Fri, 14 May 93 16:24:53 PDT Date: Fri, 14 May 93 16:24:53 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9305142324.AA18817@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: draft-ietf-pppext-ipxcp-03.txt I assert that this document is ready for the IESG as well. Does anyone disagree? From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 17 12:25:39 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27206; Mon, 17 May 93 12:00:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18752; Mon, 17 May 93 11:15:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26173; Mon, 17 May 93 11:05:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from gatekeeper.coral.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25832; Mon, 17 May 93 10:47:32 -0700 Received: from achilles.coral.com by coral.com (4.1/SMI-4.1) id AA04546; Mon, 17 May 93 13:51:51 EDT Received: by achilles.coral.com (4.1/SMI-4.1) id AA13021; Mon, 17 May 93 13:47:44 EDT Date: Mon, 17 May 93 13:47:44 EDT From: kajos@coral.com (George Kajos) Message-Id: <9305171747.AA13021@achilles.coral.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: ppp interoperability forum and ppp products Hi, I'm told that recent mailings listed ppp products and the ncps and options supported. If anyone has a copy would you please send it to me? Also who is the governing group for the PPP Interoperabilty Forum and what is the procedure for joining? Thanks in advance, George Kajos kajos@coral.com From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 17 12:48:06 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27798; Mon, 17 May 93 12:37:33 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20312; Mon, 17 May 93 12:14:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27278; Mon, 17 May 93 12:06:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27078; Mon, 17 May 93 11:55:56 -0700 Received: from america.TELEBIT.COM (america-bb.telebit.com) by apache (4.1/SMI-4.1/Telebit-Apache-Brent-930310) id AA05543 to ietf-ppp@ucdavis.edu; Mon, 17 May 93 11:55:18 PDT Received: from yoyo.telebit.com by america.TELEBIT.COM (4.0/america.telebit.com-DBC-921227) id AA01623 to ietf-ppp@ucdavis.edu; Mon, 17 May 93 11:54:41 PDT Date: Mon, 17 May 93 11:54:41 PDT From: mlewis@america.Telebit.COM (Mark S. Lewis) Message-Id: <9305171854.AA01623@america.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA01098; Mon, 17 May 93 11:55:16 PDT To: fbaker@acc.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9305142324.AA18817@saffron.acc.com> "fbaker@acc.com" Subject: draft-ietf-pppext-ipxcp-03.txt >>>>> On Fri, 14 May 93 16:24:53 PDT, fbaker@acc.com (Fred Baker) said: > I assert that this document is ready for the IESG as well. > Does anyone disagree? I agree with your assertion. As far as I know, this draft is ready for IESG consideration. Thanks. ... Mark ==========-------------- Mark S. Lewis ----------========== Mark.S.Lewis@Telebit.com Telebit Corp. Voice (408) 745-3232 From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 17 14:05:45 1993 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29278; Mon, 17 May 93 13:46:59 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21292; Mon, 17 May 93 13:15:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28366; Mon, 17 May 93 13:03:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28153; Mon, 17 May 93 12:54:43 -0700 Received: from america.TELEBIT.COM (america-bb.telebit.com) by apache (4.1/SMI-4.1/Telebit-Apache-Brent-930310) id AA05942 to ietf-ppp@ucdavis.edu; Mon, 17 May 93 12:54:03 PDT Received: from yoyo.telebit.com by america.TELEBIT.COM (4.0/america.telebit.com-DBC-921227) id AA06601 to ietf-ppp@ucdavis.edu; Mon, 17 May 93 12:53:25 PDT Date: Mon, 17 May 93 12:53:25 PDT From: mlewis@america.Telebit.COM (Mark S. Lewis) Message-Id: <9305171953.AA06601@america.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA01139; Mon, 17 May 93 12:54:00 PDT To: kajos@coral.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9305171747.AA13021@achilles.coral.com> "kajos@coral.com" Subject: ppp interoperability forum and ppp products >>>>> On Mon, 17 May 93 13:47:44 EDT, kajos@coral.com (George Kajos) said: > Hi, > I'm told that recent mailings listed ppp products and the > ncps and options supported. If anyone has a copy would you please > send it to me? Also who is the governing group for the PPP > Interoperabilty Forum and what is the procedure for joining? > Thanks in advance, > George Kajos > kajos@coral.com It's very easy to join the PPP Consortium. Basically, you show up for interoperability testing sessions. Contact me if you would like further details. I have included some summary information from the last session. Unfortunately, you have to attend the sessions to get more detailed information. ... Mark ==========-------------- Mark S. Lewis ----------========== Mark.S.Lewis@Telebit.com Telebit Corp. Voice (408) 745-3232 PPP IMPLEMENTATIONS October 1992 Summary ------- The PPP Consortium met in October of 1992 to test interoperability of PPP implementations. A brief summary of which protocols and options are implemented is shown below. A listing of the 28 vendors which provided such information is also included. What can be observed is that all of the options for LCP (RFC 1331) and IPCP (RFC 1332) have been implemented by at least 12 vendors. LCP Link Quality Monitoring (RFC 1333) has been implemented by 13 vendors. LCP Authentication (RFC 1334) also has been implemented by 13 different vendors. Several protocols besides IP have been implemented over PPP. Most popular is IPX with 10 implementations. In almost all cases, these protocols are implemented with an NCP without any options. While options are defined for many of these protocols, they are not yet widely supported. Protocol Option Implementations Not Implemented* -------- ---------------------------- --------------- --------------- LCP Maximum-Receive-Unit 23 5 LCP Async-Control-Char-Map** 13 15 LCP Magic-Number 16 12 LCP Protocol-Field-Compression 12 16 LCP Address-Control-Field-Compr. 12 16 LCP Quality-Protocol (LQM) 13 15 LCP Authentication-Protocol PAP 10 - CHAP 5 - IPCP IP-Addresses (Opt. 1) 18 10 IPCP IP-Compression 14 14 IPCP IP-Address (Opt. 3) 17 11 ATCP None 4 - BNCP None 7 - DNCP None 8 - IPXCP None 10 - XNSCP None 8 - Footnotes --------- *Not Implemented means this protocol is supported without this option. **Async-Control-Character-Map does not apply to sync only implementations. Vendors ------- 3Com Corp. Advanced Computer Communications Ascom Timeplex Inc. Centrum Communications Cisco Systems Inc. Clearpoint Research Corp. Datability, Inc. Digital Equipment Corp. Distinct Corp. FTP Software Hewlett Packard Company IBM Corp. Interactive Systems Corp. Livingston Enterprises, Inc. Merit Networks, Inc. Morning Star Technologies NEC America, Inc. Network Application Technology, Inc. Network Equipment Technologies, Inc. Network Systems Corp. Novell, Inc. Penril DataComm Networks, Inc. Proteon, Inc. Rockwell International Telebit Corp. Wellfleet Communications Xylogics Inc. Xyplex Inc.