From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 3 12:43:57 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25492; Mon, 3 Aug 92 12:39:25 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10697; Mon, 3 Aug 92 11:00:15 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22339; Mon, 3 Aug 92 10:53:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22147; Mon, 3 Aug 92 10:47:49 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA09193; Mon, 3 Aug 92 12:49:18 -0500 Received: from eros.network.com by anubis.network.com (4.0/SMI-4.0) id AA17859; Mon, 3 Aug 92 12:46:04 CDT Date: Mon, 3 Aug 92 12:46:04 CDT From: sjs@anubis.network.com (Steve Senum) Message-Id: <9208031746.AA17859@anubis.network.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Bridging over PPP Cc: fbaker@acc.com > >> Craig Fox mentioned that you were considering makeing some changes > >> to the current Bridging over PPP RFC. I was wondering if you could > >> tell me what they might be. > >> > >> Steve Senum > > There seems to be a consensus behind obsoleting the Mac Type option and > the LAN ID. > > Fred Baker I don't think obsoleting options in an existing RFC is a very good idea. We use the LAN ID (type = 5) option in our existing products, and have customers who depend on this option. Likewise there may be people who use the MAC Type option (type = 3). Steve Senum From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 3 13:32:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26699; Mon, 3 Aug 92 13:21:34 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11497; Mon, 3 Aug 92 11:59:50 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24033; Mon, 3 Aug 92 11:53:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from inet-gw-1.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23916; Mon, 3 Aug 92 11:49:40 -0700 Received: by inet-gw-1.pa.dec.com; id AA15391; Mon, 3 Aug 92 11:48:09 -0700 Received: by libeb.lkg.dec.com (5.57/cgg-100491);id AA18545; Mon, 3 Aug 92 14:47:59 -0400 Message-Id: <9208031847.AA18545@libeb.lkg.dec.com> To: us1rmc::fbaker@acc.com (Fred Baker) Cc: gunner@libeb.lkg.dec.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Bridging over PPP In-Reply-To: Your message of "Fri, 31 Jul 92 20:16:09 EDT." <9208010016.AA00483@dsmail.lkg.dec.com> Date: Mon, 03 Aug 92 14:47:58 -0400 From: "(Chris Gunner)" X-Mts: smtp Fred, >There seems to be a consensus behind obsoleting the Mac Type option and >the LAN ID. Why is the MAC Types option not considered useful ? It seems to provide a reasonable way of avoiding sending frames over the PPP link that are simply going to be dropped at the receiving end. I would have thought this was particularly useful in mixed FDDI and Ethernet environments. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Tue Aug 4 07:01:40 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28000; Tue, 4 Aug 92 06:54:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18213; Tue, 4 Aug 92 06:39:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27338; Tue, 4 Aug 92 06:30:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from csusac.ecs.csus.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27121; Tue, 4 Aug 92 06:25:36 -0700 Received: by csusac.ecs.csus.edu (5.61/1.34) id AA05593; Tue, 4 Aug 92 06:24:19 -0700 Received: by unify.Unify.Com (5.61/smail2.5/06-13-89/jwc.5) id AA17832; Tue, 4 Aug 92 06:09:09 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04216; Tue, 4 Aug 92 05:56:12 -0400 Received: from unislc.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 055544.4357; Tue, 4 Aug 1992 05:55:44 EDT Received: by unislc.slc.unisys.com (5.61/1.35) id AA10118; Sat, 1 Aug 92 23:57:36 -0600 Received: by unislc via UUCP from ctnews; Sun Aug 2 05:54:36 1992 Received: by ctnews.Convergent.COM (5.51/6.8+smail2.5); Sun, 2 Aug 92 05:54:34 GMT Received: by unislc.slc.unisys.com (5.61/1.35) id AA09345; Sat, 1 Aug 92 23:45:59 -0600 Date: Sat, 1 Aug 92 23:45:59 -0600 From: 0000-uucp(0000) Message-Id: <9208020545.AA09345@unislc.slc.unisys.com> Subject: Warning From uucp Apparently-To: ctnews!ucdavis.edu!ietf-ppp We have been unable to contact machine 'uunet' since you queued your job. uunet!mail sco!andrewk (Date 07/31) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kuunetC9497 Sincerely, unislc!uucp ############################################# ##### Data File: ############################ From ctnews!ucdavis.edu!ietf-ppp Fri Jul 31 19:02:30 1992 remote from unislc.slc.unisys.com Received: by unislc.slc.unisys.com (5.61/1.35) id AA05168; Fri, 31 Jul 92 19:02:30 -0600 Received: by unislc via UUCP from ctnews; Fri Jul 31 17:43:21 1992 Received: by ctnews.Convergent.COM (5.51/6.8+smail2.5); Fri, 31 Jul 92 17:43:19 PDT Received: from aggie.ucdavis.edu by unix.sri.com (4.1/SMI-4.0) id AA13461; Fri, 31 Jul 92 17:22:24 PDT Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA28464; Fri, 31 Jul 92 15:39:40 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22297; Fri, 31 Jul 92 15:31:25 -0700 Sender: unislc.slc.unisys.com!ucdavis.edu!ietf-ppp-request Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22101; Fri, 31 Jul 92 15:27:18 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA26298; Fri, 31 Jul 92 15:25:23 PDT Date: Fri, 31 Jul 92 15:25:23 PDT From: unislc.slc.unisys.com!acc.com!fbaker (Fred Baker) Message-Id: <9207312225.AA26298@saffron.acc.com> To: sjs@anubis.network.com Subject: Re: Bridging over PPP Cc: ietf-ppp@ucdavis.edu >> Craig Fox mentioned that you were considering makeing some changes >> to the current Bridging over PPP RFC. I was wondering if you could >> tell me what they might be. There seems to be a consensus behind obsoleting the Mac Type option and the LAN ID. I have had three vendors specifically ask me for a MAC Address Negotiation option. I need to tighten up the language in the source routing options to guide negotiations. If I say, for example, that I am running a transparent link, I might send a ring-and-bridge option saying that my (virtual or real) ring number is FOO and I consider my self bridge 2. If you say you have ring FOO, we're in trouble, and I have to reject it or something. If you say you have ring BAR and bridge 1, I might NAK that you have ring BAR and bridge 2. But the "who wins" rule is not specified. There is no substantive reason to choose one rule over another; the point is to break the tie. I suggest (consistent with a couple of other specifications) that the NUMERICALLY HIGHER number wins. I have not planned to do anything with the TR BPDU, although Kirke Preiss and I are playing telephone tag to discuss the subject. My take at the moment is: that is 802.5 specific, leave it in an 802.5 frame. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 5 12:51:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19343; Wed, 5 Aug 92 12:44:26 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01973; Wed, 5 Aug 92 12:20:38 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18481; Wed, 5 Aug 92 12:12:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18258; Wed, 5 Aug 92 12:04:47 -0700 Received: by ginger.lcs.mit.edu id AA28139; Wed, 5 Aug 92 15:03:11 -0400 Date: Wed, 5 Aug 92 15:03:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208051903.AA28139@ginger.lcs.mit.edu> To: ietf-ppp@ucdavis.ucdavis.edu, sjs@anubis.network.com Subject: Re: Bridging over PPP Cc: fbaker@acc.com, jnc@ginger.lcs.mit.edu I don't think obsoleting options in an existing RFC is a very good idea. We use the LAN ID (type = 5) option in our existing products, and have customers who depend on this option. This is a good point; we have to be careful about not breaking deployed stuff. On the other hand, how do we make progress if we can never throw anything away? I suggest that if there is something better (and I have no idea of the specifics of the point under discussion here, let me hasten to add :-), then the document should say so, we should give people plenty of time (i.e. several years) to get new stuff done and deployed, and in the interim, the thing which is being obsoleted should be marked 'obsolescent', to warn people what is going to happen. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 5 14:32:39 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22320; Wed, 5 Aug 92 14:23:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02765; Wed, 5 Aug 92 13:50:13 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21042; Wed, 5 Aug 92 13:42:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20944; Wed, 5 Aug 92 13:38:27 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA13930; Wed, 5 Aug 92 13:36:19 PDT Date: Wed, 5 Aug 92 13:36:19 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9208052036.AA13930@saffron.acc.com> To: jnc@ginger.lcs.mit.edu Subject: Re: Bridging over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu, sjs@anubis.network.com ]] I don't think obsoleting options in an existing RFC is a very good idea. ]] We use the LAN ID (type = 5) option in our existing products, and have ]] customers who depend on this option. >> This is a good point; we have to be careful about not breaking >> deployed stuff. On the other hand, how do we make progress if we can never >> throw anything away? >> I suggest that if there is something better (and I have no idea of the >> specifics of the point under discussion here, let me hasten to add :-), then >> the document should say so, we should give people plenty of time (i.e. several >> years) to get new stuff done and deployed, and in the interim, the thing >> which is being obsoleted should be marked 'obsolescent', to warn people what >> is going to happen. Steve and I spoke on the phone, and I agreed that I would not pull the two options. I suggested he document his opinion to the list, which he has done. I suggested that I mark the two options as "you really don't need to implement these," which *also* bothered Steve, on the basis that all options are optional. Sounds, Noel, like you would want to mark them as being very, very optional, based on implementation experience. BTW, Rich Bowen at IBM has suggested a new PPP protocol type be added for the IBM Source Route Bridge BPDU, and sent me a marked up copy of 1220. Opinions on the subject would be welcome. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 5 16:22:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25706; Wed, 5 Aug 92 16:18:11 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04066; Wed, 5 Aug 92 15:49:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24659; Wed, 5 Aug 92 15:43:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from NEWBRIDGE.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24431; Wed, 5 Aug 92 15:33:46 -0700 Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA23521; Wed, 5 Aug 92 18:34:50 EDT Received: from nexus.newbridge by Newbridge.COM (4.0/SMI-4.0) id AA12621; Wed, 5 Aug 92 18:30:18 EDT From: james@Newbridge.COM (James Watt) Message-Id: <9208052230.AA12621@Newbridge.COM> Subject: Re: Bridging over PPP To: fbaker@acc.com (Fred Baker) Date: Wed, 5 Aug 92 18:30:19 EDT Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9208052036.AA13930@saffron.acc.com>; from "Fred Baker" at Aug 5, 92 1:36 pm X-Mailer: ELM [version 2.3 PL8] > > BTW, Rich Bowen at IBM has suggested a new PPP protocol type be added > for the IBM Source Route Bridge BPDU, and sent me a marked up copy of > 1220. Opinions on the subject would be welcome. > > Fred > Does that mean a new option to negotiate what kind of BPDUs a bridge can support too ? I'm not sure it is necessary. Presumably one must use IBM SR-style BPDU's on a ring with IBM (or compatible) bridges, but I don't see any need to send them over a PPP link. You could set the priority to give the same topology [from (port, priority) pairs in the case of equal cost, || links) as the (ring, bridge) pairs would have. Or am I missing something ? I can already cope with both so adding one more case to the demux code and one more option is not a really big deal. -james From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 5 17:41:38 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27879; Wed, 5 Aug 92 17:32:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04353; Wed, 5 Aug 92 16:30:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25817; Wed, 5 Aug 92 16:21:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25712; Wed, 5 Aug 92 16:18:28 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA28036; Wed, 5 Aug 92 16:16:49 PDT Date: Wed, 5 Aug 92 16:16:49 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9208052316.AA28036@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA00616; Wed, 5 Aug 92 16:16:02 PDT To: fbaker@acc.com Cc: jnc@ginger.lcs.mit.edu, ietf-ppp@ucdavis.ucdavis.edu, sjs@anubis.network.com In-Reply-To: Fred Baker's message of Wed, 5 Aug 92 13:36:19 PDT <9208052036.AA13930@saffron.acc.com> Subject: Bridging over PPP ]] I don't think obsoleting options in an existing RFC is a very good idea. ]] We use the LAN ID (type = 5) option in our existing products, and have ]] customers who depend on this option. >> This is a good point; we have to be careful about not breaking >> deployed stuff. On the other hand, how do we make progress if we can never >> throw anything away? >> I suggest that if there is something better (and I have no idea of the >> specifics of the point under discussion here, let me hasten to add :-), then >> the document should say so, we should give people plenty of time (i.e. several >> years) to get new stuff done and deployed, and in the interim, the thing >> which is being obsoleted should be marked 'obsolescent', to warn people what >> is going to happen. Steve and I spoke on the phone, and I agreed that I would not pull the two options. I suggested he document his opinion to the list, which he has done. I suggested that I mark the two options as "you really don't need to implement these," which *also* bothered Steve, on the basis that all options are optional. Sounds, Noel, like you would want to mark them as being very, very optional, based on implementation experience. Sounds like we need the "implementor's guidelines" document. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 5 22:31:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06302; Wed, 5 Aug 92 22:26:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06202; Wed, 5 Aug 92 22:09:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05511; Wed, 5 Aug 92 22:00:20 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AB05251; Wed, 5 Aug 92 21:52:09 -0700 Received: by ginger.lcs.mit.edu id AA02239; Thu, 6 Aug 92 00:50:34 -0400 Date: Thu, 6 Aug 92 00:50:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208060450.AA02239@ginger.lcs.mit.edu> To: fbaker@acc.com, jnc@ginger.lcs.mit.edu Subject: Re: Bridging over PPP Cc: ietf-ppp@ucdavis.ucdavis.edu, sjs@anubis.network.com Sounds, Noel, like you would want to mark them as being very, very optional, based on implementation experience. Well, Noel isn't sure. Do they do things which the WG now feels are Not A Good Idea? If so, your suggestion sounds good. Do these options do things which some other, later, mechanism does better? If so, perhaps 'obsolescent' is better. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Thu Aug 6 09:28:30 1992 Received: from [128.120.2.9] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25515; Thu, 6 Aug 92 09:12:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08358; Thu, 6 Aug 92 08:19:43 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23788; Thu, 6 Aug 92 08:12:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from monk.proteon.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23702; Thu, 6 Aug 92 08:10:01 -0700 Received: from sonny.proteon.com by monk.proteon.com (5.65/1.8) id AA27523; Thu, 6 Aug 92 11:12:45 -0400 Received: by sonny.proteon.com (3.2/SMI-3.2) id AA16412; Thu, 6 Aug 92 11:06:37 EDT Date: Thu, 6 Aug 92 11:06:37 EDT From: jas@proteon.com (John A. Shriver) Message-Id: <9208061506.AA16412@sonny.proteon.com> To: james@Newbridge.COM Cc: fbaker@acc.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: James Watt's message of Wed, 5 Aug 92 18:30:19 EDT <9208052230.AA12621@Newbridge.COM> Subject: Bridging over PPP I would think that one would sort out IBM SR BPDU's from 802.1D BPDU's by the destination MAC address. The BPDU's do have MAC addresses when sent over a PPP link, right? From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 7 13:42:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15440; Fri, 7 Aug 92 13:38:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18968; Fri, 7 Aug 92 13:19:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14754; Fri, 7 Aug 92 13:14:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14540; Fri, 7 Aug 92 13:06:30 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01625; Fri, 7 Aug 92 13:04:57 PDT Date: Fri, 7 Aug 92 13:04:57 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9208072004.AA01625@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA01469; Fri, 7 Aug 92 13:04:56 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: once more into the breech How much meeting do we need to do in DC? What are the outstanding issues? I am aware of LAPB, compression, and some noise about bridging, but what else? I guess that the key point here is: do we need 0, 1, or 2 sessions? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 10 11:55:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29575; Mon, 10 Aug 92 11:46:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01441; Mon, 10 Aug 92 11:19:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28367; Mon, 10 Aug 92 11:10:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28146; Mon, 10 Aug 92 11:04:27 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA02668; Mon, 10 Aug 92 11:02:09 PDT Date: Mon, 10 Aug 92 11:02:09 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9208101802.AA02668@saffron.acc.com> To: brian@lloyd.com Subject: Re: once more into the breech Cc: ietf-ppp@ucdavis.ucdavis.edu I'd like to believe that we can work aout most of the details on the list; probably one meeting. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 12 21:01:47 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07589; Wed, 12 Aug 92 20:50:41 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04671; Wed, 12 Aug 92 20:33:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06743; Wed, 12 Aug 92 20:20:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06669; Wed, 12 Aug 92 20:17:38 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07614; Wed, 12 Aug 92 20:15:49 -0700 Date: Wed, 12 Aug 92 22:19:20 EDT From: "William Allen Simpson" Message-Id: <621.bill.simpson@um.cc.umich.edu> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: new pppext-authentication draft Please post today's PPP Authentication Protocols draft, found at angband.stanford.edu in pub/ppp/ap.txt To the WG: In the process of passing up the review levels of IESG and IAB, we were subjected to many comments and text additions that were not in the original draft. Since nearly 2/3 of the lines have changed, and several additional pages have been added, I am asking the WG to review the changes. After all, it's supposed to be *our* document! Those of you who have already implemented should pay close attention. The only non-interoperable change I know of is the removal of callback from CHAP. The "security gurus" don't like a poorly specified implementation dependent extension, since it's supposed to be "provably" secure. In meetings at Boston, I proposed moving callback to its own option -- having nothing to do with security -- which I will write soon. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 12 22:31:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10258; Wed, 12 Aug 92 22:20:52 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04810; Wed, 12 Aug 92 21:59:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09342; Wed, 12 Aug 92 21:50:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09076; Wed, 12 Aug 92 21:42:42 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05560; Wed, 12 Aug 92 21:41:04 PDT Date: Wed, 12 Aug 92 21:41:04 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9208130441.AA05560@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA03537; Wed, 12 Aug 92 21:41:03 PDT To: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Wed, 12 Aug 92 22:19:20 EDT <621.bill.simpson@um.cc.umich.edu> Subject: new pppext-authentication draft For historical purposes: the callback field was in the authentication protocols not for security but because you need to know who to call back and if someone decides not to implement authentication, there is no sure way of knowing who to call back. Frankly, callback belongs in the authentication protocol. Bill, just make it an authentication option rather than an LCP option. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 14 11:51:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13478; Fri, 14 Aug 92 11:19:02 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19197; Thu, 30 Jul 92 14:43:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09571; Thu, 30 Jul 92 14:32:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09401; Thu, 30 Jul 92 14:29:51 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA22765; Thu, 30 Jul 92 14:28:28 PDT Date: Thu, 30 Jul 92 14:28:28 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207302128.AA22765@ray.lloyd.com> To: mlewis@Telebit.COM Cc: cranch@novell.com, mallen@novell.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Mark S. Lewis's message of Thu, 30 Jul 92 13:27:18 PDT <9207302027.AA09196@napa.TELEBIT.COM> Subject: PPP work in progress This is what the NCP exchange would look like in the IPXWAN case: Telebit side Novell Side Config-REQ (bunch of options) ---> <--------- Config-REQ (no options) <--- Config-NAK (bunch of options) Config-ACK (no options) ---------> Config-REQ (no options) ---------> <--------- Config-ACK (no options) *** Now start doing the IPXWAN packet exchange here *** Note that the Novell side will config-NAK any options you try to send forcing you to fall back to sending an empty config-REQ. They wills send you an empty config-REQ the first time which you should ACK. Simple and completely within the protocol. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 14 12:03:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14537; Fri, 14 Aug 92 11:57:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20171; Fri, 14 Aug 92 11:41:02 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13924; Fri, 14 Aug 92 11:35:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13705; Fri, 14 Aug 92 11:28:40 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA23221; Fri, 14 Aug 92 14:26:55 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA04277; Fri, 14 Aug 92 14:26:48 EDT Date: Fri, 14 Aug 92 14:26:48 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9208141826.AA04277@cannibal.gandalf.ca> To: mlewis@Telebit.COM, brian@lloyd.com Subject: Re: PPP work in progress Cc: cranch@novell.com, mallen@novell.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu :-) This is what the NCP exchange would look like in the IPXWAN case: :-) :-) Telebit side Novell Side :-) :-) Config-REQ (bunch of options) ---> :-) :-) <--------- Config-REQ (no options) :-) <--- Config-NAK (bunch of options) Don't you mean Config-REJ? Config-NAK would have to propose new values for the options, wouldn't it? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 14 12:48:13 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15521; Fri, 14 Aug 92 12:32:02 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA20443; Fri, 14 Aug 92 12:09:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14711; Fri, 14 Aug 92 12:03:05 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14363; Fri, 14 Aug 92 11:50:13 -0700 Received: from na.novell.com. (na.Novell.COM) by newsun.novell.com with SMTP id AA04878 (5.65c/IDA-1.4.4 for ); Fri, 14 Aug 1992 11:48:30 -0700 Received: by na.novell.com. (4.1/SMI-4.1) id AA25797; Fri, 14 Aug 92 11:51:09 PDT Date: Fri, 14 Aug 92 11:51:09 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9208141851.AA25797@na.novell.com.> To: ietf-ppp@ucdavis.ucdavis.edu Subject: IPXWAN last last call Hi Y'all, As of the publication of IPXWAN through the internet drafts secretary, we announced that IPXWAN will be sent to the rfc editor as an informational rfc after a two week last call period. That period has expired with no comments. We will be sending the document to the rfc editor early next week, so this is your last chance to comment. Thank yew for your support.. Chris From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 14 14:36:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18711; Fri, 14 Aug 92 14:24:17 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21515; Fri, 14 Aug 92 13:39:51 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17219; Fri, 14 Aug 92 13:32:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17039; Fri, 14 Aug 92 13:28:36 -0700 Received: from harry. (harry.lloyd.COM) by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA06800; Fri, 14 Aug 92 13:26:49 PDT Date: Fri, 14 Aug 92 13:26:49 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9208142026.AA06800@ray.lloyd.com> Received: by harry. (4.1/SMI-4.1) id AA03776; Fri, 14 Aug 92 13:26:49 PDT To: chris@gandalf.ca Cc: mlewis@Telebit.COM, cranch@novell.com, mallen@novell.com, bsimpson@angband.stanford.edu, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Chris Sullivan's message of Fri, 14 Aug 92 14:26:48 EDT <9208141826.AA04277@cannibal.gandalf.ca> Subject: PPP work in progress :-) This is what the NCP exchange would look like in the IPXWAN case: :-) :-) Telebit side Novell Side :-) :-) Config-REQ (bunch of options) ---> :-) :-) <--------- Config-REQ (no options) :-) <--- Config-NAK (bunch of options) Don't you mean Config-REJ? Config-NAK would have to propose new values for the options, wouldn't it? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Oops, yes. It should be a Config-REJ. Sorry. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 fax (916) 676-3442 From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 14 21:10:32 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00989; Fri, 14 Aug 92 21:06:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25058; Fri, 14 Aug 92 20:49:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00227; Fri, 14 Aug 92 20:40:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00203; Fri, 14 Aug 92 20:39:38 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA10455; Fri, 14 Aug 92 20:37:43 -0700 Date: Fri, 14 Aug 92 22:19:20 EDT From: "William Allen Simpson" Message-Id: <632.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: new pppext-authentication draft > For historical purposes: the callback field was in the authentication > protocols not for security but because you need to know who to call > back and if someone decides not to implement authentication, there is > no sure way of knowing who to call back. > You are absolutely correct (historically). We decided this as a group at the Santa Fe meeting. We also decided to only include it in the CHAP configuration option to encourage people to switch from PAP to CHAP. Unfortunately, the CHAP protocol requires other protocols which haven't arrived from the CAT or NAS groups. So those who want to use callback are temporarily stuck. Also, the IAB member (Steve Kent) examining our spec wants other information in the flag field, like the format of the contents of the data area (phone number, ASCII location, ASN.1 format globally unique name, modem command string, etc): "If other, site specific uses are envisioned, then they should be specified, e.g., by numbers registered with the IANA, or there will be interoperability problems." He is correct. He also stated that callback doesn't meet the necessary requirements for "security", especially when we have an override field for the callback number. We were held up (by him) over three months for this kind of issue. > Frankly, callback belongs in the authentication protocol. Bill, just > make it an authentication option rather than an LCP option. > We can simply make authentication a _required_ option when negotiating the callback option, just like Fred is doing with compression stuff. There shouldn't be any problem, since they are going in the same packet. Since callback isn't deemed sufficient for "secure" authentication, it needn't be part of the authentication protocol spec. Then we don't have to argue the merits with the security folks. Finally, we agreed to do this at the Boston meeting. He gave in on ASCII messages, and I gave in on this, tit for tat. It actually makes the overall design better, since it will also work with PAP and any future authentication schemes we develop later. (I don't mind making a strategic retreat when it improves my position.) We've spent a lot of time on this, and hammered out an agreement. Let's get it over with, so we can go on to better things. I don't like going back again. Particularly if it subjects us to another 3 month delay. But I do want to give the implementors time to scream if it's a real problem with fielded implementations, so that we can come up with a migration plan. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Aug 15 08:20:08 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14429; Sat, 15 Aug 92 08:10:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26445; Sat, 15 Aug 92 07:49:21 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14012; Sat, 15 Aug 92 07:40:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13851; Sat, 15 Aug 92 07:30:11 -0700 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA17595; Sat, 15 Aug 92 10:28:24 -0400 Received: by crappie.morningstar.com (5.65a/910712902) id AA00479; Sat, 15 Aug 92 10:27:53 -0400 Date: Sat, 15 Aug 92 10:27:53 -0400 From: Karl Fox Message-Id: <9208151427.AA00479@crappie.morningstar.com> To: William Allen Simpson Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: new pppext-authentication draft References: <632.bill.simpson@um.cc.umich.edu> Organization: Morning Star Technologies, Inc. William Allen Simpson writes concerning removing the callback field from CHAP: > But I do want to give the implementors time to scream if it's a real > problem with fielded implementations, so that we can come up with a > migration plan. As one of the few current implementors of CHAP, I am very much in favor of removing the callback field because 1) I never thought it belonged in a security option in the first place, and 2) I never implemented callback. Maybe (2) is partially because of (1). Even though supporting both the old and new CHAP option formats will add Yet More Cruft to our implementation. Fortunately, the option lengths are different. From ietf-ppp-request@ucdavis.ucdavis.edu Sat Aug 15 15:40:21 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22878; Sat, 15 Aug 92 15:36:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27621; Sat, 15 Aug 92 15:19:22 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22359; Sat, 15 Aug 92 15:10:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22222; Sat, 15 Aug 92 15:04:50 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11321; Sat, 15 Aug 92 15:02:52 -0700 Date: Sat, 15 Aug 92 14:42:37 EDT From: "William Allen Simpson" Message-Id: <633.bill.simpson@um.cc.umich.edu> To: Van Jacobson Cc: Greg Vaudreuil , Brian Lloyd , The PPPext WG , The IESG Subject: Re: TCP/IP Header Compression For some reason, I never saw this message to the PPP list. Here is my belated reply. > From: Van Jacobson > > Bill Simpson noted that several fixes were needed to the algorithm as > > documented in RFC1144. He offered CSLIP as a reference implementation > > to base changes to RFC1144. > I was referring to the cslip reference in RFC 1144. I assumed that it had been updated, and we should include any newer code in the next RFC. I have since looked at the file -- it seems even older than the RFC code, and is called cslip-beta. Therefore, *both* the cslip reference *and* the sample code should be updated. > This is the first I've heard of fixes needed to the algorithm in > 1144. Could someone tell me what they are? Thanks. I know of > 3 one-line fixes that should be made to the sample code in > appendix A of 1144 but the algorithm & the sample code are, of > course, completely different things. > No, the _algorithm_ is fine, as far as I know. It was the _sample code_ that I meant. There are some text definitions that could use cleaning up ("conversations" versus "connection id" versus "slots"). And what to do when an identifier, window, urgent pointer, acknowlegement or sequence number went "backward" (resulting in a negative number). It's too subtle in the current text. Could you please send the 3 one-line fixes to this (ietf-ppp) list? I'm sure we would all be glad to test a new reference implementation. > Also could someone point me at Bill Simpson's CSLIP reference > implementation? Thanks. > I have done several implementations of PPP which include variants of your sample code, with fixes that were discussed in the past. One of them is in KA9Q. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Aug 15 15:50:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23124; Sat, 15 Aug 92 15:46:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27644; Sat, 15 Aug 92 15:24:14 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22363; Sat, 15 Aug 92 15:10:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22237; Sat, 15 Aug 92 15:05:10 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA11327; Sat, 15 Aug 92 15:03:18 -0700 Date: Sat, 15 Aug 92 15:55:09 EDT From: "William Allen Simpson" Message-Id: <635.bill.simpson@um.cc.umich.edu> To: IESG Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: Last Call: Point-to-Point Protocol Extensions for DECnet Well, I was beaten into submission by the vendors at Boston IETF, and relented on requiring all DECnet protocols over PPP. If and when that ever happens, I expect that this draft will be expanded. Also, I relented on the (little-endian) length field. It is inconsistent with all other PPP protocols (big-endian). However, as the draft states, the field is the same as used for ethernet. "A foolish consistency ...." ---- Therefore, I have only editorial requests for changes: The title should be "PPP DECnet Control Protocol (DNCP)" to be consistent with the other PPP protocols. PPP is *not* _extended_ for DECnet, this is merely another configuration control protocol (and a NULL one at that). The terminology needs to be updated to that of RFC 1331 (this was written for 1171). "Open" -> "Opened", etc. It needs a paragraph explaining when LCP frame modifications apply. This has been a problem in other control protocol implementations. I would recommend looking at the AppleTalk CP draft, and slavishly copying the boiler-plate in that document. Should affect only a dozen or so lines. ---- With these modifications, I recommend that it be accepted. There is sufficient implementation experience. I recommend that it be published with the AppleTalk, IPX and ISO CPs when they are completed. We have last calls on those, don't we? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sun Aug 16 05:20:05 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07297; Sun, 16 Aug 92 05:15:03 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29327; Sun, 16 Aug 92 04:59:23 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06970; Sun, 16 Aug 92 04:50:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06843; Sun, 16 Aug 92 04:43:57 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA12070; Sun, 16 Aug 92 04:42:10 -0700 Date: Sat, 15 Aug 92 22:03:36 EDT From: "William Allen Simpson" Message-Id: <641.bill.simpson@um.cc.umich.edu> To: brad@cayman.com Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: appletalk-02 Brad: I was looking through your draft for the connect time option, and came across a typo. The "incremented \n received" probably should say "incremented when it is received" or something on that order. Brian wants his address changed to brian@lloyd.com. Also, you should probably get the correct address for John Viezades. Anyway, are you amenable to moving the connect time option to LCP? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sun Aug 16 05:30:19 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07476; Sun, 16 Aug 92 05:25:46 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29343; Sun, 16 Aug 92 05:02:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06973; Sun, 16 Aug 92 04:50:10 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06845; Sun, 16 Aug 92 04:44:16 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA12073; Sun, 16 Aug 92 04:42:16 -0700 Date: Sat, 15 Aug 92 22:13:41 EDT From: "William Allen Simpson" Message-Id: <642.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Cc: iab@isi.edu, iesg@nri.reston.va.us Subject: messages in PPP options One of the things we were held up by with PPP Authentication is the message format and character set issue. It has also recently appeared with regard to SMTP on the ietf list. My compromise with Steve Kent was: The Message field is zero or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain ASCII text, and it need not be NUL or CR/LF terminated. However, the Appletalk CP (which is under "last call") also has informative messages which say: The Data field is zero or more octets representing the status code in human-readable terms. The text message is restricted to the NVT ASCII character set, as defined in pages 10-11 of [TELNET]. and This field contains the "AppleTalk ASCII" zone name in which the server resides. The character codes used in "AppleTalk ASCII" are defined in [Inside AppleTalk], appendix D, "Character codes". I am ASCIIng for guidance by the "powers that be". (Isn't that what an Architecture Board or Steering Group should be about?) I would like a consistant answer, so that future steps will be as painless as possible. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 17 10:50:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16625; Mon, 17 Aug 92 10:42:35 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04766; Mon, 17 Aug 92 10:06:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14554; Mon, 17 Aug 92 09:42:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14411; Mon, 17 Aug 92 09:36:12 -0700 Received: from na.novell.com. (na.Novell.COM) by newsun.novell.com with SMTP id AA01999 (5.65c/IDA-1.4.4 for ); Mon, 17 Aug 1992 09:34:27 -0700 Received: by na.novell.com. (4.1/SMI-4.1) id AA11572; Mon, 17 Aug 92 09:37:04 PDT Date: Mon, 17 Aug 92 09:37:04 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9208171637.AA11572@na.novell.com.> To: bill.simpson@um.cc.umich.edu Subject: Re: Last Call: Point-to-Point Protocol Extensions for DECnet Cc: ietf-ppp@ucdavis.ucdavis.edu Hi Bill, You wrote: > I recommend that it be published with the AppleTalk, IPX and ISO CPs > when they are completed. We have last calls on those, don't we? I think we're in last call stage for AppleTalk and OSI. But, I thought we had substantial changes to make after the IETF meeting at Shiva a month ago. It certainly hasn't come out as new new I-D since then. Or, am I in a black hole? Chris From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 17 10:51:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16773; Mon, 17 Aug 92 10:45:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA04962; Mon, 17 Aug 92 10:19:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15704; Mon, 17 Aug 92 10:16:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from venera.isi.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15229; Mon, 17 Aug 92 10:02:28 -0700 Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Mon, 17 Aug 1992 10:00:23 -0700 Date: Mon, 17 Aug 1992 09:59:29 -0700 From: postel@ISI.EDU Posted-Date: Mon, 17 Aug 1992 09:59:29 -0700 Message-Id: <199208171659.AA04236@bel.isi.edu> Received: by bel.isi.edu (5.65c/4.0.3-4) id ; Mon, 17 Aug 1992 09:59:29 -0700 To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: messages in PPP options Cc: iab@ISI.EDU, iesg@nri.reston.va.us Bill: From a personal technical viewpoint i think both groups are playing too fast and loose. I'd suggest that in all cases the message be restricted to the NVT ASCII character set, as defined in pages 10-11 of [TELNET]. --jon. From bill.simpson@um.cc.umich.edu Sun Aug 16 04:42:36 1992 Date: Sat, 15 Aug 92 22:13:41 EDT From: "William Allen Simpson" To: ietf-ppp@ucdavis.edu Cc: iab@ISI.EDU, iesg@nri.reston.va.us Subject: messages in PPP options One of the things we were held up by with PPP Authentication is the message format and character set issue. It has also recently appeared with regard to SMTP on the ietf list. My compromise with Steve Kent was: The Message field is zero or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain ASCII text, and it need not be NUL or CR/LF terminated. However, the Appletalk CP (which is under "last call") also has informative messages which say: The Data field is zero or more octets representing the status code in human-readable terms. The text message is restricted to the NVT ASCII character set, as defined in pages 10-11 of [TELNET]. and This field contains the "AppleTalk ASCII" zone name in which the server resides. The character codes used in "AppleTalk ASCII" are defined in [Inside AppleTalk], appendix D, "Character codes". I am ASCIIng for guidance by the "powers that be". (Isn't that what an Architecture Board or Steering Group should be about?) I would like a consistant answer, so that future steps will be as painless as possible. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 17 11:02:42 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16997; Mon, 17 Aug 92 10:52:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05030; Mon, 17 Aug 92 10:25:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15726; Mon, 17 Aug 92 10:17:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15369; Mon, 17 Aug 92 10:05:07 -0700 Received: from na.novell.com. (na.Novell.COM) by newsun.novell.com with SMTP id AA02721 (5.65c/IDA-1.4.4 for ); Mon, 17 Aug 1992 10:03:22 -0700 Received: by na.novell.com. (4.1/SMI-4.1) id AA12482; Mon, 17 Aug 92 10:05:45 PDT Date: Mon, 17 Aug 92 10:05:45 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9208171705.AA12482@na.novell.com.> To: bill.simpson@um.cc.umich.edu, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: messages in PPP options Cc: iab@isi.edu, iesg@nri.reston.va.us Hi Y'all, Bill wrote about messages, and raised a very relevant issue. I believe some background is in order so we can move forward with this. > From: "William Allen Simpson" > To: ietf-ppp@ucdavis.edu > Cc: iab@isi.edu, iesg@nri.reston.va.us > Subject: messages in PPP options > > One of the things we were held up by with PPP Authentication is the > message format and character set issue. It has also recently appeared > with regard to SMTP on the ietf list. > > My compromise with Steve Kent was: > > The Message field is zero or more octets, and its contents are > implementation dependent. It is intended to be human readable, > and MUST NOT affect operation of the protocol. It is recommended > that the message contain ASCII text, and it need not be NUL or > CR/LF terminated. Sounds quite reasonable (to an observer). > However, the Appletalk CP (which is under "last call") also has > informative messages which say: > > The Data field is zero or more octets representing the status code > in human-readable terms. The text message is restricted to the > NVT ASCII character set, as defined in pages 10-11 of [TELNET]. Again, as an observer, I understood the decision to choose this was so we could reference SOMETHING for message encoding. But... > and > > This field contains the "AppleTalk ASCII" zone name in which the > server resides. The character codes used in "AppleTalk ASCII" are > defined in [Inside AppleTalk], appendix D, "Character codes". This MUST remain is it worded. Zone names are defined in AppleTalk, and are used in many places. These characters ultimately appear in a workstation's (Mac's) service locator (Chooser). Often, they use upper-half character values. > I am ASCIIng for guidance by the "powers that be". (Isn't that what > an Architecture Board or Steering Group should be about?) > > I would like a consistant answer, so that future steps will be as > painless as possible. I agree about consistency about the first two, but we MUST leave the third as it is. > Bill.Simpson@um.cc.umich.edu Chris Ranch From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 19 10:24:03 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07083; Wed, 19 Aug 92 10:18:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21812; Wed, 19 Aug 92 10:02:24 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06494; Wed, 19 Aug 92 09:58:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06079; Wed, 19 Aug 92 09:43:58 -0700 Received: from cuba.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA24572; Wed, 19 Aug 92 12:42:20 EDT Received: from cuba by cuba.Cayman.COM (4.1/SMI-4.1) id AA18018; Wed, 19 Aug 92 12:42:19 EDT Message-Id: <9208191642.AA18018@cuba.Cayman.COM> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: appletalk-02 In-Reply-To: Mail from "William Allen Simpson" dated Sat, 15 Aug 92 22:03:36 EDT <640.bill.simpson@um.cc.umich.edu> Date: Wed, 19 Aug 92 12:42:18 -0400 From: Brad Parker fyi: I'm no longer employed by Cayman, but they are letting me read mail & news for a few weeks (shortly I'll have access to a site with a T3 feed!), so there's no need to change anything. A draft with the changes you asked for is on ftp.cayman.com in pub/ppp/ppp-atcp-aug-19-92. I'll puruse my folder on the last ietf tommorrow to make sure nothing was left out from the last IETF. My only objection about moving connect time to the LCP is that it will delay the movement of the ppp-appletalk doc ;-) I want to put this thing to bed. (other than that, however, it seems fine to me; personally I think connect-time option is not well thought out - we added it to get the apple people to buy in) -brad From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 19 15:15:54 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16633; Wed, 19 Aug 92 15:07:49 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24580; Wed, 19 Aug 92 14:41:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15619; Wed, 19 Aug 92 14:34:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15115; Wed, 19 Aug 92 14:20:54 -0700 Received: from na.novell.com. (na.Novell.COM) by newsun.novell.com with SMTP id AA01701 (5.65c/IDA-1.4.4 for ); Wed, 19 Aug 1992 14:19:02 -0700 Received: by na.novell.com. (4.1/SMI-4.1) id AA20439; Wed, 19 Aug 92 14:21:43 PDT Date: Wed, 19 Aug 92 14:21:43 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9208192121.AA20439@na.novell.com.> To: brad@Cayman.COM, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: appletalk-02 Hi Brad, et al, > From: Brad Parker > > fyi: I'm no longer employed by Cayman, but they are letting me read > mail & news for a few weeks (shortly I'll have access to a site with a > T3 feed!), so there's no need to change anything. Will you be able to see this to proposed standard stage? If not, I'd be willing to make sure it happens (now that the work is done ;). > A draft with the changes you asked for is on ftp.cayman.com in > pub/ppp/ppp-atcp-aug-19-92. > > I'll puruse my folder on the last ietf tommorrow to make sure nothing was > left out from the last IETF. > > My only objection about moving connect time to the LCP is that it will > delay the movement of the ppp-appletalk doc ;-) I want to put this > thing to bed. (other than that, however, it seems fine to me; > personally I think connect-time option is not well thought out - we > added it to get the apple people to buy in) It REALLY belongs in LCP. It doesn't make sense to just close an NCP while other NCP's are open. After all, the resource being conserved is the modem, right? Delay in its removal will result in delay in approval (Yikes...). > -brad I'm still confused by the Appendix A IS-IS w/network numbers. What's it for? Why? Shouldn't we axe the compression option? Looks pretty empty to me. LCP compression is a start... Chris From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 19 21:52:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22033; Wed, 19 Aug 92 21:46:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27074; Wed, 19 Aug 92 21:30:49 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21761; Wed, 19 Aug 92 21:22:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21728; Wed, 19 Aug 92 21:17:49 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA16960; Wed, 19 Aug 92 21:15:55 -0700 Date: Wed, 19 Aug 92 23:07:23 EDT From: "William Allen Simpson" Message-Id: <651.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: appletalk-02 > A draft with the changes you asked for is on ftp.cayman.com in > pub/ppp/ppp-atcp-aug-19-92. > Hmmm... Looks fine, except it still has the connect-time option in it. > My only objection about moving connect time to the LCP is that it will > delay the movement of the ppp-appletalk doc ;-) I want to put this > thing to bed. So do I! It will not delay the movement of ATCP (taking things out shouldn't hurt.) And if you rip out the connect time option, you can avoid the text definition problem, too. > (other than that, however, it seems fine to me; > personally I think connect-time option is not well thought out - we > added it to get the apple people to buy in) > > -brad > Just tell the Apple people that we liked the idea so well, that it is now available to everyone.... ;-> Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Thu Aug 20 08:30:56 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA13649; Thu, 20 Aug 92 08:28:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA29577; Thu, 20 Aug 92 08:09:27 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12825; Thu, 20 Aug 92 08:02:42 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from newsun.Novell.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12484; Thu, 20 Aug 92 07:53:26 -0700 Received: from na.novell.com. (na.Novell.COM) by newsun.novell.com with SMTP id AA07632 (5.65c/IDA-1.4.4 for ); Thu, 20 Aug 1992 07:50:43 -0700 Received: by na.novell.com. (4.1/SMI-4.1) id AA23588; Wed, 19 Aug 92 17:41:46 PDT Date: Wed, 19 Aug 92 17:41:46 PDT From: cranch@novell.com (Christopher Ranch) Message-Id: <9208200041.AA23588@na.novell.com.> To: rfc-editor@isi.edu Subject: IPXWAN Informational RFC Submittal Cc: ietf-ppp@ucdavis.ucdavis.edu Hello, Please consider the attached memo as Michael Allen's submission for an informational rfc. Please advise as to what the next steps are in the process. Regards and thanks, Chris and Michael cut here -> Network Working Group M. Allen Request for Comments: Novell, Inc. August 1992 Novell IPX Over Various WAN Media [IPXWAN] Status of this Memo This memo is for informational purposes only, and describes how Novell IPX operates with IETF defined WAN oriented protocols. It does not specify an Internet standard. Its distribution is unlimited. Abstract This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocol Novell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. Table of Contents 1. Introduction ........................................ 2 1.1. Operation Over PPP ............................. 2 1.2. Operation Over X.25 Switched Virtual Circuits .. 2 1.3. Operation Over X.25 Permanent Virtual Circuits . 3 1.4. Operation Over Frame Relay ..................... 3 1.5. Operation Over Other WAN Media ................. 3 2. Glossary Of Terms ................................... 4 3. IPX WAN Protocol Description ........................ 5 4. Information Exchange Packet Formats ................. 6 4.1. Timer Request Packet ........................... 7 4.2. Timer Response Packet .......................... 9 4.3. Information Request Packet ..................... 11 4.4. Information Response Packet .................... 13 5. References .......................................... 14 6. Security Considerations ............................. 14 7. Contact Points ...................................... 14 Allen [Page 1] RFC XXXX IPXWAN August 1992 1. Introduction This document describes how Novell IPX operates over various WAN media. It is strongly motivated by a desire for IPX to treat ALL wide area links in the same manner. Sections 3 and 4 describe this common "IPX WAN" protocol. IPX WAN protocol operation begins immediately after link establishment. While IPX is a connectionless datagram protocol, WANs are often connection-oriented. Different WANs have different methods of link establishment. The subsections of section 1 of this document describe what link establishment means to IPX for different media. They also describe other WAN-media-dependent aspects of IPX operation, such as protocol identification, frame encapsulation, and link tear down. 1.1 Operation Over PPP IPX uses PPP [1] when operating over point-to-point synchronous and asynchronous networks. With PPP, link establishment means the IPX NCP [4] reaches the Open state. NetWare IPX will reject all NCP options, and uses normal frame encapsulation as defined by PPP. The IPXWAN protocol MUST NOT occur until the IPX NCP reaches the Open state. PPP allows either side of a connection to stop forwarding IPX if one end sends an IPXCP or an LCP Terminate-Request. When a router detects this, it will immediately reflect the lost connectivity in its routing information database instead of naturally aging it out. 1.2 Operation over X.25 Switched Virtual Circuits With X.25, link establishment means successfully opening an X.25 virtual circuit. As specified in RFC-1356, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [2], the protocol identifier 0x800000008137 is used in the X.25 Call User Data field of the Call Request frame, and indicates that the virtual circuit will be devoted to IPX. Furthermore, each IPX packet is encapsulated directly in X.25 data frame sequences without additional framing. Either side of the virtual circuit may close it, thereby tearing down the IPX link. When a router detects this, it will immediately reflect the lost connectivity in its routing information database instead of naturally aging it out. Allen [Page 2] RFC XXXX IPXWAN August 1992 1.3 Operation over X.25 Permanent Virtual Circuits The nature of X.25 PVC's is that no call request is made. When the router is informed that X.25 Layer 2 is up, the router should assume that link establishment is complete. Each IPX packet is encapsulated in an X.25 data frame sequence without additional framing. Novell IPX assumes a particular X.25 permanent circuit is devoted to the use of IPX. If a router receives a layer 2 error condition (e.g., X.25 Restart), it should reflect lost connectivity for the permanent circuits in its routing information database and re- perform the necessary steps to obtain a full IPX connection. 1.4 Operation over Frame Relay Novell conforms to RFC-1294, "Multiprotocol Interconnect over Frame Relay" [3] for frame relay service and packet encapsulation. Currently Novell has not stabalized the method for treating frame relay connections - whether they treat the connections as LANs or WANs. 1.5 Operation over other WAN media Additional WAN media will be added here as specifications are developed. Allen [Page 3] RFC XXXX IPXWAN August 1992 2. Glossary Of Terms Primary Network Number: Every IPX WAN router has a 'primary network number'. This is an IPX network number unique to the entire internet. This number will be a permanently assigned network number for the router. Those readers familiar with NetWare 3.x servers should realize that this is the 'Internal' network number. Router Name: Every IPX WAN router must have a "Router Name". This is a symbolic name given to the router. Its purpose is to allow routers to know who they are connected to after link establishment - particularly for network management purposes. A symbolic name conveys more information to an operator than a set of numbers. The symbolic name should be between 1 and 47 characters in length containing the characters 'A' through 'Z', underscore (_), hyphen (-) and "at" sign (@). The string of characters should be followed by a null character (byte of zero) and padded to 48 characters using the null character. Those readers familiar with NetWare 3.x servers should realize that the file server name is the Router Name. Allen [Page 4] RFC XXXX IPXWAN August 1992 3. IPX WAN Protocol Description IPX WAN links have the concept of a LINK MASTER and a LINK SLAVE. This relationship is decided upon based on information contained within the first IPX packets transferred across the WAN link. After link establishment, both sides of the link send "Timer Request" packets and start a timer waiting for a "Timer Response". These "Timer Request" packets are sent every 20 seconds until a response is received or a time-out occurs trying to initialize a connection (the timer is restarted each time a new "Timer Request" is sent). The time-out should be configurable, and is normally about one minute. This is directly dependant on the call setup time for the connection. If a time-out occurs, the router issues a disconnect on the offending connection and optionally attempts to retry the connection. When a "Timer Request" is received, the router with the lowest primary network number MUST respond with a "Timer Response" packet - and become the "Slave" of the link. If the "Slave" determines that it cannot support any of the Routing Types included in the "Timer Request" packet, the "Slave" should issue a disconnect on the connection being established. The "Master" of the link (determined when a "Timer Response" packet is received) is responsible for defining the network number that is to be used as a common network number for the new WAN link, and for calculating the RIP transport time that will be advertized to other RIP routers for the new link. This is calculated by stopping the timer which was started when a "Timer Request" was initiated and applying the algorithm in section 4.2. To allow this, both sides of the link MUST have an adequate pool of WAN network numbers (unique within the internetwork) available to be assigned to the link when the call is fully completed. The "Master" of the link MUST then select a network number and construct an "Information Request" packet containing the calculated link delay, the common network number, and its own router name. On receiving this packet, the "Slave" MUST turn the packet around, overwrite the router name and node identifier and send an "Information Response". After the "Master" has received the "Information Response" and the "Slave" has received the "Information Request", standard IPX RIP and SAP packets are transferred across the WAN link, as currently defined for LAN links. The "IPX Router Specification" [5] contains information describing the Novell RIP/SAP protocol for third party developers. Allen [Page 5] RFC XXXX IPXWAN August 1992 Note that the "Information Request" and "Information Response" packets are specific to the "Routing Type"=0 information exchanges. With this routing type, no retransmission is made of any of the Information packets. If a response has not been received within the predefined time- out period, a disconnect is issued on the link, and the link can optionally be attempted later. If a router detects an error for which no suitable protocol response exists (e.g., unable to allocate a network number), the link should be terminated according to the relevant media specification. Under certain circumstances, particularly on X.25 permanent circuits, it is only possible to detect the remote router went away when it comes back up again. In this case, one side of the link receives a Timer Request packet when IPX is in a fully connected state. The side receiving the Timer Request MUST realize that a problem occurred, and revert to the IPX link establishment phase. Furthermore, the routing information learned from this connection should be immediately discarded. 4. Information Exchange Packet Formats All IPX WAN information exchange packets conform to the standard Novell IPX packet format. The packets use the IPX defined packet type 04 defining a Packet Exchange Packet. The socket number 0x9004 is a Novell reserved socket number for exclusive use with IPX WAN information exchange. IPX defines that a network number of 0 is interpreted as being a local network of unknown number that requires no routing. This feature is of use to us in transferring these packets before the common network number is exchanged. Some routers need to know a "Node Number" (or MAC address) for each node on a link. Node numbers will be formed from the "WNode ID" field. The node number will be the 4 bytes of WNode ID followed by 2 bytes of zero. Router Type number assignment. Other vendors IPX routing protocols can make use of the IPXWAN protocol definition by obtaining Router Types from Novell. This document will then include the new Router Types (with the references to vendor protocol description documents). WOption Number assignment. These numbers only need to be assigned from Novell for the "Timer Request" and "Timer Response" packets. Other packet types (e.g., the "Information Request" packets, are dependant on the "Router Type" negotiated and can contain any (vendor defined) packet type other than 0 or 1. WOption numbers in these packets are then defined by the vendor defining the Routing Type. The same packet format should still be maintained. Allen [Page 6] RFC XXXX IPXWAN August 1992 4.1 Timer Request Packet +---------------------------------------------------------------+ | Checksum | FF FF | Always FFFF | | Packet Length | 02 40 | Max IPX size (576 bytes| | | | Hi Lo order) | | Trans Control | 00 | Hops traversed | | Packet Type | 04 | Packet Exchange Packet | | Dest Net # | 00 00 00 00 | Local Network | | Dest Node # | FF FF FF FF FF FF | Broadcast | | Dest Socket # | 90 04 | Reserved WAN socket | | Source Net # | 00 00 00 00 | Local Network | | Source Node # | 00 00 00 00 00 00 | Set to zero | | Source Socket # | 90 04 | Reserved WAN socket | |------------------+-------------------+------------------------| | WIdentifier | 57 41 53 4D | Confidence identifier | | WPacket Type | 00 | Timer Request | | WNode ID | xx xx xx xx | Primary Net # of | | | | sending router | | | | (Hi Lo order) | | WSequence # | xx | Sequence start at 0 | | WNum Options | 02 | 2 Options follow | | WOption Number | 00 | Define Routing Type | | WAccept Option | 01 | 0=No,1=Yes,3=Not Applic| | WOption Data Len | 00 01 | Option length (Hi Lo) | | WOption Data | 00 | IPX RIP/SAP Routing | | WOption Number | FF | Pad option | | WAccept Option | 01 | 0=No,1=Yes,3=Not Applic| | WOption Data Len | 02 0E | Pad data length (Hi Lo)| | WOption Data | 00->FF's | Repeated sequence of 00| | | | through FF's. | +---------------------------------------------------------------+ Note: Timer Request packets will always be 576 bytes. However, there should be no assumption made about the number of options specified in this packet. After link establishment, Timer Request packets are sent by both sides of the link. Each end starts their sequence number at zero. Subsequent retries (every 20 seconds) will increment the value of this sequence number. Only a Timer Response packet with a sequence number matching the last sent sequence number will be acted upon. When receiving this packet, the WNode ID should be compared to the receiver's Primary Network #. If the WNode ID is larger than the receiver's Primary Network #, a Timer Response packet should be sent, and the receiver should become the link "Slave". Packets received on the reserved socket number not having the WIdentifier set to the hexadecimal values noted above should be discarded. Allen [Page 7] RFC XXXX IPXWAN August 1992 Routing Type Option: A routing type of zero (0) is the minimum interoperability requirement (as defined by this document). A router ready to send a Timer Response (and receiving a routing type of zero) MUST respond with a routing type of zero. A router ready to send a Timer Response (and receiving routing types not matching a supported value) SHOULD respond with a Routing Type of zero indicating support for the minimum common protocol. Note that multiple Routing Type Options can be included in the Timer Request packet if the router supports multiple routing methods for IPX. The included Router Types MUST include and support this type zero option. Accept Option (for Routing Type and PAD options): This field MUST be set to YES if the option is supported, and NO if an option is not supported. A Timer Response MUST respond with ONLY one Router Type set to YES. PAD Option: This option will normally be the last entry in the packet. Its sole purpose is to fill the IPX packet to be 576 bytes. The pad option data will contain a repeating sequence of zero's through 0xFF's. This should stop compression modems from collapsing the packet and destroying the link delay calculation. Currently Assigned WOption Numbers (Timer Request Packet): Routing Type Option = 0x00; Option Length = 0001 Current option data values: 0 Novell RIP/SAP routing with network number assigned to the link. PAD Type Option = 0xFF; Option Length = Variable Compression Option = 0x80; Option Length = Variable (length dependant on compression type) Current option data values: Byte 1 Compression type 0 = Telebit compression (length=3) [6] Telebit Byte 2 - Compression options Telebit Byte 3 - Number compression slots Allen [Page 8] RFC XXXX IPXWAN August 1992 4.2. Timer Response Packet +---------------------------------------------------------------+ | Checksum | FF FF | Always FFFF | | Packet Length | 02 40 | Max IPX size (576 bytes| | | | Hi Lo order) | | Trans Control | 00 | Hops traversed | | Packet Type | 04 | Packet Exchange Packet | | Dest Net # | 00 00 00 00 | Local Network | | Dest Node # | FF FF FF FF FF FF | Broadcast | | Dest Socket # | 90 04 | Reserved WAN socket | | Source Net # | 00 00 00 00 | Local Network | | Source Node # | 00 00 00 00 00 00 | Set to zero | | Source Socket # | 90 04 | Reserved WAN socket | |------------------+-------------------+------------------------| | WIdentifier | 57 41 53 4D | Confidence identifier | | WPacket Type | 01 | Timer Response | | WNode ID | xx xx xx xx | Primary Net # of | | | | sending router | | | | (Hi Lo order) | | WSequence # | xx | Same as Timer Request | | | | received | | WNum Options | 02 | 2 Options follow | | WOption Number | 00 | Define Routing Type | | WAccept Option | 01 | 0=No,1=Yes,3=Not Applic| | WOption Data Len | 00 01 | Option length (Hi Lo) | | WOption Data | 00 | IPX RIP/SAP Routing | | | | (Minimum interoperating| | | | requirement). Others | | | | may be defined by at a | | | | later date by Novell | | WOption Number | FF | Pad option | | WAccept Option | 01 | 0=No,1=Yes,3=Not Applic| | WOption Data Len | 02 0E | Pad data length (Hi Lo)| | WOption Data | 00->FF's | Repeated sequence of 00| | | | through FF's to stop | | | | compression modems | | | | doing any compression | | | | for link delay calc. | +---------------------------------------------------------------+ The responses contained within this packet are as described in section 4.1. Any unknown options or not supported options from the Timer Request should have the WAccept Option set to NO. If the Timer Request packet contained more than one Router Type option and the "Slave" supports all the options, the "Slave" should set the WAccept Option to NO on all Router Types except the Routing Type which is to be adopted. The "Master" of the link will then adopt the routing option specified with the YES setting and complete further information exchanges according to that routing standard. Allen [Page 9] RFC XXXX IPXWAN August 1992 This packet should contain the same sequence number as the received Timer Request. This packet should ONLY be sent by the router determining themselves to be the "Slave" of the link. Currently Assigned WOption Numbers (Timer Response Packet): Routing Type Option = 0x00; Option Length = 0001 Current option data values: 0 Novell RIP/SAP routing with network number assigned to the link. PAD Type Option = 0xFF; Option Length = Variable Compression Option = 0x80; Option Length = Variable (length dependant on compression type) Current option data values: Byte 1 Compression type 0 = Telebit compression (length=3) [6] Telebit Byte 2 - Compression options Telebit Byte 3 - Number compression slots Allen [Page 10] RFC XXXX IPXWAN August 1992 4.3. RIP/SAP Information Request Packet (Router Type=0 Only) +---------------------------------------------------------------+ | Checksum | FF FF | Always FFFF | | Packet Length | 00 63 | Size of header+data | | | | (Hi Lo order) | | Trans Control | 00 | Hops traversed | | Packet Type | 04 | Packet Exchange Packet | | Dest Net # | 00 00 00 00 | Local Network | | Dest Node # | FF FF FF FF FF FF | Broadcast | | Dest Socket # | 90 04 | Reserved WAN socket | | Source Net # | 00 00 00 00 | Local Network | | Source Node # | 00 00 00 00 00 00 | Set to zero | | Source Socket # | 90 04 | Reserved WAN socket | |------------------+-------------------+------------------------| | WIdentifier | 57 41 53 4D | Confidence identifier | | WPacket Type | 02 | Information Request | | WNode ID | xx xx xx xx | Primary Net # of | | | | sending router | | | | (Hi Lo order) | | WSequence # | 00 | Sequence start at 0 | | WNum Options | 01 | 1 Option to follow | | WOption Number | 01 | Define IPX RIP/SAP | | | | info exchange | | WAccept Option | 01 | 0=No,1=Yes,3=Not Applic| | WOption Data Len | 00 36 | Option length (Hi Lo) | | WOption Data | | | | Link Delay | xx xx | Hi Lo link delay in | | | | milli seconds (see | | | | below for calculation) | | Common Net # | xx xx xx xx | Hi Lo Common Network # | | Router Name | xx (x 48 decimal) | Router name - as defned| | | | in section 2. | +---------------------------------------------------------------+ Calculation of link delay is performed as follows: // Start_time is a time stamp when Timer Request sent out // End_time is a time stamp when a Timer Response is // received. link_delay = end_time - start_time; // 1/18th second // We are on a slow net, so add some biasing to help stop // multiple workstation sessions timing out on the link if (link_delay < 1) { link_delay = 1; }/*IF*/ link_delay *= 6; // Add the biasing link_delay *= 55; // Convert link delay to milliseconds Allen [Page 11] RFC XXXX IPXWAN August 1992 The "Link Delay" is used as the network transport time when advertized in the IPX RIP packet tuple for the network entry "Common Net #". For a consistent network, a common link delay is required at both ends of the link and is calculated by the link "Master". The Common Net # is supplied by the link "Master". This number must be unique in the connected internetwork. Each WAN call requires a seperate number. Currently only a single option is defined for the "Information Request" packet for Routing Type=0. Allen [Page 12] RFC XXXX IPXWAN August 1992 4.4. RIP/SAP Information Response Packet (Router Type=0 Only) +---------------------------------------------------------------+ | Checksum | FF FF | Always FFFF | | Packet Length | 00 63 | Size of header+data | | | | (Hi Lo Order) | | Trans Control | 00 | Hops traversed | | Packet Type | 04 | Packet Exchange Packet | | Dest Net # | 00 00 00 00 | Local Network | | Dest Node # | FF FF FF FF FF FF | Broadcast | | Dest Socket # | 90 04 | Reserved WAN socket | | Source Net # | 00 00 00 00 | Local Network | | Source Node # | 00 00 00 00 00 00 | Set to zero | | Source Socket # | 90 04 | Reserved WAN socket | |------------------+-------------------+------------------------| | WIdentifier | 57 41 53 4D | Confidence identifier | | WPacket Type | 03 | Information Response | | WNode ID | xx xx xx xx | Primary Net # of | | | | sending router | | | | (Hi Lo order) | | WSequence # | 00 | Sequence start at 0 | | WNum Options | 01 | 1 Option to follow | | WOption Number | 01 | Define IPX RIP/SAP | | | | info exchange | | WAccept Option | 01 | 0=No,1=Yes,3=Not Applic| | WOption Data Len | 00 36 | Option length (Hi Lo) | | WOption Data | | | | Link Delay | xx xx | Hi Lo link delay (as | | | | received in Info Requ) | | Common Net # | xx xx xx xx | Hi Lo Common Network # | | | | (as received in Info | | | | request) | | Router Name | xx (x 48 decimal) | Router name - as defned| | | | in section 2. | +---------------------------------------------------------------+ The responses contained within this packet are as described in section 4.3. Allen [Page 13] RFC XXXX IPXWAN August 1992 5. References [1] Simpson, W. A., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links", RFC-1331, May 1992. [2] Malis, Robinson, Ullman, "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC-1356, August 1992. [3] Bradley, Brown, Malis, "Multiprotocol Interconnect over Frame Relay", RFC-1294, January 1992. [4] Simpson, W. A., "The PPP Internetwork Packet Exchange Control Protocol (IPXCP) compromise version", Internet-Draft, July 1992, obsoleted by all subsequent I-D's and the forthcoming RFC. [5] Novell IPX Router Specification. Novell Part Number 107-000029-001. Currently this document is only available as part of a Novell developers program as part of an SDK. Novell Labs, Provo (UT) should be able to provide more information on this document. [6] Lewis, M., Telebit Corp. (mlewis@telebit.com), "IPX Header Compression based on Van Jacobson Header Compression for TCP/IP", unpublished. [Editor: This document still needs to be produced.] 6. Security Considerations Security issues are not discussed in this memo. 7. Contact Points Author's Address: Michael Allen Novell, Inc., 2180, Fortune Drive, San Jose, CA 95131 EMail: MALLEN@NOVELL.COM Chair's Address: The working group can be contacted via the current chair: Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: brian@ray.lloyd.com Allen [Page 14] From ietf-ppp-request@ucdavis.ucdavis.edu Thu Aug 20 11:42:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20127; Thu, 20 Aug 92 11:39:36 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA01205; Thu, 20 Aug 92 10:29:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17485; Thu, 20 Aug 92 10:21:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [36.98.0.21] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17112; Thu, 20 Aug 92 10:11:03 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA17783; Thu, 20 Aug 92 10:07:59 -0700 Date: Thu, 20 Aug 92 10:26:48 EDT From: "William Allen Simpson" Message-Id: <654.bill.simpson@um.cc.umich.edu> To: brian@lloyd.com Cc: dlynch@interop.com, iab@ISI.EDU, iesg@NRI.Reston.VA.US, gvaudre@NRI.Reston.VA.US, ietf-ppp@ucdavis.ucdavis.edu Subject: Summary: protocol text message content Well, I asked. Now we have 5 different answers. > From: "Dan Lynch" > Picking Kanji would be ok, but allowing diversity insures that some > vendors will make a great deal of hay on a useless issue fromthe > buyers view. Let's just force a single solution. > > PS. If we were talking about local language user interface stuff here > I would be arguing for the opposite. > We are _indeed_ talking about local language user interface stuff. Vendors want to be able to sell into overseas markets. But the issue is more complicated than that. > From: brian@lloyd.com (Brian Lloyd) > The key factor here is that the field in > question plays no part in the protocol. No matter what you put in the > information field, the protocol still works and is fully and > completely interoperable. That is correct on the face of it. However (just to muddy the waters), in some implementations the message conveys information to the *user* about any access capacity or restrictions. For example, Merit uses the field to inform the user about access to dial-out modems, whether the line has a charging fee for use, whether the user is restricted by local network, regional network, or NSFnet AUP, etc. They used ASCII symbols ($) and an ASCII representation of a bit mask to do this, so that the field _could_ be picked up automatically by application software (but is actually used only for debugging at this time). Also, the message field exists because a simple ACK/NAK doesn't give you enough information about how to correct a problem, such as, "authentication server timeout", "host not available", "invalid username/password". The protocol *works* independently, but the protocol definition recognizes that it is *used* by humans. > The information field was added as an > afterthought because someone (Bill Simpson, I think; there was no such > field when I first started working on CHAP) thought it would be nice > to at least tell the user at the remote end why they were denied > access. > The message field was present in the PAP protocol in RFC 1172, and was approved by the IESG/IAB in the following form: Message The Message field is zero or more octets and indicates an ASCII message. When Brian proposed CHAP, it had no ACK/NAK feature. Such a feature was required for correct operation of the PPP state machine, so the ACK/NAK from PAP was used (with minor modifications). The message field description is the same for both protocols. Because some implementors wanted to avoid operating system dependent problems with text display, we added the words: It should not be NUL or CR/LF terminated. When internal content issues were raised, we added: Its contents are implementation dependent. For Steve Kent, we added: It is intended to be human readable, and MUST NOT affect operation of the protocol. ---- First, we need a way to describe the local character-set used for the message. The connect-time informational option uses NVT ASCII. This is probably a bad choice as it includes CRLFs, FFs and BELs, which I would prefer not to have in the message. However, Postel favors this. Vint Cerf is leaning toward a leading octet defining the character-set in use in the message. We can't use this in the case in question, since there are already implementations. Greg Vaudre suggested using the =? escape mechanism to describe the character-set. I suggested using 7-bit displayable ASCII for the default. If the leading octet has the 8th bit set, it is a IANA assigned number which indicates the escape mechanism used. This would be compatible with the ISO proposal(s), and upwardly compatible with current implementations. I think that this issue is not going away soon, and that the solution is not going to be decided in a week. Therefore, I will change the text to reference a future RFC. ---- Second, the message content issue may be addressed. Steve Kent expressed a desire for a leading octet signifying the content or format of the message for each vendor. I am opposed, since it would require modification of every PPP PAP implementation in the field. Another solution would be "nnn text" FTP/SMTP style responses, with every possible message listed. I think this is a use of the message field which is necessary now, but will be superceded if the CAT and NAS WGs ever get their act together. Therefore, I will leave the "implementation dependent" and "human readable" verbiage intact. Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 21 10:43:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28598; Fri, 21 Aug 92 10:32:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA09167; Fri, 21 Aug 92 09:44:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27025; Fri, 21 Aug 92 09:40:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [134.22.80.1] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26952; Fri, 21 Aug 92 09:37:29 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA15313; Fri, 21 Aug 92 12:35:33 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA14651; Fri, 21 Aug 92 12:35:30 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9208211635.AA14651@cannibal.gandalf.ca> Subject: 1331 State Machine To: bill.simpson@um.cc.umich.edu (William Allen Simpson) Date: Fri, 21 Aug 92 12:35:28 EDT Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <651.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Aug 19, 92 11:07 pm X-Mailer: ELM [version 2.3 PL11] Bill: There seems to be a small problem with the state machine for the negotiation automaton in RFC1331. I will first describe the sequence of events I encounter: (ends are A & B) 1. LCP progresses and both A and B get to Opened. 2. Close event at A. 3. A responds by tld, irc, str, and goes to Closing. 4. B experiences RTR and does tld, sta, zrc, and goes to Stopping. 5. Close event at B. 6. B responds by going to Closing (now A and B are both in Closing). 7. A gets RTA, does tlf, and goes to Closed. 8. B doesn't. No new events are forthcoming that make sense except a new Open event at B. We are saved by the restart option, since if B indeed does get an Open event at this point, a Down, followed by an Up will get us into Closed. However it does not get us to the point of sending another Config-Req, unless *another* Open event occurs. It seems strange to have both ends get Close commands and only one end fall all the way back to Closed. *** Fixes: 1) The response to a Close when in Stopping could be to go to Closed. 2) The description of the restart option could advise that in response to an Open when in Closing an Up, followed by a Down, followed by another Open should be issued to the state machine. 3) The description of the Closing state says: "A Terminate-Request has been sent and the Restart timer is running, but a Terminate-Ack has not yet been received." This is not true of B, however it got to the Closing state somehow. Perhaps the action when in Stopping upon a Close event should be to send a Terminate -Request and start the timer before entering Closing. This would better fit the definition of Closing, and allow a transition to Closed. A would already be in Closed and would simply do sta and stay there. This seems to be the only transition from another state to Closing that has the possibility of not having the timer started. I haven't looked at it exhaustively. *** Other than by doing 1) or 3) I can't see how B can get to Closed without an Open event, even though A got there. Am I missing something? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ "Hey hey, my my." Neil Young _Out_of_the_Blue_ (And_Into_the_Black)_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 21 11:11:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29564; Fri, 21 Aug 92 11:06:20 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10237; Fri, 21 Aug 92 10:49:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28861; Fri, 21 Aug 92 10:42:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28718; Fri, 21 Aug 92 10:37:46 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA20578; Fri, 21 Aug 92 13:35:47 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA14809; Fri, 21 Aug 92 13:35:44 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9208211735.AA14809@cannibal.gandalf.ca> Subject: Re: 1331 State Machine To: bill.simpson@um.cc.umich.edu Date: Fri, 21 Aug 92 13:35:43 EDT Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <9208211635.AA14651@cannibal.gandalf.ca>; from "Chris Sullivan" at Aug 21, 92 12:35 pm X-Mailer: ELM [version 2.3 PL11] > 2) > > The description of the restart option could advise that in response to > an Open when in Closing an Up, followed by a Down, followed by another Open > should be issued to the state machine. Sorry, make that a Down, followed by an Up, followed by another Open... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 21 12:51:27 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02721; Fri, 21 Aug 92 12:40:28 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10731; Fri, 21 Aug 92 11:49:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00940; Fri, 21 Aug 92 11:45:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00639; Fri, 21 Aug 92 11:34:37 -0700 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA11943; Fri, 21 Aug 92 14:32:43 -0400 Received: by remora.morningstar.com (5.65a/91072901) id AA05756; Fri, 21 Aug 92 14:32:37 -0400 Date: Fri, 21 Aug 92 14:32:37 -0400 From: Karl Fox Message-Id: <9208211832.AA05756@remora.morningstar.com> To: chris@gandalf.ca (Chris Sullivan) Cc: ietf-ppp@ucdavis.ucdavis.edu, bill.simpson@um.cc.umich.edu (William Allen Simpson) Subject: 1331 State Machine References: <651.bill.simpson@um.cc.umich.edu> <9208211635.AA14651@cannibal.gandalf.ca> Organization: Morning Star Technologies, Inc. Chris Sullivan writes: > 7. A gets RTA, does tlf, and goes to Closed. > 8. B doesn't. No new events are forthcoming that make sense except > a new Open event at B. Except that your timer is running. When B received the Terminate-Request and went from Opened state to Stopping state, it should have started its timer. Whenever you transition into state 4, 5, 6, 7, or 8 from state 0, 1, 2, 3, or 9, you should start the timer. Likewise, whenever you go the other way, you should stop the timer. I'm not saying anything about whether or not there's a problem with the state machine, just that others may not have seen the problem because it is transient. B should get TO+ several times, sending Terminate-Requests and perhaps hearing nothing, and then will eventually get TO-, do a tlf, and go to Closed state. From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 21 14:12:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05565; Fri, 21 Aug 92 14:08:48 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11687; Fri, 21 Aug 92 13:29:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03978; Fri, 21 Aug 92 13:20:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03623; Fri, 21 Aug 92 13:10:14 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA14682; Fri, 21 Aug 92 16:08:08 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA15213; Fri, 21 Aug 92 16:08:05 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9208212008.AA15213@cannibal.gandalf.ca> Subject: Re: 1331 State Machine To: karl@MorningStar.Com (Karl Fox) Date: Fri, 21 Aug 92 16:08:03 EDT Cc: chris@gandalf.ca, ietf-ppp@ucdavis.ucdavis.edu, bill.simpson@um.cc.umich.edu In-Reply-To: <9208211832.AA05756@remora.morningstar.com>; from "Karl Fox" at Aug 21, 92 2:32 pm X-Mailer: ELM [version 2.3 PL11] > > 8. B doesn't. No new events are forthcoming that make sense except > > a new Open event at B. > > Except that your timer is running. When B received the > Terminate-Request and went from Opened state to Stopping state, it > should have started its timer. Whenever you transition into state 4, 5, > 6, 7, or 8 from state 0, 1, 2, 3, or 9, you should start the timer. Well I did miss something fairly huge there, didn't I? The zrc action starts the timer. So when I send the Terminate-Ack and go to state 5 I should be starting my timer. I retract all statements about problems, fixes, etc. In fact, I go away suitably humbled. Much ado about less than zero. Sorry to disturb... Thanks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 21 15:46:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08483; Fri, 21 Aug 92 15:32:23 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12376; Fri, 21 Aug 92 14:29:31 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06066; Fri, 21 Aug 92 14:21:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05725; Fri, 21 Aug 92 14:12:28 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA19484; Fri, 21 Aug 92 14:10:17 -0700 Date: Fri, 21 Aug 92 16:51:57 EDT From: "William Allen Simpson" Message-Id: <659.bill.simpson@um.cc.umich.edu> To: chris@gandalf.ca (Chris Sullivan) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: 1331 State Machine > Well I did miss something fairly huge there, didn't I? The zrc action > starts the timer. So when I send the Terminate-Ack and go to state 5 > I should be starting my timer. > Actually, the zrc was the last fix we made to the spec. So, you're working through the logic that we went through only 9 months ago, after 4 years or more of dithering. > I retract all statements about problems, fixes, etc. In fact, I go away > suitably humbled. Much ado about less than zero. Sorry to disturb... > You, humble? I never thought I'd live to see the day.... Anyway, this is the *implementor's* list (as I remember to have let you know rather pointedly a few months ago). We WANT people to raise questions. Surely, there's something that can be made better (I'm only _nearly_ perfect, myself :-). Welcome to the hallowed ranks of PPP implementors! Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Sat Aug 22 04:51:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27470; Sat, 22 Aug 92 04:46:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16014; Sat, 22 Aug 92 04:29:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26983; Sat, 22 Aug 92 04:21:15 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from hobbit.gandalf.ca by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26907; Sat, 22 Aug 92 04:18:42 -0700 Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA04852; Fri, 21 Aug 92 23:03:21 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA16147; Fri, 21 Aug 92 23:03:15 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9208220303.AA16147@cannibal.gandalf.ca> Subject: Re: 1331 State Machine To: bill.simpson@um.cc.umich.edu (William Allen Simpson) Date: Fri, 21 Aug 92 23:03:15 EDT Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: <659.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Aug 21, 92 4:51 pm X-Mailer: ELM [version 2.3 PL11] > Actually, the zrc was the last fix we made to the spec. So, you're > working through the logic that we went through only 9 months ago, after > 4 years or more of dithering. Too bad I couldn't keep all that archive stuff in my head. > > I retract all statements about problems, fixes, etc. In fact, I go away > > suitably humbled. Much ado about less than zero. Sorry to disturb... > > > You, humble? I never thought I'd live to see the day.... I've had quite a few of these days lately. > Anyway, this is the *implementor's* list (as I remember to have let you > know rather pointedly a few months ago). We WANT people to raise > questions. Surely, there's something that can be made better (I'm only > _nearly_ perfect, myself :-). PPP? Nah. (Except maybe a little compression and LAPB... :^) We might play around with suggestions 1) and 3) and see what happens. Maybe try them against some other vendors' code too... > Welcome to the hallowed ranks of PPP implementors! I musta took a wrong turn at Albuquerque. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Chris Sullivan "Musical innovation is full of Gandalf Data Limited danger to the State, for when chris@gandalf.ca the modes of music change, the laws of the State always change with them." Plato _Republic_ "Hey hey, my my." Neil Young _Out_of_the_Blue_ (And_Into_the_Black)_ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From ietf-ppp-request@ucdavis.ucdavis.edu Sun Aug 23 23:11:29 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20884; Sun, 23 Aug 92 23:06:57 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21672; Sun, 23 Aug 92 22:49:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20389; Sun, 23 Aug 92 22:40:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA20234; Sun, 23 Aug 92 22:32:10 -0700 Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA21784; Sun, 23 Aug 92 22:30:09 -0700 Date: Mon, 24 Aug 92 00:05:31 EDT From: "William Allen Simpson" Message-Id: <665.bill.simpson@um.cc.umich.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: login versus PPP I'm having a problem with all of the servers that have a login prompt, then start PPP. Since PPP has built-in authentication, all I think we need is to detect the PPP frame at the login prompt: 0x7eff7d23. Has anybody taken this approach? Is there any reason why it won't work? Bill.Simpson@um.cc.umich.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon Aug 24 09:48:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04441; Mon, 24 Aug 92 09:30:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24340; Mon, 24 Aug 92 09:10:12 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03608; Mon, 24 Aug 92 09:02:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03413; Mon, 24 Aug 92 08:56:51 -0700 Received: by volitans.morningstar.com (5.65a/92042102) id AA18313; Mon, 24 Aug 92 11:54:21 -0400 Date: Mon, 24 Aug 92 11:54:21 -0400 From: Bob Sutterfield Message-Id: <9208241554.AA18313@volitans.morningstar.com> To: bill.simpson@um.cc.umich.edu ("William Allen Simpson") In-Reply-To: bill.simpson@um.cc.umich.edu's message of Mon, 24 Aug 92 00:05:31 EDT Subject: login versus PPP Cc: ietf-ppp@ucdavis.ucdavis.edu Date: Mon, 24 Aug 92 00:05:31 EDT From: bill.simpson@um.cc.umich.edu ("William Allen Simpson") I'm having a problem with all of the servers that have a login prompt, then start PPP. Since PPP has built-in authentication, all I think we need is to detect the PPP frame at the login prompt: 0x7eff7d23. Has anybody taken this approach? Is there any reason why it won't work? It's inconvenient on some systems, since it requires a modification of the software that prints the "login:" prompt. And that software may have side-effects besides just printing that prompt. And the vendor's sources are likely unavailable for local modification, so that a custom-built "login:" lookalike would lack those (probably lightly-documented) side-effects. On some of our UNIX systems, we have a PPP process running on the modem port in place of the usual getty(8), which is the process that prints the "login:" prompt. When CD goes high, the incoming session is greeted with the 0x7eff7d23..., rather than with the "login:" prompt. Then the peers exchange CHAP. This works fine, but it renders the port useless for non-PPP traffic like UUCP or interactive users, which is why it would be nice to detect the 0x7eff7d23... within getty. Your idea is good, and some implementations {c,sh}ould support it where it makes sense, but call it a MAY rather than a MUST. getty(8) isn't part of our PPP distribution, and it would be very hard to include it. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Aug 26 10:32:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28878; Wed, 26 Aug 92 10:27:45 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14814; Wed, 26 Aug 92 08:40:54 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25046; Wed, 26 Aug 92 08:30:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24805; Wed, 26 Aug 92 08:25:37 -0700 Received: from caicos.Cayman.COM by cayman.Cayman.COM (4.1/SMI-4.0) id AA01206; Wed, 26 Aug 92 11:23:52 EDT Received: by caicos.Cayman.COM (4.1/SMI-4.1) id AA00331; Wed, 26 Aug 92 11:23:38 EDT Date: Wed, 26 Aug 92 11:23:38 EDT From: brad@Cayman.COM (Brad Parker) Message-Id: <9208261523.AA00331@caicos.Cayman.COM> To: internet-drafts@NRI.Reston.VA.US Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: New ATCP (AppleTalk) PPP draft available X-Zippy: Is it NOUVELLE CUISINE when 3 olives are struggling with a scallop in a plate of SAUCE MORNAY? The latest (and hopefully final) draft of the AppleTalk-over-PPP ATCP document is available for ftp from ftp.cayman.com in pub/ppp/ppp-atcp-aug-26-92 Please place this draft in the internet-draft directories. This draft removed the "connect-time" option (option 5 is now "RESERVED") and cleaned up the formatting a bit. Negotiating the "connect-time" option is now the responsibility of LCP. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 28 08:41:20 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19740; Fri, 28 Aug 92 08:32:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02921; Fri, 28 Aug 92 08:09:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18811; Fri, 28 Aug 92 08:00:37 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nsco.network.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18516; Fri, 28 Aug 92 07:50:47 -0700 Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA12081; Fri, 28 Aug 92 09:51:14 -0500 Received: from eros.network.com by anubis.network.com (4.0/SMI-4.0) id AA09386; Fri, 28 Aug 92 09:48:49 CDT Date: Fri, 28 Aug 92 09:48:49 CDT From: sjs@anubis.network.com (Steve Senum) Message-Id: <9208281448.AA09386@anubis.network.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP DECnet There is a new draft of the PPP DECnet Control Protocol (DNCP) in the internet-drafts directory. This draft contains only editorial changes from the previous draft. My thanks to Bill Simpson for his thorough review of this draft. Steve Senum From ietf-ppp-request@ucdavis.ucdavis.edu Fri Aug 28 17:50:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06598; Fri, 28 Aug 92 17:45:06 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08574; Fri, 28 Aug 92 17:29:25 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05947; Fri, 28 Aug 92 17:20:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05874; Fri, 28 Aug 92 17:17:55 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-920708) id AA00489 to ietf-ppp@ucdavis.edu; Fri, 28 Aug 92 17:15:47 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-Brent-920717) id AA26005 to ietf-ppp@ucdavis.edu; Fri, 28 Aug 92 17:15:44 PDT Date: Fri, 28 Aug 92 17:15:44 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9208290015.AA26005@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA06615; Fri, 28 Aug 92 17:17:17 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: Open Invitation--PPP Consortium Customers want reliable networking software that interoperates with as wide a group of equipment as possible. They are looking for PPP to provide link and network control protocols for serial communications. Vendors want to provide such equipment. To that end, Telebit would like to invite all PPP vendors to participate in a working session. This will be a strictly technical effort to test the interoperability of PPP implementations. The first such meeting was held June 1-5. It proved so beneficial to the participants that we are holding a second. Also, a number of positive articles were published (NetworkWorld and Communications Week) about how the members were working towards greater interoperability. This is good for the participants and the PPP industry in general. GOALS: Test interoperability in a spirit of cooperation to identify problems and limitations. Resolve interoperability problems during the session and later. Identify areas for improvement in the specification and implementation of PPP. INVITEES: Everyone is invited. We have included specific people on the address list because they are actively involved with some facet of PPP. ALL others with PPP implementations, or just an interest to see how things work, are invited to come. This is not intended to exclude anyone who would like to participate or observe. Editors from industry publications are invited to attend a briefing on the nature of the meeting (Wednesday 8/22). SCHEDULE: October 19-23, 1992 We need to schedule a maximum of 5 days. Given the larger number of participants at this meeting, we will need this time. Hopefully, we will have a little fun at the same time. LOCATION: Telebit Corp. 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 Telebit is located in Sunnyvale California. It is about half way between San Francisco and San Jose, in the heart of "Silicon Valley." The San Jose Airport is slight closer and is generally easier to get through. However, San Francisco will be fine if there aren't convenient flights in and out of San Jose. SPECIFIC AREAS OF TESTING: We need to determine an interoperability matrix. Participants will be matched-up based on what PPP protocols they support over which links (i.e. sync, async both dialup and direct). The primary protocols of interest are: Link Control (LCP), Password Authentication (PAP), Challenge Authentication (CHAP), Link Quality Monitoring (LQM), Internet Protocol (IPCP), AppleTalk (ATKCP), Novell IPX (IPXCP), Xerox NS, DECnet Phase IV, OSI Network Layer, and Bridging PDU. For each of the protocols, participant pairs will explore the specifics of each option. The participants will examine the option's configurability, the range of the option, the results of the negotiation, and basic operation of the option. These results of this testing will be tabulated and made available to the participants only. Detailed results will not be made available to the public. This policy is designed to encourage vendor participation by removing the threat of negative publicity. INTEROP PPP-DEMO A number of the participants will also be involved in a demonstration of PPP interoperability at the InterOP show the following week. The results of this interoperability testing will be used to determine what to show at InterOp. If you need more details on the the demo, please contact Brian Lloyd (brian@lloyd.com or voice (916) 676-1147). ATTENDEE REQUIREMENTS: Router/host to run PPP implementation Serial hardware adapters (async and sync) Sync cables with proper interface CSU/DSU or "modem eliminators" for sync (faster than 56Kbps) Trace/debugging hardware (e.g. line monitors) Toolkit to put-up and break-down setups Reference Manuals TELEBIT SUPPLIES: Large room for setup Power connections - 24 110v. outlets Phone switch - 64 ports Phone cables CSU/DSUs (to 56Kbps) - 12 pair Thinnet hardware - cables, Ts, terminators Unix (Sparc SunOS 4.1.1) providing bootp & tftp service NETWORK ACCESS: Telebit will provide connectivity to the Internet thru it's 56K link. Participants will be able to read/send mail, ftp code, and whatever. ACCOMMODATIONS: The most convient accommodations are the Wyndham Garden Hotel (next door). The special rates are: Sunday-Thursday $89, Friday-Saturday $54. To make reservations call 408/747-0999. Mention that you are attending the "PPP Consortium" to get these rates and a room out of the reserved block. Breakfast and lunch provided every day by Telebit. Telebit will also plan an evening or so of entertainment. RSVP: I need to know as soon as possible if your company would like to participate. The block of rooms will be reserved until October 5, 1992. Please cut and fill out the following section and return it to me. Hope you can make it. ... Mark =====----- Mark S. Lewis, Telebit Corporation -----====== inet: mlewis@telebit.com Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 ------------------------ Cut Here ---------------------------- Yes, we would like to participate in the 2nd meeting PPP Interoperability Consortium. Company: Address: Address: Address: Address: Please list thost that will attend: COMPANY REPRESENTATIVES Name E-mail Voice Fax ---- ------ ----- --- Please check the protocols supported over which media: PROTOCOL MEDIA MATRIX Protocol Sync Link Asyc Link -------- --------- --------- Link Control (LCP) Password Authentication (PAP) Challenge Authentication (CHAP) Link Quality Monitoring (LQM) Internet Protocol (IPCP) AppleTalk (ATKCP) Novell IPX (IPXCP) Xerox NS DECnet Phase IV OSI Network Layer Bridging PDU Other (specify) Commments: ------------------------ Cut Here ----------------------------