From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 4 22:00:51 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19971; Mon, 4 May 92 21:56:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA10622; Mon, 4 May 92 21:39:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19075; Mon, 4 May 92 21:30:50 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18753; Mon, 4 May 92 21:23:19 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA05814; Mon, 4 May 92 21:22:36 PDT Date: Mon, 4 May 92 21:22:36 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9205050422.AA05814@ray.lloyd.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: IETF Boston Topics for Boston? Do we need to meet in Boston? Ideas? Discussion? Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 5 10:28:44 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10378; Tue, 5 May 92 10:10:16 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13998; Tue, 5 May 92 09:49:56 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09429; Tue, 5 May 92 09:42:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA09123; Tue, 5 May 92 09:32:01 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA17662; Tue, 5 May 92 09:30:15 PDT Date: Tue, 5 May 92 09:30:15 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205051630.AA17662@saffron.acc.com> To: brian@lloyd.com Subject: Re: IETF Boston Cc: ietf-ppp@ucdavis.ucdavis.edu If we haven't got it straightened out yet, we should probably discuss LCP LAPB negotiation and LCP Compression Negotiation. (Bill: still waiting for the LAPB pages...) By the way, something that could facilitate getting the LCP advanced and still be able to add such as above: Have you noticed that there is not a single telnet document that tries to describe "all" of the messages telnet peers can exchange, but rather there is a long list of "The Telnet Option" documents? If we allow IANA to do their job with the protocol negotiation identifiers, we can allow later documents to say "to use this, you need LCP option " and describe it. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 5 10:52:53 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11577; Tue, 5 May 92 10:46:13 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14380; Tue, 5 May 92 10:21:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10633; Tue, 5 May 92 10:17:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10335; Tue, 5 May 92 10:09:26 -0700 Received: by mts-gw.pa.dec.com; id AA23971; Tue, 5 May 92 10:07:14 -0700 Message-Id: <9205051707.AA23971@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Tue, 5 May 92 10:08:07 PDT Date: Tue, 5 May 92 10:08:07 PDT From: Jesse Walker To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu Subject: Re: IETF Boston Brian: What is the status of the MIB? A few of us commented on it, but no resolution has circulated regarding our comments. Will the MIB issues be resolved before the Boston meeting? -- Jesse Walker From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 5 14:06:00 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17880; Tue, 5 May 92 13:53:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17152; Tue, 5 May 92 13:30:30 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16870; Tue, 5 May 92 13:22:07 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from nero.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16473; Tue, 5 May 92 13:11:14 -0700 Received: by nero.clearpoint.com (4.1/1.34) id AA24050; Tue, 5 May 92 16:10:30 EDT Date: Tue, 5 May 92 16:10:30 EDT From: saul@nero.clearpoint.com (Saul Agranoff) Message-Id: <9205052010.AA24050@nero.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP LQR Question Could someone please explain the following paragraph from the 'Configuration Option Format' section (2.5) of latest PPP Link Quality Monitoring spec (draft-ietf-pppext-lqm-01.txt): > A value of zero indicates that the peer does not need to maintain > a timer. Instead, the peer generates a LQR immediately upon > receiving a LQR. A value of zero MUST be Nak'd by the peer with > an appropriate non-zero value when that peer has sent or will send > a Configure-Request packet containing the Quality-Protocol > Configuration Option for the Link-Quality-Report with a zero > Reporting-Period. The way I read this, one side (at least) MUST maintain a timer for sending LQRs. Is this correct? Wouldn't it be reasonable for BOTH sides to passively await LQRs (which might be generated by user-request only when transmission dificulties are suspected)? From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 5 18:41:46 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27879; Tue, 5 May 92 18:39:37 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA19912; Tue, 5 May 92 18:20:00 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA27206; Tue, 5 May 92 18:18:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26497; Tue, 5 May 92 17:57:58 -0700 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA11386; Tue, 5 May 92 20:56:59 -0400 Received: by crappie.morningstar.com (5.65a/910712902) id AA01949; Tue, 5 May 92 20:56:57 -0400 Date: Tue, 5 May 92 20:56:57 -0400 From: Karl Fox Message-Id: <9205060056.AA01949@crappie.morningstar.com> To: saul@nero.clearpoint.com (Saul Agranoff) Cc: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP LQR Question References: <9205052010.AA24050@nero.clearpoint.com> Organization: Morning Star Technologies, Inc. Saul Agranoff writes: > Could someone please explain the following paragraph from > the 'Configuration Option Format' section (2.5) of latest > PPP Link Quality Monitoring spec (draft-ietf-pppext-lqm-01.txt): > > > A value of zero indicates that the peer does not need to maintain > > a timer. Instead, the peer generates a LQR immediately upon > > receiving a LQR. A value of zero MUST be Nak'd by the peer with > > an appropriate non-zero value when that peer has sent or will send > > a Configure-Request packet containing the Quality-Protocol > > Configuration Option for the Link-Quality-Report with a zero > > Reporting-Period. > > The way I read this, one side (at least) MUST maintain a timer > for sending LQRs. Is this correct? Yes. > Wouldn't it be reasonable for BOTH sides to passively await LQRs > (which might be generated by user-request only when transmission > dificulties are suspected)? Yow, no! If you did this, then a single injected LQR would bounce back and forth between the peers forever as fast as they could send it. From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 6 09:14:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA22976; Wed, 6 May 92 09:04:14 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA24953; Wed, 6 May 92 08:39:39 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21887; Wed, 6 May 92 08:30:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21488; Wed, 6 May 92 08:20:09 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07368; Wed, 6 May 92 08:19:10 PDT Date: Wed, 6 May 92 08:19:10 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9205061519.AA07368@ray.lloyd.com> To: kasten@europa.clearpoint.com Cc: walker@eider.enet.dec.com, rlstewart@eng.xyplex.com, ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Frank Kastenholz's message of Wed, 6 May 92 09:01:18 EDT <9205061301.AA00912@europa.clearpoint.com> Subject: mib plan of action Date: Wed, 6 May 92 09:01:18 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) jesse and brian here's the situation. for various reasons, between now and the ietf meeting i will not have the time to continue our discussion on the ppp mib architecture. (basically, i have to do the work that my employer pays me for -- write code :-). i believe that the mib structure as i have proposed, and the mib structure that jesse has been arguing for are both pretty much suitable for the mib. i think that either one would do and that each has its plusses and minuses. in other words, this is an issue that reasonable people may agree to disagree. so, since i do not have the time to continue the discussion, and, since i would like to close this long chapter of my life (it has been going on longer than the ethernet mib!), i will recast the mib to jesse's form, and then let's put it forward at boston for standardization, etc, etc, etc. if this is acceptable to you guys, then we should put it forth on the working group and get their hum of consent. i would like to get this done in the next week or two. certainly before interop. however, if the w.g. does not want to do this, we will have to carry on the discussion later in the spring or summer and the earliest that the w.g. can consider the entire mib would be the november ietf. i believe that november is too far away. i've copied bob stewart on this since he is the only one who has had anything to say on our discussions. frank > From ietf-ppp-request@ucdavis.edu Tue May 5 13:36:20 1992 > Sender: ietf-ppp-request@ucdavis.edu > From: Jesse Walker > To: brian@lloyd.com > Cc: ietf-ppp@ucdavis.edu > Subject: Re: IETF Boston > > Brian: > > What is the status of the MIB? A few of us commented on it, but no > resolution has circulated regarding our comments. Will the MIB issues > be resolved before the Boston meeting? > > -- Jesse Walker Whoa Frank. I agree that Jesse has some interesting points but he has yet to convince me that it is all that critical. We have lots of people here who will be affected so I would like to hear from them. If there is no strong feeling one way or the other then I would prefer to leave the MIB as it is. If it is the same to everyone else then I would choose the path of least resistance. On the other hand, if Jesse wants to hack a new version of the document that casts the MIB in the form he likes that is fine also. We can then decide which doc we like better. Frank, if you agree with Jesse's comments and WISH to change the document, fine. It is your document. Change it and be done. Now I want the MIB document put to bed you two. Simplify it and post it. I want to see an end to this epic saga. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 7 05:31:37 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02259; Thu, 7 May 92 05:25:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA05568; Thu, 7 May 92 05:09:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01704; Thu, 7 May 92 05:00:11 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from mts-gw.pa.dec.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01611; Thu, 7 May 92 04:58:12 -0700 Received: by mts-gw.pa.dec.com; id AA26380; Thu, 7 May 92 04:57:24 -0700 Message-Id: <9205071157.AA26380@mts-gw.pa.dec.com> Received: from eider.enet; by decpa.enet; Thu, 7 May 92 04:57:27 PDT Date: Thu, 7 May 92 04:57:27 PDT From: Jesse Walker To: brian@lloyd.com Cc: ietf-ppp@ucdavis.ucdavis.edu Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu Subject: >> Brian: On the other hand, if Jesse wants to hack a new version of the document that casts the MIB in the form he likes that is fine also. We can then decide which doc we like better. >> Fair enough. I'll do this the first week in June. My plan is to begin with >> Frank's latest MIB and simply restructure it. I am not unhappy with the >> variables in the MIB, only its scalability and extensibility. I still think >> Frank deserves our thanks for bringing the MIB as far as he has. >> >> -- Jesse Walker From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 7 09:41:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10050; Thu, 7 May 92 09:32:40 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA07956; Thu, 7 May 92 09:00:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08702; Thu, 7 May 92 08:51:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ray.lloyd.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08262; Thu, 7 May 92 08:40:13 -0700 Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA08162; Thu, 7 May 92 08:36:54 PDT Date: Thu, 7 May 92 08:36:54 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9205071536.AA08162@ray.lloyd.com> To: walker@eider.ENET.dec.com Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Jesse Walker's message of Thu, 7 May 92 04:57:27 PDT <9205071157.AA26380@mts-gw.pa.dec.com> Date: Thu, 7 May 92 04:57:27 PDT From: Jesse Walker Apparently-To: brian@lloyd.com, ietf-ppp@ucdavis.edu >> Brian: On the other hand, if Jesse wants to hack a new version of the document that casts the MIB in the form he likes that is fine also. We can then decide which doc we like better. >> Fair enough. I'll do this the first week in June. My plan is to begin with >> Frank's latest MIB and simply restructure it. I am not unhappy with the >> variables in the MIB, only its scalability and extensibility. I still think >> Frank deserves our thanks for bringing the MIB as far as he has. >> >> -- Jesse Walker I heartily agree. Since you and Frank seem to be the most active in this area I would like to see you resolve the structure issue and let us know where you have gone. I would like to put the MIB to bed now that LQM has been moved forward and the SAAG folks have signed off on the Authentication document. The MIB seems to be the last item so let's get it cleaned up quickly. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 8 18:50:59 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA10446; Fri, 8 May 92 18:41:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26892; Fri, 8 May 92 18:17:57 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04199; Fri, 8 May 92 15:05:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [36.98.0.21] by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03889; Fri, 8 May 92 14:54:42 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA15437; Fri, 8 May 92 14:52:07 -0700 Date: Fri, 8 May 92 15:44:38 EDT From: "William Allen Simpson" Message-Id: <319.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: link compression Not long ago, I asked for folks who knew of compression over sync to send me a list of vendors, so we could determine if this is an immediate compatability need, or just a marketing daydream. I had three responses: Russell Gocht says Microcom has a compressing bridge/router for leased lines, V.25bis, and X.25; with line speeds to T1 (256K for X.25). Fred Baker says that ACC is in the process of implementing a software version of V.42bis compression over LAPB. Jim Forster says cisco "doesn't do compression on sync lines now, but we should. If the work of this group is interesting, we might follow its lead, otherwise we'll do something else." There was also the expressed interest (on the list) of Morning Star and Cayman, touting an alternative scheme. I liked Fred's overall comments: The reason it's not a hardware issue is that the price of a synchronous compressor is on the order of $5K, as much or more than the router itself, and the DSU (synchronous equivalent to a modem) being yet a third cost. At 56 KBPS, one can reasonably use software compression to achieve a 112-224 KBPS effective bit rate without additional hardware. T1 is another story; now the outboard compressor pays for itself. As to whether it's a marketing issue, well, it may be. But if PPP doesn't provide a standard way to do it, we and everybody else still have to do it. It's not a question of whether, it's a question of when and how. I agree with the sentiment. What we need to decide is this: 1) When? 1a) Is this more important than the MIB, OSI, IPX and AppleTalk? 1b) Should we wait until they are done, or split our efforts? 1c) Will this slow general availability of PPP, or accelerate it? 2) How? 2a) Should we use V.29bis, or something else? 2b) Should we use LAPB, or some other method of link feedback? 2c) Is there a way to make this protocol dependent? Otherwise, we won't be able to fall back to unadulterated LCP, violating the PPP design principles. Bill_Simpson@um.cc.umich.edu bsimpson@vela.acs.oakland.edu From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 11 12:54:16 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12473; Mon, 11 May 92 12:41:04 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA12333; Mon, 11 May 92 12:19:48 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11436; Mon, 11 May 92 12:10:42 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from faui45.informatik.uni-erlangen.de by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11006; Mon, 11 May 92 11:57:31 -0700 Received: by uni-erlangen.de; id AA05514 (5.65c-5/7.3l-FAU); Mon, 11 May 1992 20:56:33 +0200 Received: from USENET by Informatik.Uni-Erlangen.de with Cnews-09/03/90 for The PPP mailing list ; contact News@Informatik.Uni-Erlangen.de if you have questions. To: ietf-ppp@ucdavis.ucdavis.edu Date: Mon, 11 May 1992 18:55:56 GMT From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) Subject: LAPB and OSI Message-Id: <1992May11.185556.6727@informatik.uni-erlangen.de> Organization: CSD., University of Erlangen, Germany Hello! A few weeks ago, I began to develop a MS-DOS driver for X.25 over async LAPB (start/stop mode defined in ISO 3309). This will be public domain software. Could anyone please give me a short summary on what are the plans for PPP concerning: - LAPB - OSI in general - compatibility to the final version of the ISO start/stop mode It might be quite easy to support the LAPB included in future PPP versions in my software. Thank you! Markus --- Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany Internet: mskuhn@immd4.informatik.uni-erlangen.de | X.500 entry available Don't worry over what other people are thinking about you. ---------------- ---------- They're too busy worrying over what you are thinking about them. From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 11 14:02:17 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA15022; Mon, 11 May 92 13:57:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA13525; Mon, 11 May 92 13:41:07 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14259; Mon, 11 May 92 13:31:35 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from regal.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14032; Mon, 11 May 92 13:26:10 -0700 Received: by regal.cisco.com; Mon, 11 May 92 13:24:50 -0700 Date: Mon, 11 May 92 13:24:50 -0700 From: Dave Katz Message-Id: <9205112024.AA25147@regal.cisco.com> To: mskuhn@immd4.informatik.uni-erlangen.de Cc: ietf-ppp@ucdavis.ucdavis.edu In-Reply-To: Markus Kuhn's message of Mon, 11 May 1992 18:55:56 GMT <1992May11.185556.6727@informatik.uni-erlangen.de> Subject: LAPB and OSI There is active work taking place to finalize OSI connectionless network layer protocols over PPP; that work specifically excludes ISO 8208/X.25 because of the current lack of a reliable data link. Depending on how/whether work on LAPB progresses, it may be relatively easy in the future to lift the restriction on 8208. Someone else can comment on the status of LAPB/PPP. Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 11 May 1992 18:55:56 GMT From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn) Organization: CSD., University of Erlangen, Germany Hello! A few weeks ago, I began to develop a MS-DOS driver for X.25 over async LAPB (start/stop mode defined in ISO 3309). This will be public domain software. Could anyone please give me a short summary on what are the plans for PPP concerning: - LAPB - OSI in general - compatibility to the final version of the ISO start/stop mode It might be quite easy to support the LAPB included in future PPP versions in my software. Thank you! Markus --- Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany Internet: mskuhn@immd4.informatik.uni-erlangen.de | X.500 entry available Don't worry over what other people are thinking about you. ---------------- ---------- They're too busy worrying over what you are thinking about them. From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 11 16:12:02 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19117; Mon, 11 May 92 16:05:08 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA14789; Mon, 11 May 92 15:41:24 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18188; Mon, 11 May 92 15:35:56 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA17878; Mon, 11 May 92 15:27:42 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA03514; Mon, 11 May 92 15:26:22 PDT Date: Mon, 11 May 92 15:26:22 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205112226.AA03514@saffron.acc.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: LAPB compatibility Folke: Bill sent be the text from the ancient and dusty RFC 1171 predecessor regarding a LAPB option. His comment was that it was less than verbose and lacked any real content - an assessment I would agree with. I propose that this text be substituted for it and included in the LCP. I will follow in a bit with a compression option. I would be curious of your comments. Fred ====================================================================== .ig .Nh 2 Optional CCITT X.25 LAPB Compatibility .LP .RS For those protocols for which a sequenced, flow controlled, error corrected connection is required or desirable, PPP frames may optionally contain Information (I) and other LAPB compatible commands. LAPB is defined by the following documents: .NP ISO 3309: High Level Data Link Control Procedures - Frame Structure .NP ISO 4335: High Level Data Link Control Procedures - Consolidation of Elements of Procedures .NP ISO 7478: High Level Data Link Control Procedures - Multilink Procedure .NP ISO 7776: High Level Data Link Control Procedures - Description of X.25 LAPB-compatible DTE Data Link Procedures .NP ISO 7809: High Level Data Link Control Procedures - Consolidation of Classes of Procedures .LP We define the following PPP option: .DS +--------+--------+--------+--------+ | LAPB | LENGTH | WINDOW | ADDRESS| | OPTION | | | | +--------+--------+--------+--------+ .DE .LP By default, PPP is used over an ISO 3309 header with Address=Broadcast (FF) and Control = UI (03). In the event that a system requires reliable data exchange, it may include the LAPB OPTION in its Configure Request. In that, it should note the ADDRESS that it will use and the WINDOW that it will offer. .LP A system which does not desire to implement LAPB should REJECT the option. .LP A system which is unhappy with its neighbor's LAPB configuration should NAK the option, filling in the new values that the neighbor should use. .LP A system which chooses to accept a LAPB OPTION should emit the SABM appropriate to the configuration, and receive the UA response, prior to sending the CONFIGURE ACK. .LP Valid Address values are single or multiple octet values following the ISO 3309 addressing convention. When the values 0x01, 0x03, 0x07, or 0x0F are used, they are used in accordance with their ISO 7776, section 5.1, definitions. .LP Valid window values, as defined in ISO 7776 section 5.7.4, are in the range 1..127. Windows in excess of 7 imply the use of Extended Sequence Numbers; windows in the range 1..7 imply the use of Basic (Modulo 8) sequence numbers. NAKs may reduce the window size by may not increase it. .LP In the Multilink Procedure, the Multilink Control Field resides between the Address and Control fields and the PPP header. .LP The values of the timers T1, T2, T3, and T4, and the constant N2, and also their Multilink counterparts, are not exchanged, and are a matter of local configuration. N1 may be derived from the PPP MRU. From ietf-ppp-request@ucdavis.ucdavis.edu Mon May 11 19:52:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26188; Mon, 11 May 92 19:47:25 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16572; Mon, 11 May 92 19:29:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25326; Mon, 11 May 92 19:20:23 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25111; Mon, 11 May 92 19:14:30 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA24537 to ietf-ppp@ucdavis.edu; Mon, 11 May 92 19:03:36 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA29380 to brian@lloyd.com; Mon, 11 May 92 19:00:15 PDT Date: Mon, 11 May 92 19:00:15 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9205120200.AA29380@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA08254; Mon, 11 May 92 19:04:12 PDT To: ietf-ppp@ucdavis.ucdavis.edu Cc: brian@lloyd.com, gordon@ftp.com, tayler@heart.enet.dec.com, grant@xylogics.com, brad@cayman.com, misko@cisco.com, walkerl@med.ge.com, centrum@netcom.com Subject: PPP-Athon is June 1-5 Here is a status report on the upcoming PPP-Athon. We now have about 10 companied that have committed to attending. A number of other companies have said they are considering it. Several purchasers of PPP products have asked to come and observe. Plans have been progressing well and we are on target for June 1-5. I have included information on hotel accommodations and such. We have reserved a block of rooms in the hotel next door. I need to know if you can attend by May 22, as the hotel reservations evaporate then. Everyone who has not reponded should give this serious consideration and let me know. Hope you can make it. ... Mark "PPP-Athon" Invitation 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 strictly a technical effort to make sure participating PPP implementations interoperate well. GOALS: 1) Test interoperability in a spirit of cooperation to identify problems and limitations. 2) Resolve interoperability problems during the session or later. 3) Identify areas for improvement in our implementation. 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. SCHEDULE: Schedule a maximum of 5 days for fun and progress. June 1 - 5, 1992 LOCATION: 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: 1) Test interoperability of IP, AppleTalk, IPX and bridging over sync PPP connections 2) Test interoperability of IP, AppleTalk, IPX and bridging over direct async PPP connections 3) Test interoperability of IP, AppleTalk, IPX and bridging over dial-up async PPP connections ATTENDEE REQUIREMENTS: Router/host to run PPP implementation Serial hardware adapters (async and sync) CSU/DSU for sync (faster than 56Kbps) Trace/debugging hardware (eg. 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 Sync cables - 12 V.35 cables Thinnet hardware - 12 cables, Ts, terminators Unix (Sparc) providing bootp & tftp service ACCOMMODATIONS: The Wyndham Garden Hotel (Next Door) To make reservations call 408/747-0999 Rates Mon-Fri $86, Sat-Sun $49 Mention that you are attending the "PPP-Athon" to get these rates and get a room out of the reserved block. Lunch provided every day by Telebit Telebit will plan an evening or two's fun RSVP: I need to know if you can make it by May 22, as I can't reserve rooms past this date. 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 From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 12 10:03:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21142; Tue, 12 May 92 09:51:43 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21071; Tue, 12 May 92 08:59:44 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19212; Tue, 12 May 92 08:51:38 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA18881; Tue, 12 May 92 08:38:29 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA06458; Tue, 12 May 92 08:37:07 PDT Date: Tue, 12 May 92 08:37:07 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205121537.AA06458@saffron.acc.com> To: mm@gandalf.ca Subject: Re: LAPB compatibility Cc: ietf-ppp@ucdavis.ucdavis.edu >> > +--------+--------+--------+--------+ >> > | LAPB | LENGTH | WINDOW | ADDRESS| >> > | OPTION | | | | >> > +--------+--------+--------+--------+ >> > .DE >> > .LP >> > By default, PPP is used over an ISO 3309 header with >> > Address=Broadcast (FF) and Control = UI (03). >> > In the event that a system requires reliable data exchange, >> > it may include the LAPB OPTION in its Configure Request. >> > In that, it should note the ADDRESS that it will use >> > and the WINDOW that it will offer. >> This is good! Does the job nicely. >> Is the multilink procedure non-optional? Some might balk at it being >> required. I was trying to not preclude it, not require it. It seems to me that, if A suggests Multilink to B and B doesn't want to do so, B might NAK with a point to point address. >> I would be interested in any preliminary details you can give me on >> your impending compression text. In particular are you intending to >> take Dave Carr's suggestion of using selective retries? Well, since *chips* don't generally support selective retries and ISO 7776 doesn't use that HDLC option, I wasn't going to propose it. I was hoping to just point to an existing standard rather than get into all the possible subsets. A thought rumbled up as I was biking in this morning, though; in certain contexts, like "I am attached to an ISDN link or to a Frame Relay Network", one might determine from that context that the LAPB in question is in fact Q.921 or Q.922, without explicitly saying so in the Configure Request. Thoughts? I'm still mulling that one over... >> I also suppose in going LAPB whole hog we must lose the nice alignment >> which the UI only framing had. Anything we can do about that? No, not unless we use extended sequencing, and even there the chips generally don't store the LAPB header. The modulo 8 Control field is a single octet just as the UI is. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 12 10:21:50 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21722; Tue, 12 May 92 10:11:21 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA21413; Tue, 12 May 92 09:22:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19950; Tue, 12 May 92 09:14:09 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA19565; Tue, 12 May 92 09:01:29 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA06484; Tue, 12 May 92 09:00:03 PDT Date: Tue, 12 May 92 09:00:03 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205121600.AA06484@saffron.acc.com> To: brian@lloyd.com Subject: Re: direction Cc: ietf-ppp@ucdavis.ucdavis.edu >> I do not think that changing the current LCP document would be a good >> idea. I would like to see a new document that describes the LCP >> options for negotiating LAPB. That way the existing LCP document can >> proceed along the standard track and there will be no question about >> setting it back due to changes. That's fine if that's the way you want it, Brian. You said the other day that this work SHOULD go forward (you conceded the debate), and that it belonged in the LCP document. You detailed Jim Forster and myself to do it. I was acting on your sage advice. It goes like this: if you want other documents to be able to define and add LCP options, I would appreciate a statement in the LCP document saying "new LCP option numbers may be assigned by IANA". >> 1. Who is going to write the LAPB document? You tell me. What is needed beyond the text I suggested last night and a few cover paragraphs? If I can cut and paste some boilerplate out of the existing LCP or LQM document, I might be willing to do it. >> I also think that compression should be a separate document. Either they should both be separate documents or they should all be in the LCP document. >> 2. Who is going to write the compression document? I thought I heard Venkat offer; I could write that as well, though. >> I really want to move forward on the other documents (LCP, IPCP, >> authentication, LQM, and MIB mostly right now) and I do not want their >> progress slowed down by activity on error correction or compression. Yes, yes, you've said that several times. The LCP document needs to be updated to support the new LQM procedure, if the March 23 document is the most up to date (my collegue at Gandalf pointed that out to me). I await your wisdom. Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 12 13:09:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26364; Tue, 12 May 92 12:50:29 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA23080; Tue, 12 May 92 11:30:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23794; Tue, 12 May 92 11:20:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23477; Tue, 12 May 92 11:11:17 -0700 Received: from remora.morningstar.com by volitans.morningstar.com (5.65a/92042102) id AA17776; Tue, 12 May 92 14:10:05 -0400 Received: by remora.morningstar.com (5.65a/91072901) id AA08672; Tue, 12 May 92 14:10:04 -0400 Date: Tue, 12 May 92 14:10:04 -0400 From: Karl Fox Message-Id: <9205121810.AA08672@remora.morningstar.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: LAPB compatibility References: <9205121537.AA06458@saffron.acc.com> Organization: Morning Star Technologies, Inc. Am I correct to assume that, when using LAP-B, one end will use address 01 and the other 03? If so, what is the best way to negotiate this? Bill? Will LCP still always be sent in UI frames? Why or why not? Also, it would sure be nice to limit the scope of the LAP-B options if possible. Is MLP useful? Do we really need to support both SABM and SABME? Maybe we could even fix the window size, although that might be difficult. From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 12 16:52:34 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04263; Tue, 12 May 92 16:40:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA26443; Tue, 12 May 92 16:19:42 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03314; Tue, 12 May 92 16:12:36 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03132; Tue, 12 May 92 16:06:19 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA07784; Tue, 12 May 92 16:04:52 PDT Date: Tue, 12 May 92 16:04:52 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205122304.AA07784@saffron.acc.com> To: dcarr@donut.gandalf.ca Subject: Re: Cc: estgoar@ucdavis.ucdavis.edu, ietf-ppp@ucdavis.ucdavis.edu >> I wasn't suggesting all the subsets, just selective retry. >> Don't get me wrong, we have yet to implement selective retry on our >> compression bridge. But it's on the schedule someplace :-) We DO have it implemented in our software LAPB module, it's just a matter of turning it on. On lines with modern BERs, it's frankly not as obvious a win as it sounds. It helps mostly with long delay links. >> On the compression algorithm front, I contacted the authors of the >> Info-ZIP compression program, and things look good. Still working on >> the "can't sell it for a profit" clause however. At least there >> shouldn't be $60,000 in royalties as with V42.bis, better compression, >> and no patents! I'd be real interested to know about this in more detail Fred From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 12 20:20:23 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA12388; Tue, 12 May 92 20:15:47 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA27848; Tue, 12 May 92 19:59:29 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11900; Tue, 12 May 92 19:50:46 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA11678; Tue, 12 May 92 19:44:18 -0700 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA21106 (5.65c/IDA-1.4.4nsd for ); Tue, 12 May 1992 19:42:54 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA20399 (5.65c/IDA-1.4.4-910725); Tue, 12 May 1992 19:42:51 -0700 Message-Id: <199205130242.AA20399@himagiri.NSD.3Com.COM> To: fbaker@acc.com (Fred Baker) Cc: brian@lloyd.com, ietf-ppp@ucdavis.ucdavis.edu Subject: Re: direction Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) In-Reply-To: Mail from fbaker@acc.com (Fred Baker) dated Tue, 12 May 92 09:00:03 PDT <9205121600.AA06484@saffron.acc.com> Date: Tue, 12 May 92 19:42:48 -0700 From: Venkat Prasad >> 2. Who is going to write the compression document? >>I thought I heard Venkat offer; I could write that as well, though. >> fred >Venkat: could you please contact me to verify that you want to produce >said document. Thanks. > Brian I have the inclination but not the time. I did say earlier that I will be willing to do some work in the area to help in the standards efforts. Since Fred has said he could write it I can perhaps help him in his efforts - if he needs any. thanks /Venkat Prasad From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 13 15:25:06 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25123; Wed, 13 May 92 15:02:32 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06796; Wed, 13 May 92 14:41:18 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24059; Wed, 13 May 92 14:35:13 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23234; Wed, 13 May 92 14:15:38 -0700 Received: from via.ws13.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA20782; Wed, 13 May 92 14:14:24 -0700 Date: Wed, 13 May 92 13:25:28 EDT From: "William Allen Simpson" Message-Id: <331.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: direction > >> 1. Who is going to write the LAPB document? > > You tell me. What is needed beyond the text I suggested last night > and a few cover paragraphs? If I can cut and paste some boilerplate > out of the existing LCP or LQM document, I might be willing to do it. > > You may cut and paste to your heart's content so long as the result is > comprehensive and cohesive. > Fred, you can find the whole LCP nroff at: angband.stanford.edu:pub/ppp/nr/lcp.nr Go ahead and use whatever you need. I'd be delighted to help you with boilerplate, of course, just as long as I don't have to write the whole thing. > if you want other documents to be able to define > and add LCP options, I would appreciate a statement in the LCP > document saying "new LCP option numbers may be assigned by IANA". > > That should not be hard to add since that is already the case. > Uh, guys, the statement has been there for YEARS! The most up-to-date values of the LCP Option Type field are specified in the most recent "Assigned Numbers" RFC [11]. Current values are assigned as follows: Our experience with the IANA is that Jon will assign numbers, whether we like it or not! We are trying to get him to consult the WG before assigning the numbers, so that we can have fewer bogus assignments (a problem last two years). Specifically, I want a draft published *before* the assignment is made. Just used in your first draft. > >> I also think that compression should be a separate document. > > Either they should both be separate documents or they should all be in > the LCP document. > > Let's go with new documents. That seems to be the logical direction > to compartmentalize the work. > Yes, a short focused document would be better. Only when I removed the LQM from the LCP document did we get the excellent review suggestions that made LQM work. > ... The LCP document needs to > be updated to support the new LQM procedure, if the March 23 document > is the most up to date (my collegue at Gandalf pointed that out to > me). > > Bill Simpson: could you verify that the LCP doc is up to date re LQM. > Thanks. > I believe the LCP document to be complete. The final text has been passed to the RFC Editor for publication. What update did he have in mind? Please send your/his/her question directly to me. If it's significant, we can re-publish in 6 months. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 13 15:36:31 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26167; Wed, 13 May 92 15:28:08 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA06851; Wed, 13 May 92 14:47:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24068; Wed, 13 May 92 14:35:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23241; Wed, 13 May 92 14:15:51 -0700 Received: from via.ws13.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA20785; Wed, 13 May 92 14:14:41 -0700 Date: Wed, 13 May 92 13:57:23 EDT From: "William Allen Simpson" Message-Id: <332.bsimpson@angband.stanford.edu> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: LAPB compatibility > From: Karl Fox > > Am I correct to assume that, when using LAP-B, one end will use address > 01 and the other 03? If so, what is the best way to negotiate this? > Bill? > Each end of the link negotiates the LAP-B configuration option separately and simultaneously, so specifying this in the option might lead to negotiation failure. Karl suggested requiring the magic-number option for resolving this -- low number is 01. > Will LCP still always be sent in UI frames? Why or why not? > All LCP, LQM, Authentication, and probably NCP packets *MUST* be sent in PPP UI frames. These frames must be distinguishable even when synchronization is lost, so they MUST be sent "bare". We probably need some method of negotiating which protocols are allowed in the LAPB frames. Perhaps a string of protocol numbers at the end of the LAP-B configuration option? > Also, it would sure be nice to limit the scope of the LAP-B options if > possible. Is MLP useful? Do we really need to support both SABM and > SABME? Maybe we could even fix the window size, although that might be > difficult. > I think this is open to discussion. One of the things that PPP is supposed to address is the need to setup such parameters in advance. There are a lot of setup parameters to be considered. I would like them all to be negotiated. We are getting so many variables that it seems to me that we need a separate NCP for LAP-B, rather than a single LCP option. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 13 18:13:24 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02542; Wed, 13 May 92 17:57:54 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA08768; Wed, 13 May 92 17:42:19 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA01461; Wed, 13 May 92 17:32:16 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00810; Wed, 13 May 92 17:17:29 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA12476; Wed, 13 May 92 17:15:56 PDT Date: Wed, 13 May 92 17:15:56 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205140015.AA12476@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: LAPB compatibility Cc: ietf-ppp@ucdavis.ucdavis.edu > Am I correct to assume that, when using LAP-B, one end will use address > 01 and the other 03? If so, what is the best way to negotiate this? > Bill? > Each end of the link negotiates the LAP-B configuration option separately and simultaneously, so specifying this in the option might lead to negotiation failure. Karl suggested requiring the magic-number option for resolving this -- low number is 01. While I think the algorithm is cute, I worry about this in another context. We have spoken, as a group, about multiple PPP links in parallel, although we haven't resolved whether there are common or separate NCPs, etc. In certain contexts - anything with VJ compression, or bridging - having a serialized multiple link data stream has some real nice attributes. So, while I certainly didn't want anyone to HAVE to implement MLP, I tried rather obviously to not preclude it. Now, I could go for the same algorithm, but a "MLP/Point to Point LAPB" selector, and the low magic number would have the numerically smaller address. Thoughts? All LCP, LQM, Authentication, and probably NCP packets *MUST* be sent in PPP UI frames. These frames must be distinguishable even when synchronization is lost, so they MUST be sent "bare". Absolutely We probably need some method of negotiating which protocols are allowed in the LAPB frames. Perhaps a string of protocol numbers at the end of the LAP-B configuration option? Probably the other way around; one generally routes some well specified set of protocols and bridges the rest. But, now *why* is one configuring LAPB? If it's to get sequential multiple line service for some protocols, and others don't need it (send VJ/TCP serialized, but not generalized IP, for example), then it makes sense to send the other protocols in UI frames. If it's because we are doing something rather basic to the line, like encrypting or compressing all the data frames, then you're really saying "what do we want compressed or encrypted", and I think that the answer is probably pretty general. It seems that that is a decision the devicecan make without negotiation. > Also, it would sure be nice to limit the scope of the LAP-B options if > possible. Is MLP useful? Do we really need to support both SABM and > SABME? Maybe we could even fix the window size, although that might be > difficult. > I think this is open to discussion. One of the things that PPP is supposed to address is the need to setup such parameters in advance. There are a lot of setup parameters to be considered. I would like them all to be negotiated. Yes, that's why we need a 500 object MIB (or was it 400? I forget:^) A little more seriously, we could limit the thing to selecting between modulo 8 and modulo 128; actually negotiating the window might not be necessary. My comment would be that once you've set aside an octet for the boolean, you may as well make it an integer in 1..127. We are getting so many variables that it seems to me that we need a separate NCP for LAP-B, rather than a single LCP option. That doesn't make a lot of sense to me, as it makes us negotiate something about the *link* in an NCP. That doesn't sound like the right functional division. From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 14 07:01:58 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00707; Thu, 14 May 92 06:54:53 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11548; Thu, 14 May 92 06:31:46 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29413; Thu, 14 May 92 06:22:28 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GINGER.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA29246; Thu, 14 May 92 06:16:44 -0700 Received: by ginger.lcs.mit.edu id AA20631; Thu, 14 May 92 09:15:31 -0400 Date: Thu, 14 May 92 09:15:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9205141315.AA20631@ginger.lcs.mit.edu> To: dcarr@donut.gandalf.ca, fbaker@acc.com Subject: Re: Cc: estgoar@ucdavis.ucdavis.edu, ietf-ppp@ucdavis.ucdavis.edu, jnc@ginger.lcs.mit.edu >> shouldn't be $60,000 in royalties as with V42.bis, better compression, >> and no patents! No patents *yet*. Since the Patent Office seems to be utterly ignorant of prior openly known work in the field of algorithms (i.e. I sometimes think their attitude is if they didn't patent it already, it doesn't exist, and must be patentable), and since a patent, once issued, can apparently only be overturned by a (usually expensive) lawsuit, don't count on it. (I.e., once granted, even if you show them the prior art, the Patent Office can't retract the patent. If I seem a little unhappy with the Patent Office, I am.) The only thing I would *count on* for this is things that *are* patented, but for which the patent has been placed in the public domain. Noel From ietf-ppp-request@aggie.ucdavis.edu Thu May 14 15:29:49 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA16750; Thu, 14 May 92 15:03:53 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14665; Thu, 14 May 92 14:00:22 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA14264; Thu, 14 May 92 13:46:19 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22024; Thu, 14 May 92 13:44:43 -0700 Date: Thu, 14 May 92 13:34:56 EDT From: "William Allen Simpson" Message-Id: <342.bsimpson@angband.stanford.edu> To: ietf-ppp@aggie.ucdavis.edu Subject: Re: LAPB compatibility > While I think the algorithm is cute, I worry about this in > another context. We have spoken, as a group, about multiple > PPP links in parallel, although we haven't resolved whether > there are common or separate NCPs, etc. > There are *definitely* separate NCPs for each link. It could hardly be otherwise in a heterogeneous dynamic dial-up context (NetBlazer example: a sync line, with backup by a combined pool of 16550 and Digiboard async ports, using newer and older modems). Each link is likely to have quite different configuration parameters, and you might want to have different network-layer traffic over each type of link. > Probably the other way around; one generally routes some well > specified set of protocols and bridges the rest. > Only if you are of the bridging faith. Discovering the set of transportable protocols is easy, since they each have a NCP for self-configuration. > > Also, it would sure be nice to limit the scope of the LAP-B options if > > possible. Is MLP useful? Do we really need to support both SABM and > > SABME? Maybe we could even fix the window size, although that might be > > difficult. > > > I think this is open to discussion. One of the things that PPP is > supposed to address is the need to setup such parameters in advance. > There are a lot of setup parameters to be considered. I would like them > all to be negotiated. > > Yes, that's why we need a 500 object MIB (or was it 400? I > forget:^) > We need the MIB because too many of us are tired of having to configure boxes by hand. It's easier to keep them in a MIB than on little sheets of paper tucked under the device. PPP has this nice little negotiation mechanism to work things out dynamically. Of course, this takes extra work by the programmers (once) instead of the sysadmin (1,000,000 times). > A little more seriously, we could limit the thing to selecting > between modulo 8 and modulo 128; actually negotiating the > window might not be necessary. My comment would be that once > you've set aside an octet for the boolean, you may as well make > it an integer in 1..127. > As I said, open to discussion. We could eliminate even these if we state: "This is the PPP compression version of LAPB, and it always uses these fixed parameters." I just don't think people want to do that. > We are getting so many variables that it seems to me that we need a > separate NCP for LAP-B, rather than a single LCP option. > > That doesn't make a lot of sense to me, as it makes us > negotiate something about the *link* in an NCP. That doesn't > sound like the right functional division. > OK, wrong name. The LAPB-LCP then. Just a separate control protocol. We have another 4091 to hand out in the c--- series. That is, we start up the link, and after authentication, etc, send a LAPB-LCP packet to see if this implementation handles LAPB headers. It might have 1 to 4 options, separately negotiated. My experience is that this is easier to code, and get right. We already had the problem with negotiating multiple values in one option with IPCP addresses. I want to avoid that boondoggle this time around. Don't think layers, think practical division. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@aggie.ucdavis.edu Thu May 14 22:51:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05030; Thu, 14 May 92 22:50:55 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24365; Thu, 14 May 92 19:18:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from bridge2.NSD.3Com.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24345; Thu, 14 May 92 19:17:37 -0700 Received: from himagiri.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA13989 (5.65c/IDA-1.4.4nsd for ); Thu, 14 May 1992 19:16:28 -0700 Received: from localhost.NSD.3Com.COM by himagiri.NSD.3Com.COM with SMTP id AA22692 (5.65c/IDA-1.4.4-910725 for ); Thu, 14 May 1992 19:16:25 -0700 Message-Id: <199205150216.AA22692@himagiri.NSD.3Com.COM> To: ietf-ppp@aggie.ucdavis.edu Cc: vsp@NSD.3Com.COM Subject: RFC1171/1172 and new drafts Organization: 3Com, 5400 Bayfront Plaza, Santa Clara, CA 95052-8145 Phone.......: (408) 764-5226 (Office) (408) 764-5000 (General Office) Date: Thu, 14 May 92 19:16:23 -0700 From: Venkat Prasad Is there a "delta" document that describes the differences between the two versions ? What is the easiest way to know this without having the two side by side and comparing them line by line. thanks /Prasad From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 15 06:51:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA26188; Fri, 15 May 92 06:47:57 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA22675; Fri, 15 May 92 06:29:35 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25125; Fri, 15 May 92 06:20:25 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from Angband.Stanford.EDU by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24880; Fri, 15 May 92 06:10:19 -0700 Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22945; Fri, 15 May 92 06:09:06 -0700 Date: Fri, 15 May 92 08:30:53 EDT From: "William Allen Simpson" Message-Id: <353.bsimpson@angband.stanford.edu> To: internet-drafts@nri.reston.va.us Cc: ietf-ppp@ucdavis.ucdavis.edu, iesg@nri.reston.va.us Subject: ppp-authentication draft Please find the latest draft PPP Authentication Protocols text, at: angband.stanford.edu:pub/ppp/ap.txt This includes the new required draft blurb. To the PPP WG: It also includes various text additions requested by the Security folks. Most of these are religious in nature, but some have prompted me to add Implementation Notes to clarify the practical application of the protocols. To the IESG: The approval time for this protocol is holding up all of the others, since it must be published with LCP, LQM and IPCP to completely obsolete RFCs 1171 and 1172. I was lead to believe that there was conditional approval, pending SAAG comment (and any such changes would be added on the way to the RFC editor), but nothing has happened in over a month. Please consider this at your earliest convenience. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From ietf-ppp-request@ucdavis.ucdavis.edu Fri May 15 12:02:48 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06203; Fri, 15 May 92 11:52:50 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA25081; Fri, 15 May 92 11:31:17 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05709; Fri, 15 May 92 11:23:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from colossus.cs.psu.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA05493; Fri, 15 May 92 11:10:25 -0700 Received: by colossus.cs.psu.edu id <36871>; Fri, 15 May 1992 14:09:16 -0400 From: Bryce Nutter To: ietf-ppp@ucdavis.ucdavis.edu Subject: Paper on PPP Message-Id: <92May15.140916edt.36871@colossus.cs.psu.edu> Date: Fri, 15 May 1992 14:09:14 -0400 Hi, I'm looking for a paper on PPP that is on the level of design and performance as opposed to detailed specifics on the protocol. I asked Drew Perkins and he refered me to you. Thanks for your time. Sincerely, Bryce From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 19 15:12:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23845; Tue, 19 May 92 15:01:22 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11645; Tue, 19 May 92 14:39:34 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21968; Tue, 19 May 92 14:33:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay2.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21589; Tue, 19 May 92 14:29:17 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04611; Tue, 19 May 92 17:28:18 -0400 Received: from natadm.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 172658.18899; Tue, 19 May 1992 17:26:58 EDT Received: by natadm.noname (4.1/SMI-4.1) id AA22567; Mon, 18 May 92 19:52:50 PDT Date: Mon, 18 May 92 19:52:50 PDT From: natadm!rching@uunet.UU.NET (Robert Ching) Message-Id: <9205190252.AA22567@natadm.noname> To: ietf-ppp@ucdavis.ucdavis.edu, phil@uunet.UU.NET, ycw@uunet.UU.NET, simon@uunet.UU.NET, henry@uunet.UU.NET, chi@uunet.UU.NET, david@uunet.UU.NET, yang@uunet.UU.NET, maurice@uunet.UU.NET, shu@uunet.UU.NET, uunet!napa.Telebit.COM!mlewis@uunet.UU.NET References: <9205120200.AA29380@napa.TELEBIT.COM> Subject: PPP-Athon is June 1-5 Mark, We (NAT) would like to participate in the "PPP-Athon" event. Our product (LANB 280) supports IP and bridging over sync PPP connections. - Robert Ching (Network Applications Technology Inc.) natadm!rching@uunet.uu.net phone: (408) 370-4270 fax: (408) 370-4222 From ietf-ppp-request@ucdavis.ucdavis.edu Tue May 19 15:23:25 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA24786; Tue, 19 May 92 15:16:27 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA11717; Tue, 19 May 92 14:45:47 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21992; Tue, 19 May 92 14:33:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from relay2.UU.NET by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA21592; Tue, 19 May 92 14:29:17 -0700 Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA04625; Tue, 19 May 92 17:28:20 -0400 Received: from natadm.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 172657.18891; Tue, 19 May 1992 17:26:57 EDT Received: by natadm.noname (4.1/SMI-4.1) id AA22553; Mon, 18 May 92 19:52:10 PDT Date: Mon, 18 May 92 19:52:10 PDT From: natadm!rching@uunet.UU.NET (Robert Ching) Message-Id: <9205190252.AA22553@natadm.noname> To: cc.@uunet.UU.NET, ietf-ppp@ucdavis.ucdavis.edu, phil@uunet.UU.NET, ycw@uunet.UU.NET, simon@uunet.UU.NET, henry@uunet.UU.NET, chi@uunet.UU.NET, david@uunet.UU.NET, yang@uunet.UU.NET, maurice@uunet.UU.NET, shu@uunet.UU.NET, uunet!napa.Telebit.COM!mlewis@uunet.UU.NET References: <9205120200.AA29380@napa.TELEBIT.COM> Subject: PPP-Athon is June 1-5 Mark, We (NAT) would like to participate in the "PPP-Athon" event. Our product (LANB 280) supports IP and bridging over sync PPP connections. - Robert Ching (Network Applications Technology Inc.) natadm!rching@uunet.uu.net phone: (408) 370-4270 fax: (408) 370-4222 From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 27 12:22:04 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA25156; Wed, 27 May 92 12:11:02 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA16410; Wed, 27 May 92 11:39:10 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23876; Wed, 27 May 92 11:31:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from LANSLIDE.HLS.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA23530; Wed, 27 May 92 11:22:29 -0700 Received: by lanslide.hls.com (4.1/SMI-4.0) id AA17662; Wed, 27 May 92 11:21:38 PDT Date: Wed, 27 May 92 11:21:38 PDT From: kenb@hls.com (Ken Brock) Message-Id: <9205271821.AA17662@lanslide.hls.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Latest Source for PPP Cc: kenb@hls.com I am interested in implementing PPP in my products Terminal Server. Could you add me to the mailing list or send me some information for obtaining a copy of the latest source code for this up-and-coming protocol? Thank you, Kenneth Brock Hughes LAN Systems 415-966-7975 1225 Charleston Rd Mountain View, CA 94043 kenb@hls.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 27 14:51:18 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA00194; Wed, 27 May 92 14:44:56 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA17803; Wed, 27 May 92 14:09:32 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28779; Wed, 27 May 92 14:02:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA28426; Wed, 27 May 92 13:51:14 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA11569; Wed, 27 May 92 16:42:28 EDT Date: Wed, 27 May 92 16:42:28 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9205272042.AA11569@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: new mib a new version of the mib has been sent to the internet drafts repositories. i do not know when it will show up there. here's a copy frank --------------------------------------------- Internet Draft Experimental Definitions of Managed Objects for the Point-to-Point Protocol 27 May 1992 Frank J. Kastenholz Clearpoint Research Corp 35 Parkwood Drive Hopkinton, Mass 01748 USA kasten@europa.clearpoint.com Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. This document will be submitted to the Internet Activities Board as a Draft Standard. This document defines an experimental extension to the SNMP MIB. Upon publication as a Draft Standard, a new MIB number will be assigned. This is a working document only, it should neither be cited nor quoted Internet Draft PPP MIB May 1992 in any formal document. This document will expire before 2 Dec. 1992. Distribution of this document is unlimited. Please send comments to kasten@europa.clearpoint.com. 1. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing subnetwork interfaces using the family of Point-to-Point Protocols[8, 9, 10, 11, & 12]. This memo does not specify a standard for the Internet community. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 2] Internet Draft PPP MIB May 1992 2. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212 defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1156 which defines MIB-I, the core set of managed objects for the Internet suite of protocols. RFC 1213, defines MIB-II, an evolution of MIB-I based on implementation experience and new operational requirements. RFC 1157 which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 3] Internet Draft PPP MIB May 1992 3. Objects Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [3] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [1] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. The SMI specifies the use of the basic encoding rules of ASN.1 [4], subject to the additional requirements imposed by the SNMP. 3.1. Format of Definitions Section 5 contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [5,6]. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 4] Internet Draft PPP MIB May 1992 4. Overview 4.1. Object Selection Criteria To be consistent with IAB directives and good engineering practice, an explicit attempt was made to keep this MIB as simple as possible. This was accomplished by applying the following criteria to objects proposed for inclusion: (1) Require objects be essential for either fault or configuration management. In particular, objects for which the sole purpose was to debug applications ware explicitly excluded from the MIB. (2) Consider evidence of current use and/or utility. (3) Limit the total of objects. (4) Exclude objects which are simply derivable from others in this or other MIBs. 4.2. Structure of the PPP This section describes the basic model of PPP used in developing the PPP MIB. This information should be useful to the implementor in understanding some of the basic design decisions of the MIB. The PPP is not one single protocol but a large family of protocols. Each of these is, in itself, a fairly complex protocol. The PPP protocols may be divided into three rough categroies: Control Protocols The Control Protocols are used to control the operation of the PPP. The Control Protocols include the Link Control Protocol (LCP), the Password Authentication Protocol (PAP), the Link Quality Report (LQR), and the Challenge Handshake Authentication Protocol (CHAP). Network Protocols The Network Protocols are used to move the network traffic over the PPP interface. A Network Protocol encapsulates the datagrams of a specific higher-layer Frank J. Kastenholz Expires 2 Dec. 1992 [Page 5] Internet Draft PPP MIB May 1992 protocol that is using the PPP as a data link. Note that within the context of PPP, the term "Network Protocol" does not imply an OSI Layer-3 protocol; for instance, there is a Bridging network protocol. Network Control Protocols (NCPs) The NCPs are used to control the operation of the Network Protocols. Generally, each Network Protocol has its own Network Control Protocol; thus, the IP Network Protocol has its IP Control Protocol, the Bridging Network Protocol has its Bridging Network Control Protocol and so on. 4.3. MIB Groups Objects in this MIB are arranged into several MIB groups. Each group is organized as a set of related objects. These groups are the basic unit of conformance: if the semantics of a group is applicable to an implementation then all objects in the group must be implemented. The PPP MIB is organized into the following MIB Groups: The PPP Link Group This group represents the lowest "level" of the PPP protocol. This group contains two tables, one containing status information and the other configuration information. The configuration table is split off of the status so that it may be placed in a separate MIB View for security purposes. Implementation of this group is mandatory for all PPP implementations. The PPP LQR Group This group provides the basic MIB variables that apply to the PPP LQR Protocol. This group provides MIB access to the information required for LQR processing. This group contains two tables, one containing status information and the other configuration information. The configuration table is split off of the status so that it Frank J. Kastenholz Expires 2 Dec. 1992 [Page 6] Internet Draft PPP MIB May 1992 may be placed in a separate MIB View for security purposes. Implementation of the PPP LQR Group is mandatory for all PPP implementations that implement LQR. The PPP LQR Extensions Group The PPP LQR Extensions group contains the most recently received LQR packet. This is done in order to facilitate external implementations of the Link Quality determination policies. It is not practical to examine the relevant MIB objects which are used to generate LQR packets since LQR policies may require synchronization of the values of all data used to determine Link Qualitiy; i.e., the values of the relevant counters must all be taken at the same instant in time. Thus, by recording the last received LQR packet, a synchronized record of the relevant data is available. As this information may not be efficiently maintained on all PPP implementations, implementation of this group is optional. The PPP IP Group The PPP IP Group contains configuration, status, and control variables that apply to the operation of IP over PPP. Implementation of this group is mandatory for all implementations of PPP that support IP over PPP. The PPP Bridge Group The PPP Bridge Group contains configuration, status, and control variables that apply to the operation of Bridging over PPP. Implementation of this group is mandatory for all implementations of PPP that support the Bridging over PPP. The PPP CHAP Group The PPP CHAP Group contains configuration, status, and control variables that apply to the PPP Challange Frank J. Kastenholz Expires 2 Dec. 1992 [Page 7] Internet Draft PPP MIB May 1992 Handshake Authentication Protocol. Implementation of this group is mandatory for all implementations of PPP that support the PPP CHAP. The PPP PAP Group The PPP PAP Group contains configuration, status, and control variables that apply to the PPP Password Authentication Protocol. Implementation of this group is mandatory for all implementations of PPP that support the PPP PAP. 4.4. Relationship to Interface and Interface Extensions Groups The PPP Mib is a medium-specific extension to the standard MIB-2 interface group[2] and to the Interface Extensions MIB [7]. This section discusses certain components of these groups when the interface is a PPP interface. The entire PPP instance represents a single interface in the sense used in [2] and thus has a single entry in the ifTable. All PPP packets are defined in [8] as being broadcast packets. Thus, the packets are counted as non-unicast packets in the ifTable (ifInNUcastPkts and ifOutNUCastPkts) and as broadcasts in the ifExtnsTable (ifExtnsBroadcastsReceviedOks and ifExtnsBroadcastsTransmittedOks). ifSpecific Contains the OBJECT IDENTIFIER ppp. ifAdminStatus Setting this object to up will inject an administrative open event into the LCP's finite state machine. Setting this object to down will inject an administrative close event into the LCP's finite state machine. ifOperStatus Represents the state of the LCP Finite State Machine. If the Finite State Machine is in the Opened state then the value of ifOperStatus is up, otherwise the value of ifOperStatus is down. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 8] Internet Draft PPP MIB May 1992 5. Definitions RFCppp-MIB DEFINITIONS ::= BEGIN IMPORTS experimental, Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 TRAP-TYPE FROM RFC-1215; -- PPP MIB ppp OBJECT IDENTIFIER ::= { experimental 18 } -- The individual Groups within the PPP MIB pppLink OBJECT IDENTIFIER ::= { ppp 1 } pppLqr OBJECT IDENTIFIER ::= { ppp 2 } pppIp OBJECT IDENTIFIER ::= { ppp 3 } pppBridge OBJECT IDENTIFIER ::= { ppp 4 } pppSecurity OBJECT IDENTIFIER ::= { ppp 5 } pppTests OBJECT IDENTIFIER ::= { ppp 6 } -- -- The following are place holders for later -- elements of the PPP MIBs. When the -- indicated encpasulation is finished, the -- MIB for that encapsulation will be placed -- under the given OID. -- pppIpx OBJECT IDENTIFIER ::= { ppp 7 } pppIso OBJECT IDENTIFIER ::= { ppp 8 } pppAppleTalk OBJECT IDENTIFIER ::= { ppp 9 } pppDecNet OBJECT IDENTIFIER ::= { ppp 10 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 9] Internet Draft PPP MIB May 1992 5.1. PPP Link Group -- -- The PPP Link Group. Implementation of this -- group is mandatory for all PPP entities. -- pppLinkStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLinkStatusEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing PPP-link specific variables for this PPP implementation." ::= { pppLink 1 } pppLinkStatusEntry OBJECT-TYPE SYNTAX PppLinkStatusEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Management information about a particular PPP Link." INDEX { pppLinkStatusIndex } ::= { pppLinkStatusTable 1 } PppLinkStatusEntry ::= SEQUENCE { pppLinkStatusIndex INTEGER, pppLinkStatusPhysicalIndex INTEGER, pppLinkStatusBadAddresses Counter, pppLinkStatusBadControls Counter, pppLinkStatusPacketTooLongs Counter, pppLinkStatusBadFCSs Counter, pppLinkStatusLocalMRU INTEGER, pppLinkStatusRemoteMRU INTEGER, Frank J. Kastenholz Expires 2 Dec. 1992 [Page 10] Internet Draft PPP MIB May 1992 pppLinkStatusLocalToPeerACCMap OCTET STRING, pppLinkStatusPeerToLocalACCMap OCTET STRING, pppLinkStatusLocalToRemoteProtocolCompression INTEGER, pppLinkStatusRemoteToLocalProtocolCompression INTEGER, pppLinkStatusLocalToRemoteACCompression INTEGER, pppLinkStatusRemoteToLocalACCompression INTEGER, pppLinkStatusTransmit32BitFcs INTEGER, pppLinkStatusReceive32BitFcs INTEGER } pppLinkStatusIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each PPP link. Its value ranges between 1 and the value of ifNumber. The interface identified by a particular value of this index is that identified by the same value of an ifIndex object instance. The value for each link must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { pppLinkStatusEntry 1 } pppLinkStatusPhysicalIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the interface over which this PPP Link is operating. This interface would usually be an HDLC or RS-232 type of interface. If there is no lower-layer interface element, or there is no ifEntry for the element, or the element can Frank J. Kastenholz Expires 2 Dec. 1992 [Page 11] Internet Draft PPP MIB May 1992 not be identified, then the value of this object is 0." ::= { pppLinkStatusEntry 2 } pppLinkStatusBadAddresses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received with an incorrect Address Field. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link." REFERENCE "Section 3.1, Address Field, of [8]." ::= { pppLinkStatusEntry 3 } pppLinkStatusBadControls OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received on this link with an incorrect Control Field. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link." REFERENCE "Section 3.1, Flag Sequence, of [8]." ::= { pppLinkStatusEntry 4 } pppLinkStatusPacketTooLongs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of received packets that have been discarded because their length exceeded the MRU. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link. NOTE, Frank J. Kastenholz Expires 2 Dec. 1992 [Page 12] Internet Draft PPP MIB May 1992 packets which are longer than the MRU but which are successfully received and processed are NOT included in this count." ::= { pppLinkStatusEntry 5 } pppLinkStatusBadFCSs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of received packets that have been discarded due to having an incorrect FCS. This counter is a component of the ifInErrors variable that is associated with the interface that represents this PPP Link." ::= { pppLinkStatusEntry 6 } pppLinkStatusLocalMRU OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The final negotiated MRU value for the local PPP Entity. This value is the MRU that the remote entity has accepted for the local PPP entity." ::= { pppLinkStatusEntry 7 } pppLinkStatusRemoteMRU OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The final negotiated MRU value for the remote PPP Entity." ::= { pppLinkStatusEntry 8 } pppLinkStatusLocalToPeerACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-only STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 13] Internet Draft PPP MIB May 1992 DESCRIPTION "The ACC Map used by the local PPP entity when transmitting packets to the remote PPP entity." ::= { pppLinkStatusEntry 9 } pppLinkStatusPeerToLocalACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-only STATUS mandatory DESCRIPTION "The ACC Map used by the remote PPP entity when transmitting packets to the local PPP entity." ::= { pppLinkStatusEntry 10 } pppLinkStatusLocalToRemoteProtocolCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local PPP entity will use Protocol Compression when transmitting packets to the remote PPP entity. This is the Protocol Compression option that the remote PPP entity has advertised to the local entity and that the local PPP entity has accepted." ::= { pppLinkStatusEntry 11 } pppLinkStatusRemoteToLocalProtocolCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the remote PPP entity will use Protocol Compression when transmitting Frank J. Kastenholz Expires 2 Dec. 1992 [Page 14] Internet Draft PPP MIB May 1992 packets to the local PPP entity. This is the Protocol Compression option that the local PPP entity has advertised to the remote entity and that the remote PPP entity has accepted." ::= { pppLinkStatusEntry 12 } pppLinkStatusLocalToRemoteACCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local PPP entity will use Address and Control Compression when transmitting packets to the remote PPP entity. This is the Address and Control Compression option that the remote PPP entity has advertised to the local entity and that the local PPP entity has accepted." ::= { pppLinkStatusEntry 13 } pppLinkStatusRemoteToLocalACCompression OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the remote PPP entity will use Address and Control Compression when transmitting packets to the local PPP entity. This is the Address and Control Compression option that the local PPP entity has advertised to the remote entity and that the remote PPP entity has accepted." ::= { pppLinkStatusEntry 14 } pppLinkStatusTransmit32BitFcs OBJECT-TYPE SYNTAX INTEGER {false (1), true (2)} Frank J. Kastenholz Expires 2 Dec. 1992 [Page 15] Internet Draft PPP MIB May 1992 ACCESS read-only STATUS mandatory DESCRIPTION "If true(2) then the local node will send packets to the remote node using the 32 bit FCS. If false(1) then the 16 bit FCS is in use." REFERENCE "Section 7.9, 32 Bit FCS, of [8]." ::= { pppLinkStatusEntry 15 } pppLinkStatusReceive32BitFcs OBJECT-TYPE SYNTAX INTEGER {false (1), true (2)} ACCESS read-only STATUS mandatory DESCRIPTION "If true(2) then the remote node will send packets to the local node using the 32 bit FCS. If false(1) then the 16 bit FCS is in use." REFERENCE "Section 7.9, 32 Bit FCS, of [8]." ::= { pppLinkStatusEntry 16 } pppLinkConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLinkConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing the LCP configuration parameters for this PPP Link. These variables represent the initial configuration of the PPP Link. The actual values of the parameters may be changed when the link is brought up via the LCP options negotiation mechanism." ::= { pppLink 2 } pppLinkConfigEntry OBJECT-TYPE SYNTAX PppLinkConfigEntry ACCESS not-accessible STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 16] Internet Draft PPP MIB May 1992 DESCRIPTION "Configuration information about a particular PPP Link." INDEX { pppLinkConfigIndex } ::= { pppLinkConfigTable 1 } PppLinkConfigEntry ::= SEQUENCE { pppLinkConfigIndex INTEGER, pppLinkConfigInitialMRU INTEGER, pppLinkConfigReceiveACCMap OCTET STRING, pppLinkConfigXmitACCMap OCTET STRING, pppLinkConfigMagicNumber INTEGER, pppLinkConfig32BitFCS INTEGER } pppLinkConfigIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each PPP link. Its value ranges between 1 and the value of ifNumber. The interface identified by a particular value of this index is that identified by the same value of an ifIndex object instance. The value for each link must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { pppLinkConfigEntry 1 } pppLinkConfigInitialMRU OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The initial Maximum Receive Unit (MRU) that Frank J. Kastenholz Expires 2 Dec. 1992 [Page 17] Internet Draft PPP MIB May 1992 the local PPP entity will advertise to the remote entity. If the value of this variable is 0 then the local PPP entity will not advertise any MRU to the remote entity and the default MRU will be assumed. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.2, Maximum Receive Unit of [8]." DEFVAL { 1500 } ::= { pppLinkConfigEntry 2 } pppLinkConfigReceiveACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-write STATUS mandatory DESCRIPTION "The Asynchronous-Control-Character-Map (ACC) that the local PPP entity requires for use on its receive side. In effect, this is the ACC Map that is required in order to ensure that the local modem will successfully receive all characters. The actual ACC map used on the receive side of the link will be a combination of the local node's pppLinkConfigReceiveACCMap and the remote node's pppLinkConfigXmitACCMap. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.3, page 4, Async-Control-Character- Map of [8]." DEFVAL { 'ffffffff'h } ::= { pppLinkConfigEntry 3 } pppLinkConfigXmitACCMap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (4)) ACCESS read-write STATUS mandatory DESCRIPTION "The Asynchronous-Control-Character-Map (ACC) that the local PPP entity requires for use on its transmit side. In effect, this is the ACC Map that is required in order to ensure that all characters can be successfully transmitted Frank J. Kastenholz Expires 2 Dec. 1992 [Page 18] Internet Draft PPP MIB May 1992 through the local modem. The actual ACC map used on the transmit side of the link will be a combination of the local node's pppLinkConfigXmitACCMap and the remote node's pppLinkConfigReceiveACCMap. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.3, page 4, Async-Control-Character- Map of [8]." DEFVAL { 'ffffffff'h } ::= { pppLinkConfigEntry 4 } pppLinkConfigMagicNumber OBJECT-TYPE SYNTAX INTEGER {false (1), true (2)} ACCESS read-write STATUS mandatory DESCRIPTION "If true(2) then the local node will attempt to perform Magic Number negotiation with the remote node. If false(1) then this negotiation is not performed. In any event, the local node will comply with any magic number negotiations attempted by the remote node, per the PPP specification. Changing this object will have effect when the link is next restarted." REFERENCE "Section 7.6, Magic Number, of [8]." DEFVAL { false } ::= { pppLinkConfigEntry 5 } pppLinkConfig32BitFCS OBJECT-TYPE SYNTAX INTEGER {false (1), true (2)} ACCESS read-write STATUS mandatory DESCRIPTION "If true(2) then the local node will attempt to perform 32 Bit FCS negotiation with the remote node. If false(1) then this negotiation is not performed. In any event, the local node will comply with any 32 Bit FCS negotiations attempted by the remote node, per the PPP specification. Changing this object will have Frank J. Kastenholz Expires 2 Dec. 1992 [Page 19] Internet Draft PPP MIB May 1992 effect when the link is next restarted." REFERENCE "Section 7.9, 32 Bit FCS, of [8]." DEFVAL { false } ::= { pppLinkConfigEntry 6 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 20] Internet Draft PPP MIB May 1992 5.2. PPP LQR Group -- -- The PPP LQR Group. -- Implementation of this group is mandatory for all -- PPP implementations that implement LQR. -- pppLqrTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLqrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the LQR parameters and statistics for the local PPP entity." ::= { pppLqr 1 } pppLqrEntry OBJECT-TYPE SYNTAX PppLqrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "LQR information for a particular PPP link. A PPP link will have an entry in this table if and only if LQR Quality Monitoring has been successfully negotiated for said link." INDEX { pppLqrIndex } ::= { pppLqrTable 1 } PppLqrEntry ::= SEQUENCE { pppLqrIndex INTEGER, pppLqrQuality INTEGER, pppLqrInGoodOctets Counter, pppLqrLocalPeriod INTEGER, pppLqrRemotePeriod INTEGER, pppLqrOutLQRs Counter, pppLqrInLQRs Frank J. Kastenholz Expires 2 Dec. 1992 [Page 21] Internet Draft PPP MIB May 1992 Counter } pppLqrIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the PPP Link entity over which this LQR is operating." ::= { pppLqrEntry 1 } pppLqrQuality OBJECT-TYPE SYNTAX INTEGER { good(1), bad(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The current quality of the link as declared by the local PPP entity's Link-Quality Management modules. No effort is made to define good or bad, nor the policy used to determine it." ::= { pppLqrEntry 2 } pppLqrInGoodOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The LQR InGoodOctets counter for this link." REFERENCE "Section 2.2, Counters, of [12]." ::= { pppLqrEntry 3 } pppLqrLocalPeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 22] Internet Draft PPP MIB May 1992 DESCRIPTION "The LQR reporting period that is in effect for the local PPP entity. The local entity received a configure-ack for this value from the remote PPP entity." REFERENCE "Section 2.5, Configuration Option Format, of [12]." ::= { pppLqrEntry 4 } pppLqrRemotePeriod OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The LQR reporting period that is in effect for the remote PPP entity. The local entity sent a configure-ack for this value in response to the configure-req from the remote PPP entity." REFERENCE "Section 2.5, Configuration Option Format, of [12]." ::= { pppLqrEntry 5 } pppLqrOutLQRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The value of the OutLQRs counter on the local node for the link identified by pppLqrLinkIndex." REFERENCE "Section 2.2, Counters, of [12]." ::= { pppLqrEntry 6 } pppLqrInLQRs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The value of the InLQRs counter on the local Frank J. Kastenholz Expires 2 Dec. 1992 [Page 23] Internet Draft PPP MIB May 1992 node for the link identified by pppLqrLinkIndex." REFERENCE "Section 2.2, Counters, of [12]." ::= { pppLqrEntry 7 } -- -- The PPP LQR Configuration table. -- pppLqrConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLqrConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the LQR Configuration parameters for the local PPP entity." ::= { pppLqr 2 } pppLqrConfigEntry OBJECT-TYPE SYNTAX PppLqrConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "LQR configuration information for a particular PPP link." INDEX { pppLqrConfigIndex } ::= { pppLqrConfigTable 1 } PppLqrConfigEntry ::= SEQUENCE { pppLqrConfigIndex INTEGER, pppLqrConfigPeriod INTEGER, pppLqrConfigStatus INTEGER } pppLqrConfigIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 24] Internet Draft PPP MIB May 1992 DESCRIPTION "A unique value which ranges between 1 and the value of ifNumber. The interface identified by a particular value of this value is that identified by the same value of an ifIndex object instance. The value for each link must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. This object identifies the ifTable entry that is associated with this instance of the LQR Protocol." ::= { pppLqrConfigEntry 1 } pppLqrConfigPeriod OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The LQR Reporting Period that the local PPP entity will attempt to negotiate with the remote entity, in units of seconds. Changing this object will have effect when the link is next restarted." REFERENCE "Section 2.5, Configuration Option Format, of [12]." DEFVAL { 0 } ::= { pppLqrConfigEntry 2 } pppLqrConfigStatus OBJECT-TYPE SYNTAX INTEGER {disabled (1), enabled (2)} ACCESS read-write STATUS mandatory DESCRIPTION "If enabled(2) then the local node will attempt to perform LQR negotiation with the remote node. If disabled(1) then this negotiation is not performed. In any event, the local node will comply with any magic number negotiations attempted by the remote node, per the PPP specification. Changing this object will have effect when the link is next restarted. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 25] Internet Draft PPP MIB May 1992 Setting this object to the value disabled(1) has the effect of invalidating the corresponding entry in the pppLqrConfigTable object. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use." REFERENCE "Section 7.6, Magic Number, of [8]." DEFVAL { enabled } ::= { pppLqrConfigEntry 3 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 26] Internet Draft PPP MIB May 1992 5.3. PPP LQR Extensions Group -- -- The PPP LQR Extensions Group. -- Implementation of this group is optional. -- -- The intent of this group is to allow external -- implementation of the policy mechanisms that -- are used to declare a link to be "bad" or not. -- -- It is not practical to examine the MIB objects -- which are used to generate LQR packets since -- LQR policies tend to require synchronization of -- the values of all data used to determine Link -- Qualitiy; i.e. the values of the relevant counters -- must all be taken at the same instant in time. -- pppLqrExtnsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppLqrExtnsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing extended LQR parameters local PPP entity." ::= { pppLqr 3 } pppLqrExtnsEntry OBJECT-TYPE SYNTAX PppLqrExtnsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Extended LQR information for a particular PPP link. Assuming that this group has been implemented, a PPP link will have an entry in this table if and only if LQR Quality Monitoring has been successfully negotiated for said link." INDEX { pppLqrExtnsIndex } ::= { pppLqrExtnsTable 1 } PppLqrExtnsEntry ::= SEQUENCE { pppLqrExtnsIndex Frank J. Kastenholz Expires 2 Dec. 1992 [Page 27] Internet Draft PPP MIB May 1992 INTEGER, pppLqrExtnsLastReceivedLqrPacket OCTET STRING(SIZE(68)) } pppLqrExtnsIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value which ranges between 1 and the value of ifNumber. The interface identified by a particular value of this value is that identified by the same value of an ifIndex object instance. The value for each link must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." ::= { pppLqrExtnsEntry 1 } pppLqrExtnsLastReceivedLqrPacket OBJECT-TYPE SYNTAX OCTET STRING(SIZE(68)) ACCESS read-only STATUS mandatory DESCRIPTION "This object contains the most recently received LQR packet. The format of the packet is as described in the LQM Protocol specificiation. The LQR packet is stored in network byte order. The LAP-B and PPP headers are not stored in this object; the first four octets of this variable contain the Magic- Number field, the second four octets contain the LastOutLQRs field and so on." ::= { pppLqrExtnsEntry 2 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 28] Internet Draft PPP MIB May 1992 5.4. PPP IP Group -- -- The PPP IP Group. -- Implementation of this group is mandatory for all -- PPP implementations that support operating IP over PPP. -- pppIpTable OBJECT-TYPE SYNTAX SEQUENCE OF PppIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the IP parameters and statistics for the local PPP entity." ::= { pppIp 1 } pppIpEntry OBJECT-TYPE SYNTAX PppIpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "IPCP information for a particular PPP link. A PPP link will have an entry in this table if and only if running IP over the PPP link has been successfully negotiated for said link." INDEX { pppIpIndex } ::= { pppIpTable 1 } PppIpEntry ::= SEQUENCE { pppIpIndex INTEGER, pppIpLocalToRemoteCompressionProtocol INTEGER, pppIpRemoteToLocalCompressionProtocol INTEGER, pppIpRemoteMaxSlotId INTEGER, pppIpLocalMaxSlotId INTEGER, pppIpOperStatus INTEGER Frank J. Kastenholz Expires 2 Dec. 1992 [Page 29] Internet Draft PPP MIB May 1992 } pppIpIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the ifTable that is associated with the PPP Link over which this instance of the IP network and control protocol are operating." ::= { pppIpEntry 1 } pppIpLocalToRemoteCompressionProtocol OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The IP compression protocol that the local PPP-IP entity uses when sending packets to the remote PPP-IP entity." ::= { pppIpEntry 2 } pppIpRemoteToLocalCompressionProtocol OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The IP compression protocol that the remote PPP-IP entity uses when sending packets to the local PPP-IP entity." ::= { pppIpEntry 3 } pppIpRemoteMaxSlotId OBJECT-TYPE SYNTAX INTEGER(0..255) ACCESS read-only Frank J. Kastenholz Expires 2 Dec. 1992 [Page 30] Internet Draft PPP MIB May 1992 STATUS mandatory DESCRIPTION "The Max-Slot-Id parameter that the remote node has advertised and that is in use on the link. If vj-tcp header compression is not in use on the link then the value of this object shall be 0." ::= { pppIpEntry 4 } pppIpLocalMaxSlotId OBJECT-TYPE SYNTAX INTEGER(0..255) ACCESS read-only STATUS mandatory DESCRIPTION "The Max-Slot-Id parameter that the local node has advertised and that is in use on the link. If vj-tcp header compression is not in use on the link then the value of this object shall be 0." ::= { pppIpEntry 5 } pppIpOperStatus OBJECT-TYPE SYNTAX INTEGER {opened(1), not-opened(2)} ACCESS read-only STATUS mandatory DESCRIPTION "The operational status of the IP network protocol. If the value of this object is up then the finite state machine for the IP network protocol has reached the Opened state." ::= { pppIpEntry 6 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 31] Internet Draft PPP MIB May 1992 -- -- The PPP IP Configuration table. -- This is a separate table in order to facilitate -- placing these variables in a separate MIB view. -- pppIpConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppIpConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the IP parameters and statistics for the local PPP entity." ::= { pppIp 2 } pppIpConfigEntry OBJECT-TYPE SYNTAX PppIpConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "IPCP information for a particular PPP link." INDEX { pppIpConfigIndex } ::= { pppIpConfigTable 1 } PppIpConfigEntry ::= SEQUENCE { pppIpConfigIndex INTEGER, pppIpConfigCompression INTEGER, pppIpConfigAdminStatus INTEGER } pppIpConfigIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the ifTable that is associated with the local IPCP entity." ::= { pppIpConfigEntry 1 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 32] Internet Draft PPP MIB May 1992 pppIpConfigCompression OBJECT-TYPE SYNTAX INTEGER { none(1), vj-tcp(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If none(1) then the local node will not attempt to negotiate any IP Compression option. Otherwise, the local node will attempt to negotiate compression mode indicated by the enumerated value Changing this object will have effect when the link is next restarted." REFERENCE "Section 4.0, Van Jacobson TCP/IP Header Compression of [9]." DEFVAL { none } ::= { pppIpConfigEntry 2 } pppIpConfigOperStatus OBJECT-TYPE SYNTAX INTEGER {open(1), close(2)} ACCESS read-write STATUS mandatory DESCRIPTION "The immediate desired status of the IP network protocol.Setting this object to open will inject an administrative open event into the IP network protocol's finite state machine. Setting this object to close will inject an administrative close event into the IP network protocol's finite state machine." ::= { pppIpConfigEntry 3 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 33] Internet Draft PPP MIB May 1992 5.5. PPP Bridge Group -- -- The PPP Bridge NCP Group. -- Implementation of this group is mandatory for all -- PPP implementations that support MAC Bridging over -- PPP (RFC1220). -- pppBridgeTable OBJECT-TYPE SYNTAX SEQUENCE OF PppBridgeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the parameters and statistics for the local PPP entity that are related to the operation of Bridging over the PPP." ::= { pppBridge 1 } pppBridgeEntry OBJECT-TYPE SYNTAX PppBridgeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Bridging information for a particular PPP link." INDEX { pppBridgeIndex } ::= { pppBridgeTable 1 } PppBridgeEntry ::= SEQUENCE { pppBridgeIndex INTEGER, pppBridgeLinkIndex INTEGER, pppBridgeLocalToRemoteTinygramCompression INTEGER, pppBridgeRemoteToLocalTinygramCompression INTEGER, pppBridgeLocalToRemoteLanId INTEGER, pppBridgeRemoteToLocalLanId INTEGER, pppBridgeOperStatus Frank J. Kastenholz Expires 2 Dec. 1992 [Page 34] Internet Draft PPP MIB May 1992 INTEGER } pppBridgeIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the PPP-Link entity over which this Bridge Network Protocol is operating." ::= { pppBridgeTable 2 } ::= { pppBridgeEntry 1 } pppBridgeLocalToRemoteTinygramCompression OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local node will perform Tinygram Compression when sending packets to the remote entity. If false then the local entity will not perform Tinygram Compression. If true then the local entity will perform Tinygram Compression." REFERENCE "Section 6.7, Tinygram Compression Option, of [10]" ::= { pppBridgeEntry 2 } pppBridgeRemoteToLocalTinygramCompression OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates what the local node believes to be the remote node will perform Tinygram Compression when sending packets to the local node. If false then the remote entity is not expected to perform Tinygram Compression. If Frank J. Kastenholz Expires 2 Dec. 1992 [Page 35] Internet Draft PPP MIB May 1992 true then the remote entity is expected to perform Tinygram Compression." REFERENCE "Section 6.7, Tinygram Compression Option, of [10]" ::= { pppBridgeEntry 3 } pppBridgeLocalToRemoteLanId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the local node will include the LAN Identification field in transmitted packets or not. If false(1) then the local node will not transmit this field, true(2) means that the field will be transmitted." REFERENCE "Section 6.8, LAN Identification Option, of [10]" ::= { pppBridgeEntry 4 } pppBridgeRemoteToLocalLanId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-only STATUS mandatory DESCRIPTION "Indicates whether the remote node has indicated that it will include the LAN Identification field in transmitted packets or not. If false(1) then the field will not be transmitted, if true(2) then the field will be transmitted." REFERENCE "Section 6.8, LAN Identification Option, of [10]" ::= { pppBridgeEntry 5 } pppBridgeOperStatus OBJECT-TYPE SYNTAX INTEGER {opened(1), not-opened(2)} ACCESS read-only STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 36] Internet Draft PPP MIB May 1992 DESCRIPTION "The operational status of the Bridge network protocol. If the value of this object is up then the finite state machine for the Bridge network protocol has reached the Opened state." ::= { pppBridgeEntry 6 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 37] Internet Draft PPP MIB May 1992 -- -- The PPP Bridge Configuration table -- pppBridgeConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppBridgeConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the parameters and statistics for the local PPP entity that are related to the operation of Bridging over the PPP." ::= { pppBridge 2 } pppBridgeConfigEntry OBJECT-TYPE SYNTAX PppBridgeConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Bridging Configuration information for a particular PPP link." INDEX { pppBridgeConfigIndex } ::= { pppBridgeConfigTable 1 } PppBridgeConfigEntry ::= SEQUENCE { pppBridgeConfigIndex INTEGER, pppBridgeConfigTinygram INTEGER, pppBridgeConfigRingId INTEGER, pppBridgeConfigLineId INTEGER, pppBridgeConfigLanId INTEGER, pppBridgeConfigOperStatus INTEGER } pppBridgeConfigIndex OBJECT-TYPE SYNTAX INTEGER(1..2147483648) ACCESS read-only STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 38] Internet Draft PPP MIB May 1992 DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the local PPP Bridging NCP entity." ::= { pppBridgeConfigEntry 1 } pppBridgeConfigTinygram OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local BNCP entity will not initiate the Tinygram Compression Option Negotiation. If true then the local BNCP entity will initiate negotiation of this option." REFERENCE "Section 6.7, Tinygram Compression Option, of [10]" DEFVAL { true } ::= { pppBridgeConfigEntry 2 } pppBridgeConfigRingId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local PPP Entity will not initiate a Remote Ring Identification Option negotiation. If true then the local PPP entity will intiate this negotiation. This MIB object is relevant only if the interface is for 802.5 Token Ring bridging." REFERENCE "Section 6.4, IEEE 802.5 Remote Ring Identification Option, of [10]" DEFVAL { false } ::= { pppBridgeConfigEntry 3 } pppBridgeConfigLineId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 39] Internet Draft PPP MIB May 1992 DESCRIPTION "If false then the local PPP Entity is not to initiate a Line Identification Option negotiation. If true then the local PPP entity will intiate this negotiation. This MIB object is relevant only if the interface is for 802.5 Token Ring bridging." REFERENCE "Section 6.5, IEEE 802.5 Line Identification Option, of [10]" DEFVAL { false } ::= { pppBridgeConfigEntry 4 } pppBridgeConfigLanId OBJECT-TYPE SYNTAX INTEGER { false(1), true(2) } ACCESS read-write STATUS mandatory DESCRIPTION "If false then the local BNCP entity will not initiate the LAN Identification Option Negotiation. If true then the local BNCP entity will initiate negotiation of this option." REFERENCE "Section 6.8, LAN Identification Option, of [10]" DEFVAL { false } ::= { pppBridgeConfigEntry 5 } pppBridgeConfigOperStatus OBJECT-TYPE SYNTAX INTEGER {open(1), close(2)} ACCESS read-write STATUS mandatory DESCRIPTION "The immediate desired status of the IP network protocol.Setting this object to open will inject an administrative open event into the IP network protocol's finite state machine. Setting this object to close will inject an administrative close event into the IP network protocol's finite state machine." ::= { pppBridgeConfigEntry 6 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 40] Internet Draft PPP MIB May 1992 5.6. PPP Security Configuration Group -- -- The PPP Security Configuration Group -- Implementation of this group is mandatory for all -- PPP implementations that support a PPP security -- protocol. -- -- The table in this group allows the network manager -- to configure which security protocols are to be -- used on which link and in what order of preference -- each protocol is to be tried. -- pppSecurityConfigTable OBJECT-TYPE SYNTAX SEQUENCE OF PppSecurityConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the configuration and preference parameters for PPP Security." ::= { pppSecurity 1 } pppSecurityConfigEntry OBJECT-TYPE SYNTAX PppSecurityConfigEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "CHAP information for a particular PPP link." INDEX { pppSecurityConfigLink, pppSecurityConfigPreference } ::= { pppSecurityConfigTable 1 } PppSecurityConfigEntry ::= SEQUENCE { pppSecurityConfigLink INTEGER, pppSecurityConfigPreference INTEGER, pppSecurityConfigProtocol INTEGER } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 41] Internet Draft PPP MIB May 1992 pppSecurityConfigLink OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the local PPP entity's link for which this particular security algorithm shall be attempted. A value of 0 indicates the default algorithm - i.e., this entry applies to all links for which explicit entries in the table do not exist." ::= { pppSecurityConfigEntry 1 } pppSecurityConfigPreference OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The relative preference of the security protocol identified by pppSecurityConfigProtocol. Security protocols with lower values of pppSecurityConfigPreference are tried before protocols with higher values of pppSecurityConfigPreference." ::= { pppSecurityConfigEntry 2 } pppSecurityConfigProtocol OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-write STATUS mandatory DESCRIPTION "Identifies the security protocol to be attempted on the link identified by pppSecurityConfigLink at the preference level identified by pppSecurityConfigPreference. Setting this object to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, has the effect of invalidating the corresponding entry in this table. It is an implementation-specific matter as to whether Frank J. Kastenholz Expires 2 Dec. 1992 [Page 42] Internet Draft PPP MIB May 1992 the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use." ::= { pppSecurityConfigEntry 3 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 43] Internet Draft PPP MIB May 1992 5.7. PPP CHAP Group -- -- The PPP CHAP Group. -- Implementation of this group is mandatory for all -- PPP implementations that support the CHAP protocol. -- -- pppSecurityConfigProtocol takes the OBJECT IDENTIFIER -- pppChap to indicate that the Challenge Handshake -- Authentication Protocol is to be used. -- pppChap OBJECT IDENTIFIER ::= { pppSecurity 2 } pppChapTable OBJECT-TYPE SYNTAX SEQUENCE OF PppChapEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the Chap parameters and statistics for the local PPP entity." ::= { pppChap 1 } pppChapEntry OBJECT-TYPE SYNTAX PppChapEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "CHAP information for a particular PPP link and preference level." INDEX { pppChapLink, pppChapPreference } ::= { pppChapTable 1 } PppChapEntry ::= SEQUENCE { pppChapLink INTEGER, pppChapPreference INTEGER, pppChapDigestType INTEGER } pppChapLink OBJECT-TYPE SYNTAX INTEGER(0..2147483648) Frank J. Kastenholz Expires 2 Dec. 1992 [Page 44] Internet Draft PPP MIB May 1992 ACCESS read-write STATUS mandatory DESCRIPTION "The value of pppSecurityConfigLink that identifies the entry in the pppSecurityConfig table to which this entry in the pppChapTable applies." ::= { pppChapEntry 1 } pppChapPreference OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The value of pppSecurityConfigPreference that identifies the entry in the pppSecurityConfig table to which this entry in the pppChapTable applies." ::= { pppChapEntry 2 } pppChapDigestType OBJECT-TYPE SYNTAX INTEGER { invalid(1) md5-chap-digest(2) } ACCESS read-write STATUS mandatory DESCRIPTION "The CHAP Digest format to use in attempting the CHAP authtentication as defined by the corresponding entry in the pppSecurityConfig table.Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the pppChapTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppChapType object." REFERENCE Frank J. Kastenholz Expires 2 Dec. 1992 [Page 45] Internet Draft PPP MIB May 1992 "Section 4.1, Configuration Option Format, of [11]" DEFVAL { md5-chap-digest } ::= { pppChapEntry 3 } pppChapSecretsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppChapSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the secret CHAP parameters for the local PPP entity. As this table contains secret information, it is expected that access to this table be limited to those SNMP Party-Pairs for which a privacy protocol is in use for all SNMP messages that the parties exchange. This table contains a Name and its associated Digest secret. The parameters in this table are used by the local entity when generating CHAP Response packets. The table allows for multiple name/secret pairs to be specified for a particular link by using the pppChapSecretIdIndex object. These parameters are used by a node when it attempts to authenticate itself." ::= { pppChap 2 } pppChapSecretsEntry OBJECT-TYPE SYNTAX PppChapSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Secret CHAP information to generate a single response." INDEX { pppChapSecretsLinkIndex, pppChapSecretsIdIndex } ::= { pppChapSecretsTable 1 } PppChapSecretsEntry ::= SEQUENCE { pppChapSecretsLinkIndex INTEGER, Frank J. Kastenholz Expires 2 Dec. 1992 [Page 46] Internet Draft PPP MIB May 1992 pppChapSecretsIdIndex INTEGER, pppChapSecretsName OCTET STRING, pppChapSecretsSecret OCTET STRING, pppChapSecretsStatus INTEGER } pppChapSecretsLinkIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the local PPP CHAP Entity. If the value of this object is 0 then the name/secret pair applies to all links." ::= { pppChapSecretsEntry 1 } pppChapSecretsIdIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each Name/Secret pair that has been defined for use on this link. This allows multiple Name/Secret pairs to be defined for each link. How the local entity selects which pair to use is a local implementation decision." ::= { pppChapSecretsEntry 2 } pppChapSecretsName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "A name." ::= { pppChapSecretsEntry 3 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 47] Internet Draft PPP MIB May 1992 pppChapSecretsSecret OBJECT-TYPE SYNTAX OCTET STRING -- (SIZE(16)) when MD5 ACCESS read-write STATUS mandatory DESCRIPTION "The digest secret to be associated with the name." ::= { pppChapSecretsEntry 4 } pppChapSecretsStatus OBJECT-TYPE SYNTAX INTEGER { invalid(1) valid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the pppChapSecretsTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppChapSecretsStatus object." DEFVAL { valid } ::= { pppChapSecretsEntry 5 } pppChapPeerSecretsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppChapPeerSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the secret PAP parameters that are expected of remotes that may attempt to authenticate themselves to the local PPP entity. Received CHAP Responses are expected to Frank J. Kastenholz Expires 2 Dec. 1992 [Page 48] Internet Draft PPP MIB May 1992 match one of the entries in this table. As this table contains secret information, it is expected that access to this table be limited to those SNMP Party-Pairs for which a privacy protocol is in use for all SNMP messages that the parties exchange." ::= { pppChap 3 } pppChapPeerSecretsEntry OBJECT-TYPE SYNTAX PppChapPeerSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Secret remote CHAP information for a particular Peer Name/Secret and link." INDEX { pppChapPeerSecretsLink, pppChapPeerSecretsIndex } ::= { pppChapPeerSecretsTable 1 } PppChapPeerSecretsEntry ::= SEQUENCE { pppChapPeerSecretsLink INTEGER, pppChapPeerSecretsIndex INTEGER, pppChapPeerSecretsName OCTET STRING, pppChapPeerSecretsSecret OCTET STRING, pppChapPeerSecretsStatus INTEGER } pppChapPeerSecretsLink OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the local PPP Link for which this Name/Secret pair will be evaluated as valid. A particular Name/Secret pair is valid only for the link(s) for which there is a pppChapPeerSecretsTable Frank J. Kastenholz Expires 2 Dec. 1992 [Page 49] Internet Draft PPP MIB May 1992 entry containing said Name/Secret pair. By convention, a value of 0 for this object indicates all links on the local PPP entity." ::= { pppChapPeerSecretsEntry 1 } pppChapPeerSecretsIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "A unique value for each Name/Secret pair that has been defined for use on this link. This allows multiple Name/Secret pairs to be defined for each link." ::= { pppChapPeerSecretsEntry 2 } pppChapPeerSecretsName OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "A Peer-Name which may attempt to connect over the link identified by pppChapPeerSecretsLink." ::= { pppChapPeerSecretsEntry 3 } pppChapPeerSecretsSecret OBJECT-TYPE SYNTAX OCTET STRING -- (SIZE(16)) when using MD5 ACCESS read-write STATUS mandatory DESCRIPTION "The Secret associated with the Peer-Name identified in pppChapPeerSecretsName." ::= { pppChapPeerSecretsEntry 4 } pppChapPeerSecretsStatus OBJECT-TYPE SYNTAX INTEGER { invalid(1) valid(2) } ACCESS read-write STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 50] Internet Draft PPP MIB May 1992 DESCRIPTION "Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the pppChapPeerSecretsTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppChapPeerSecretsStatus object." DEFVAL { valid } ::= { pppChapPeerSecretsEntry 5 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 51] Internet Draft PPP MIB May 1992 5.8. PPP PAP Group -- -- The PPP PAP Group. -- Implementation of this group is mandatory for all -- PPP implementations that support the PAP protocol. -- -- pppSecurityConfigProtocol takes the OBJECT IDENTIFIER -- pppPap to indicate that the Password -- Authentication Protocol is to be used. -- -- pppPap OBJECT IDENTIFIER ::= { pppSecurity 3 } pppPapSecretsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppPapSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Table containing the secret PAP parameters for the local PPP entity. As this table contains secret information, it is expected that access to this table be limited to those SNMP Party- Pairs for which a privacy protocol is in use for all SNMP messages that the parties exchange. This table contains the Peer-ID and Password that this PPP entity will advertise to the remote entity when sending PAP Authenticate Request packets. The table allows for multiple id/password pairs to be specified for a particular link by using the pppPapSecretIdIndex object." ::= { pppPap 1 } pppPapSecretsEntry OBJECT-TYPE SYNTAX PppPapSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Secret PAP information." INDEX { pppPapSecretsIndex, pppPapSecretsIdIndex } ::= { pppPapSecretsTable 1 } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 52] Internet Draft PPP MIB May 1992 PppPapSecretsEntry ::= SEQUENCE { pppPapSecretsIndex INTEGER, pppPapSecretsIdIndex INTEGER, pppPapSecretsId OCTET STRING, pppPapSecretsPassword OCTET STRING, pppPapSecretsStatus INTEGER } pppPapSecretsIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the local PPP Password Authentication Protocol Entity.If the value of this object is 0 then the ID/Password pair applies to all links." ::= { pppPapSecretsEntry 1 } pppPapSecretsIdIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-only STATUS mandatory DESCRIPTION "A unique value for each ID/Password pair that has been defined for use on this link. This allows multiple ID/Password pairs to be defined for each link. How the local entity selects which pair to use is a local implementation decision." ::= { pppPapSecretsEntry 2 } pppPapSecretsId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory Frank J. Kastenholz Expires 2 Dec. 1992 [Page 53] Internet Draft PPP MIB May 1992 DESCRIPTION "A Peer ID." ::= { pppPapSecretsEntry 3 } pppPapSecretsPassword OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The password to be associated with the Peer ID." ::= { pppPapSecretsEntry 4 } pppPapSecretsStatus OBJECT-TYPE SYNTAX INTEGER { invalid(1) valid(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the pppPapSecretsTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppPapSecretsStatus object." DEFVAL { valid } ::= { pppPapSecretsEntry 5 } pppPapPeerSecretsTable OBJECT-TYPE SYNTAX SEQUENCE OF PppPapPeerSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION Frank J. Kastenholz Expires 2 Dec. 1992 [Page 54] Internet Draft PPP MIB May 1992 "Table containing the secret PAP parameters that are expected of remotes that may attempt to authenticate themselves to the local PPP entity. As this table contains secret information, it is expected that access to this table be limited to those SNMP Party-Pairs for which a privacy protocol is in use for all SNMP messages that the parties exchange." ::= { pppPap 3 } pppPapPeerSecretsEntry OBJECT-TYPE SYNTAX PppPapPeerSecretsEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Secret remote PAP information for a particular remote ID/password and link." INDEX { pppPapPeerSecretsLink, pppPapPeerSecretsIndex } ::= { pppPapPeerSecretsTable 1 } PppPapPeerSecretsEntry ::= SEQUENCE { pppPapPeerSecretsLink INTEGER, pppPapPeerSecretsIndex INTEGER, pppPapPeerSecretsId OCTET STRING, pppPapPeerSecretsPassword OCTET STRING, pppPapPeerSecretsStatus INTEGER } pppPapPeerSecretsLink OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "The value of ifIndex that identifies the entry in the interface table that is associated with the local PPP Link for which this ID/Password pair will be evaluated as valid. A particular Frank J. Kastenholz Expires 2 Dec. 1992 [Page 55] Internet Draft PPP MIB May 1992 ID/Password pair is valid only for the link(s) for which there is a pppPapPeerSecretsTable entry containing said ID/Password pair. By convention, a value of 0 for this object indicates all links on the local PPP entity." ::= { pppPapPeerSecretsEntry 1 } pppPapPeerSecretsIndex OBJECT-TYPE SYNTAX INTEGER(0..2147483648) ACCESS read-write STATUS mandatory DESCRIPTION "A unique value for each ID/Password pair that has been defined for use on this link. This allows multiple ID/Password pairs to be defined for each link." ::= { pppPapPeerSecretsEntry 2 } pppPapPeerSecretsId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "A Peer-ID which may attempt to connect over the link identified by pppPapPeerSecretsLink." ::= { pppPapPeerSecretsEntry 3 } pppPapPeerSecretsPassword OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The Password associated with the Peer-ID identified in pppPapPeerSecretsId." ::= { pppPapPeerSecretsEntry 4 } pppPapPeerSecretsStatus OBJECT-TYPE SYNTAX INTEGER { invalid(1) valid(2) } Frank J. Kastenholz Expires 2 Dec. 1992 [Page 56] Internet Draft PPP MIB May 1992 ACCESS read-write STATUS mandatory DESCRIPTION "Setting this object to the value invalid(1) has the effect of invalidating the corresponding entry in the pppPapPeerSecretsTable. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant pppPapPeerSecretsStatus object." DEFVAL { valid } ::= { pppPapPeerSecretsEntry 5 } END Frank J. Kastenholz Expires 2 Dec. 1992 [Page 57] Internet Draft PPP MIB May 1992 5.9. PPP Tests The extensions to the interface table in [7] define a table through which the network manager can instruct the managed object to perform various tests of the interface. This is the ifExtnsTestTable. The PPP MIB defines one such test. 5.9.1. PPP Echo Test The PPP Echo Test is defined as pppEchoTest OBJECT IDENTIFIER ::= { pppTests 1 } Invoking this test causes a PPP Echo Packet to be sent on the line. ifExtnsTestResult returns success(2) if the echo response came back properly. It returns failed(7) if the response did not properly return. The definition of "proper" in this context is left to the discretion of the implementor. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 58] Internet Draft PPP MIB May 1992 6. Acknowledgements This document was produced by the PPP working group. In addition to the working group, the author wishes to thank the following individuals for their comments and contributions: Bill Simpson -- Daydreamer Glenn McGregor -- Merit Jesse Walker -- DEC Chris Gunner -- DEC Frank J. Kastenholz Expires 2 Dec. 1992 [Page 59] Internet Draft PPP MIB May 1992 7. References [1] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [2] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets - MIB-2, Internet Working Group Request for Comments 1213. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [3] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [5] Rose, M., and K. McCloghrie, Editors, Concise MIB Definitions, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [6] Rose, M., Editor, A Convention for Defining Traps for use with the SNMP, RFC 1215, Performance Systems International, March 1991. [7] K. McCloghrie, Extensions to the Generic-Interface MIB, RFC1229, Hughes LAN Systems, May 1991. [8] W. Simpson, The Point-to-Point Protocol for the Transmission of Multi-protocol Datagrams over Point-to- Point Links, RFC 1331, May 1992. [9] G. McGregor, The PPP Internet Protocol Control Protocol, RFC 1332, Merit, May 1992. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 60] Internet Draft PPP MIB May 1992 [10] F. Baker, Point-to-Point Protocol Extensions for Bridging, RFC1220, ACC, April 1991. [11] PPP Authentication Protocols, Work In Progress [12] W. Simpson, PPP Link Quality Monitoring, RFC 1333, May 1992. [13] New SNMP Administrative Model, Work In Progress. [14] SNMP Security Protocols, Work In Progress. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 61] Internet Draft PPP MIB May 1992 8. Security Considerations The PPP MIB affords the network operator the ability to configure and control the PPP links of a particular system, including the PPP authentication protocols. This represents a security risk. These risks are addressed in the following manners: (1) All variables which represent a significant security risk are placed in separate, optional, MIB Groups. As the MIB Group is the quantum of implementation within a MIB, the implementor of the MIB may elect not to implement these groups. (2) The implementor may choose to implement the variables which present a security risk so that they may not be written, i.e., the variables are READ-ONLY. This method still presents a security risk, and is not recommended, in that the variables, specifically the PPP Authentication Protocols' variables, may be easily read. (3) Using the new SNMP administrative framework[13,14], the operator can place the variables into MIB views which are protected in that the parties which have access to those MIB views use authentication and privacy protocols, or the operator may elect to make these views not accessible to any party. In order to facilitate this placement, all security-related variables are placed in separate MIB Tables. This eases the identification of the necessary MIB View Subtree. Frank J. Kastenholz Expires 2 Dec. 1992 [Page 62] Internet Draft PPP MIB May 1992 Table of Contents Status of this Memo .................................... 1 1 Abstract .............................................. 2 2 The Network Management Framework ...................... 3 3 Objects ............................................... 4 3.1 Format of Definitions ............................... 4 4 Overview .............................................. 5 4.1 Object Selection Criteria ........................... 5 4.2 Structure of the PPP ................................ 5 4.3 MIB Groups .......................................... 6 4.4 Relationship to Interface and Interface Extensions Groups ............................................. 8 5 Definitions ........................................... 9 5.1 PPP Link Group ...................................... 10 5.2 PPP LQR Group ....................................... 21 5.3 PPP LQR Extensions Group ............................ 27 5.4 PPP IP Group ........................................ 29 5.5 PPP Bridge Group .................................... 34 5.6 PPP Security Configuration Group .................... 41 5.7 PPP CHAP Group ...................................... 44 5.8 PPP PAP Group ....................................... 52 5.9 PPP Tests ........................................... 58 5.9.1 PPP Echo Test ..................................... 58 6 Acknowledgements ...................................... 59 7 References ............................................ 60 8 Security Considerations ............................... 62 Frank J. Kastenholz Expires 2 Dec. 1992 [Page 63] From ietf-ppp-request@ucdavis.ucdavis.edu Wed May 27 16:51:28 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04195; Wed, 27 May 92 16:43:42 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA18998; Wed, 27 May 92 16:20:11 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03252; Wed, 27 May 92 16:14:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA02960; Wed, 27 May 92 16:04:04 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-Brent-910926) id AA26114 to ietf-ppp@ucdavis.edu; Wed, 27 May 92 16:02:40 PDT Received: from yoyo.telebit.com by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA17784 to ietf-ppp@ucdavis.edu; Wed, 27 May 92 16:02:37 PDT Date: Wed, 27 May 92 16:02:37 PDT From: mlewis@napa.Telebit.COM (Mark S. Lewis) Message-Id: <9205272302.AA17784@napa.TELEBIT.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA06426; Wed, 27 May 92 16:03:19 PDT To: ietf-ppp@ucdavis.ucdavis.edu Subject: PPP-Athon participants A few have been asking which vendors have committed to participating in the upcoming PPP-Athon. Here is the list as of 5/27/92. There will be some observer there as well. VENDOR PARTICIPATE ---------------------- ----------- 3Com No Cayman Yes Centrum Communications Yes cisco Maybe DEC - UK Yes GE Medical Yes FTP Software Yes Livingston Maybe Morning Star Yes NAT Yes Network Systems Yes Novell Yes Proteon Maybe Shiva No Telebit Obviously Wellfleet Maybe Xylogics Yes It is not too late to get in on the fun. I am hoping some of the others will decide to come. The time is growing near, so let me know ASAP. I will provide more details. Date: June 1-5 Place: Sunnyvale, California (between San Francisco & San Jose) Start: Monday June 1 at 9:00 am ... Mark =========----------- Mark S. Lewis -----------========== inet: mlewis@telebit.com Telebit Corp. Telebit (408) 745-3232 uucp: uunet!telebit!mlewis Fax (408) 745-3810 From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 28 11:22:30 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA04817; Thu, 28 May 92 11:18:31 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA02176; Thu, 28 May 92 10:49:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03659; Thu, 28 May 92 10:40:53 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SAFFRON.ACC.COM by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA03399; Thu, 28 May 92 10:31:03 -0700 Received: by saffron.acc.com (4.1/SMI-4.1) id AA03042; Thu, 28 May 92 10:29:18 PDT Date: Thu, 28 May 92 10:29:18 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9205281729.AA03042@saffron.acc.com> To: kasten@clearpoint.com Subject: PPP MIB Cc: ietf-ppp@ucdavis.ucdavis.edu Frank: Thanks for your updated MIB. Steffen and I have a few comments. We had subsetted the previous MIB for implementation in our private branch. We are going to implement the entirety of this version in our private branch (with a view to changing to the real OID next year or the year after when the reviews are complete), with the following changes. We would suggest the same changes for the public MIB. - it looks to us like one cannot derive the state of the LCP FSM. We will add a variable PppState ::= INTEGER { initial (1), starting (2), closed (3), stopped (4), closing (5), stopping (6), reqSent (7), ackRcvd (8), ackSent (9), opened (10) } accPppLinkStatusState SYNTAX PppState ACCESS read-only STATUS mandatory DESCRIPTION "the state of the LCP state machine." - We would suggest that each CP or NCP have a variable of SYNTAX PppState. You have one now which is either "open" or "close" (shouldn't that be "closed"?) in the IP and Bridge tables (pppIpConfigOperStatus and pppBridgeConfigOperStatus). We will cannibalize those. - We will have to think through setting an interface variable to stop a protocol from using a PPP interface; that fits relatively nicely with unnumbered links, I suppose, but our approach in configuring our network layer protocols is to configure an ipAddrEntry (or its unnumbered equivalent, or its other-protocol equivalent) on the interface, not the interface under IP or whatever. - pppBridgeConfigOperStatus - uh, I think you might want to reread that description text... Fred ----- End Included Message ----- From ietf-ppp-request@ucdavis.ucdavis.edu Thu May 28 13:24:45 1992 Received: from aggie.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08250; Thu, 28 May 92 13:16:44 -0700 Received: from ucdavis.ucdavis.edu by aggie.ucdavis.edu (5.61/UCD2.04) id AA03416; Thu, 28 May 92 12:49:05 -0700 Received: by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA07113; Thu, 28 May 92 12:41:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from europa.clearpoint.com by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA06965; Thu, 28 May 92 12:34:28 -0700 Received: by europa.clearpoint.com (4.1/1.34) id AA12953; Thu, 28 May 92 15:25:49 EDT Date: Thu, 28 May 92 15:25:49 EDT From: kasten@europa.clearpoint.com (Frank Kastenholz) Message-Id: <9205281925.AA12953@europa.clearpoint.com> To: ietf-ppp@ucdavis.ucdavis.edu Subject: Re: PPP MIB Forwarding: Mail from 'MAILER-DAEMON (Mail Delivery Subsystem)' dated: Thu, 28 May 92 15:24:06 EDT Cc: fbaker@acc.com, steffen@acc.com fred thanks for the comments > - it looks to us like one cannot derive the state of the LCP FSM. > We will add a variable > > PppState ::= INTEGER { > initial (1), > starting (2), > closed (3), > stopped (4), > closing (5), > stopping (6), > reqSent (7), > ackRcvd (8), > ackSent (9), > opened (10) > } > > accPppLinkStatusState > SYNTAX PppState > ACCESS read-only > STATUS mandatory > DESCRIPTION > "the state of the LCP state machine." we considered doing this sort of thing, however at the san diego ietf meeting we decided to reduce things to an up/down indication. up/down gives the needed information. looking at the full fsm was realised to be primarily an issue for debugging bad implementations and the mib is meant for operational purposes, not debugging. generally, because of the fixed number of retries and timeouts in ppp, a proper implementation should transit quickly from closed to opened state and vice versa. anything that is sitting in any of the intermediate states is imagined to be a broken implementation. > - We would suggest that each CP or NCP have a variable of SYNTAX > PppState. You have one now which is either "open" or "close" > (shouldn't that be "closed"?) in the IP and Bridge tables > (pppIpConfigOperStatus and pppBridgeConfigOperStatus). We will > cannibalize those. see above > - pppBridgeConfigOperStatus - uh, I think you might want to reread > that description text... picky picky picky