From list-admin Tue Mar 1 13:16:24 1994 Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA20881 for ; Tue, 1 Mar 1994 13:16:23 -0500 Message-Id: <199403011816.NAA20881@merit.edu> Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 3863; Tue, 01 Mar 94 13:13:20 EST Date: Tue, 1 Mar 94 13:13:38 EST From: "Rich Bowen" To: fbaker@acc.com cc: ietf-ppp@merit.edu Subject: draft-ietf-pppext-for-bridging-03.txt Fred, I have incorporated all comments received since the last meeting into this draft -- I believe it's ready for a 'last call'. (Note to everyone: this draft is available on the usual ftp servers. You may not have received the notice since it was sent to the 'old' mailing list at ucdavis instead of to merit.) Regards, Rich - - - - - - - - - - - - - - - - - From list-admin Tue Mar 1 13:49:17 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA23516 for ; Tue, 1 Mar 1994 13:49:16 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB05344; Tue, 1 Mar 94 10:49:11 PST Message-Id: <9403011849.AB05344@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Mar 1994 10:49:03 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: draft-ietf-pppext-for-bridging-03.txt Cc: rich_bowen@vnet.IBM.COM >I have incorporated all comments received since the last meeting into >this draft -- I believe it's ready for a 'last call'. OK, guys & gals: last call. Speak now or... ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Tue Mar 1 15:40:06 1994 Received: from Shiva.COM (Shiva.COM [192.80.57.1]) by merit.edu (8.6.5/8.6.5) with SMTP id PAA04926 for ; Tue, 1 Mar 1994 15:39:27 -0500 From: Postmaster@marty.Shiva.COM Received: from marty ([140.248.208.151]) by Shiva.COM (1.34b) Tue, 1 Mar 94 15:39:16 EST Date: Tue, 1 Mar 94 15:29:33 EST Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt To: ietf-ppp@merit.edu X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >I still have a problem with the Added field in the Name-Projection >option in NBFCP. All other configuration options in LCP and other >NCPs (that I've read) return Configure-Ack on an option without >modifying the data that was sent. > >In my PPP implementation, rather than keep around the entire contents >of the last Request for each [LN]CP, I just make a checksum. Then, if >a get an Ack, I just compare the checksums. The NBFCP would require >me to either: (a) keep all outstanding Requests, (b) re-derive what I >think I sent, or (c) implicitly trust the Ack to match my Request. > >Unfortunately, I don't have a better suggestion for the >Name-Projection option. > I have a suggestion for the names projection. The peer sends its NetBIOS names (16 bytes of name plus N bytes of status, including whether it is a unique or group name). If the other side detects a conflict immediately, it will Nak this option and "suggest" a list of names that does not include the name(s) in conflict. If the other side does not detect a conflict immediately, it Acks this option. If it doesn't know what the heck we are talking about, it sends a Rej. The other side then attempts to detect duplicate names through whatever means it can (such as by doing a proxy Add Name). If there is a conflict detected at this time, it sends an NBFCP Terminate-Request indicating that a name conflict was detected. If the peer that is using the name wants to, it can renegotiate. The benefits of this method are: -- A normal NBFCP negotiation, in which there are no name conflicts, does not take any extra time. Since the other side is not checking the names during negotiation, there is no unnecessary delay. -- The peers can still decide to proceed with a connection if some of the names are in conflict. -- The purity of the PPP Req/Ack/Nak/Rej model is not sullied. The drawbacks of this method are: -- Going to be pointed out to me momentarily. - - - - - - - - - - - - - - - - - From list-admin Tue Mar 1 17:15:19 1994 Received: from gordius.gordian.com (gordius.gordian.com [192.73.220.81]) by merit.edu (8.6.5/8.6.5) with ESMTP id RAA13034 for ; Tue, 1 Mar 1994 17:15:17 -0500 Received: from eris.gordian.com (eris.gordian.com [192.73.220.121]) by gordius.gordian.com (8.6.5/8.6.5) with SMTP id OAA04713 for ; Tue, 1 Mar 1994 14:14:45 -0800 Received: by eris.gordian.com (AIX 3.2/UCB 5.64/4.03) id AA33143; Tue, 1 Mar 1994 14:14:45 -0800 Received: from BatMail.robin.v2.13.CUILIB.3.45.SNAP.NOT.LINKED.eris.gordian.com.rs.aix31 via MS.5.6.eris.gordian.com.rs_aix31; Tue, 1 Mar 1994 14:14:44 -0800 (PST) Message-Id: Date: Tue, 1 Mar 1994 14:14:44 -0800 (PST) From: Jay Laefer To: ietf-ppp@merit.edu Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt In-Reply-To: References: Postmaster@marty.Shiva.COM writes: > I have a suggestion for the names projection. The peer sends its NetBIOS > names (16 bytes of name plus N bytes of status, including whether it is a uniq\ > ue > or group name). As was already pointed out, my complaints about the NBFCP draft were based on a misreading of the text. I have no objection to the current draft. -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From list-admin Tue Mar 1 17:27:34 1994 Received: from netmail2.microsoft.com (netmail2.microsoft.com [131.107.1.13]) by merit.edu (8.6.5/8.6.5) with SMTP id RAA13761 for ; Tue, 1 Mar 1994 17:27:33 -0500 Received: by netmail2.microsoft.com (5.65/25-eef) id AA18132; Tue, 1 Mar 94 14:28:30 -0800 Message-Id: <9403012228.AA18132@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 01 Mar 94 14:28:30 PST X-Msmail-Message-Id: 444F2610 X-Msmail-Conversation-Id: 444F2610 From: Thomas Dimitri To: ietf-ppp@merit.edu Date: Tue, 1 Mar 94 14:21:25 TZ Subject: Re: draft-ietf-pppext-netbios-fcp-04.txt Please see my comments below... ---------- | From: | | >I still have a problem with the Added field in the Name-Projection | >option in NBFCP. All other configuration options in LCP and other | >NCPs (that I've read) return Configure-Ack on an option without | >modifying the data that was sent. | > | >In my PPP implementation, rather than keep around the entire contents | >of the last Request for each [LN]CP, I just make a checksum. Then, if | >a get an Ack, I just compare the checksums. The NBFCP would require | >me to either: (a) keep all outstanding Requests, (b) re-derive what I | >think I sent, or (c) implicitly trust the Ack to match my Request. | > | >Unfortunately, I don't have a better suggestion for the | >Name-Projection option. | > I do not know why the above email was included. It has already been pointed out that this is not true. That Configure-Ack matches the Request. This change was made quite some time ago. | I have a suggestion for the names projection. The peer sends its NetBIOS | names (16 bytes of name plus N bytes of status, including whether it is a unique | or group name). | | If the other side detects a conflict immediately, it will Nak this option and | "suggest" a list of names that does not include the name(s) in conflict. If the | other side does not detect a conflict immediately, it Acks this option. If it | doesn't know what the heck we are talking about, it sends a Rej. | | The other side then attempts to detect duplicate names through whatever | means it can (such as by doing a proxy Add Name). If there is a conflict | detected at this time, it sends an NBFCP Terminate-Request indicating that a | name conflict was detected. If the peer that is using the name wants to, it can | renegotiate. | | The benefits of this method are: | | -- A normal NBFCP negotiation, in which there are no name conflicts, | does not take any extra time. Since the other side is not checking | the names during negotiation, there is no unnecessary delay. The current draft does this as well. | -- The peers can still decide to proceed with a connection if some | of the names are in conflict. The current draft does this as well. | -- The purity of the PPP Req/Ack/Nak/Rej model is not sullied. The current draft differs *only* from LCP in that the Configure-Nak specifies which names can be added and which ones can't. Thus, instead of directly suggesting a Configure-Request, it implies one. However, the Configure-Request can easily formed from the Configure-Nak so although slightly sullied, I believe it is acceptable and discussion of this point on this alias led me to believe this was the case. The reason why this was done was so that the peer could find out why any NetBIOS names could not be added. This information is quite important and was decidely conveyed in the Configure-Nak. I would be against any proposal that did not convey this infomation. However, I think the proposal above is even more sullied. It suggests that a Configure-Nak be Ack'd! I do not think this is acceptable. --Thomas - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 10:47:39 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA17516 for ; Wed, 2 Mar 1994 10:47:39 -0500 Received: from tri-flow.ftp.com by ftp.com ; Wed, 2 Mar 1994 10:48:03 -0500 Received: from stev.d-cell.ftp.com by tri-flow.ftp.com.ftp.com (5.0/SMI-SVR4) id AA00626; Tue, 1 Mar 94 18:24:19 EST Date: Tue, 1 Mar 94 18:24:19 EST Message-Id: <9403012324.AA00626@tri-flow.ftp.com.ftp.com> To: ietf-ppp@merit.edu Subject: PLEASE NOTE From: stev@tri-flow.ftp.com (stev knowles) Sender: stev@tri-flow.ftp.com Repository: tri-flow.ftp.com, [message accepted at Tue Mar 1 18:24:14 1994] Originating-Client: d-cell.ftp.com Content-Length: 0 i have been slow in getting the SONET and ISDN PPP rfc's out the door. at this point, i am now in a mode of awaiting notification about implementations. the last call does not seem to have generated any, and the mail i sent to the mailing list does not either. i dont feel that it is in our community's best interest to put somthing into the standards track that does not have more than one implementation. you assistance would be appreciated. if i dont hear from someone with details by 11mar94, i will assume that there has been no implementation experience, and return the drafts to the WG for their decision on what to do with the documents. your options woudl include Informational and Experimental RFCs. your assistance in this is appreciated. - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 11:10:41 1994 Received: from vnet.IBM.COM (vnet.ibm.com [192.239.48.4]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA19669 for ; Wed, 2 Mar 1994 11:10:40 -0500 Message-Id: <199403021610.LAA19669@merit.edu> Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 1930; Wed, 02 Mar 94 11:07:37 EST Date: Wed, 2 Mar 94 11:09:18 EST From: "Rich Bowen" To: glenn@lloyd.com cc: ietf-ppp@merit.edu Subject: draft-ietf-pppext-for-bridging-03.txt >section 5.4 Tinygram-Compression > > A Configure-NAK MUST NOT be sent in response to a Configure- > Request that includes this option. > >I have some parse errors with this. On first reading, it indicates to me that >no option may be NAKed if a configure requestion contains the tinygram >compression option. If I squint, I can parse it to mean that the >tinygram option itself, can't be NAKed. Maybe some parenthesis... I agree that the statement is ambiguous. How about this: This option MUST NOT be included in a Configure-Nak if it has been received in a Configure-Request. This option MAY be included in a Configure-Nak in order to prompt the peer to send the option in its next Configure-Request. >section 5.6 MAC-Address > >I wonder why an Conf-ACK val 00-00-00-00-00-00 couldn't be used to indicate >no assigment, rather than a Conf-REJ. This was the style used in IPCP. It seems to me that either would work equally well. It probably just didn't occur to us at the time that this option was proposed. If you know of a problem with using the Conf-Rej, let me know. >And as a question, rather than a request for change.... > >How did the number 2 get assigned for boolean value false? >This is quite different from the style used for LCP boolean >options. I could see zero easily enough. (I think that it would have >simplified a number of things in my LCP implementation to have a value >associated with each option). I didn't work on the first version of this document and don't know the history of that choice but I suspect that it was modeled after SNMP MIBs, which typically use 1 and 2 for boolean values. Regards, Rich ------------------------------- Referenced Note --------------------------- Received: from lloyd.com by vnet.IBM.COM (IBM VM SMTP V2R2) with TCP; Tue, 01 Mar 94 19:34:59 EST Received: by lloyd.com (Smail3.1.28.1 #2) id m0pbevy-000ERwC; Tue, 1 Mar 94 16:37 PST Message-Id: From: "Glenn McGregor" To: fbaker@acc.com (Fred Baker) cc: rich_bowen@vnet.ibm.com Subject: Re: draft-ietf-pppext-for-bridging-03.txt In-reply-to: Your message of "Tue, 01 Mar 1994 10:49:03 PST." <9403011849.AB05344@fennel.acc.com> Date: Tue, 01 Mar 1994 16:36:49 -0800 Sender: glenn@harry.lloyd.com >>I have incorporated all comments received since the last meeting into >>this draft -- I believe it's ready for a 'last call'. > >OK, guys & gals: last call. Speak now or... > >============================================================================= >Fred Baker (fbaker@acc.com) >Advanced Computer Communications > > Hi. I've just gotten around to looking at the bridging draft. (Amazing what having to implement BCP will do)! Here's what I'ved noticed... section 5.4 Tinygram-Compression A Configure-NAK MUST NOT be sent in response to a Configure- Request that includes this option. I have some parse errors with this. On first reading, it indicates to me that no option may be NAKed if a configure requestion contains the tinygram compression option. If I squint, I can parse it to mean that the tinygram option itself, can't be NAKed. Maybe some parenthesis... section 5.6 MAC-Address I wonder why an Conf-ACK val 00-00-00-00-00-00 couldn't be used to indicate no assigment, rather than a Conf-REJ. This was the style used in IPCP. ----- And as a question, rather than a request for change.... How did the number 2 get assigned for boolean value false? This is quite different from the style used for LCP boolean options. I could see zero easily enough. (I think that it would have simplified a number of things in my LCP implementation to have a value associated with each option). ------ All in all, I think that it is very well writen. The background sections were particularly useful to me, as I have nearly no bridging experience. Glenn McGregor Lloyd Internetworking glenn@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Cameron Park, CA 95682 (916) 676-3442 - fax - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 13:20:43 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA29402 for ; Wed, 2 Mar 1994 13:20:40 -0500 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA21479; Wed, 2 Mar 94 10:20:25 PST Message-Id: <9403021820.AA21479@fennel.acc.com> X-Sender: fbaker@fennel.acc.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Mar 1994 10:20:18 -0800 To: stev@tri-flow.ftp.com From: fbaker@acc.com (Fred Baker) Subject: Re: PLEASE NOTE Cc: ietf-ppp@merit.edu At 6:24 PM 3/1/1994 -0500, stev knowles wrote: >i have been slow in getting the SONET and ISDN PPP rfc's out the >door. at this point, i am now in a mode of awaiting notification >about implementations. the last call does not seem to have generated >any, and the mail i sent to the mailing list does not either. we implement ppp/isdn; it is deployed ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 14:47:01 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA07320 for ; Wed, 2 Mar 1994 14:47:00 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA10129; Wed, 2 Mar 94 11:46:54 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA01904; Wed, 2 Mar 94 12:46:14 -0700 Date: Wed, 2 Mar 94 12:46:14 -0700 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9403021946.AA01904@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: speaking of drafts Speaking of progress ... What's happening to the CCP draft? Was it agreed that it should say something about a different protocol number for per-link compression beneath multilink? If not, shouldn't it be forwarded or something? What's happening to the MCP draft? The last public controversy I recall concerned link or bundle ID's. Is the MCP draft awaiting text for ID's? Or should it be forwarded or something? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 14:58:45 1994 Received: from digibd.com (digibd.digibd.com [192.83.159.205]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA08455 for ; Wed, 2 Mar 1994 14:58:38 -0500 Received: by digibd.com (5.65/DBI-1.19) id AA03468; Wed, 2 Mar 94 13:56:09 -0600 From: tomc@digibd.com (Tom Coradetti) Message-Id: <9403021956.AA03468@digibd.com> Subject: Re: PLEASE NOTE To: stev@tri-flow.ftp.com (stev knowles) Date: Wed, 2 Mar 1994 13:56:09 -0600 (CST) Cc: ietf-ppp@merit.edu In-Reply-To: <9403012324.AA00626@tri-flow.ftp.com.ftp.com> from "stev knowles" at Mar 1, 94 06:24:19 pm X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1174 > > i have been slow in getting the SONET and ISDN PPP rfc's out the > door. at this point, i am now in a mode of awaiting notification > about implementations. the last call does not seem to have generated > any, and the mail i sent to the mailing list does not either. > > i dont feel that it is in our community's best interest to put > somthing into the standards track that does not have more than one > implementation. you assistance would be appreciated. > > if i dont hear from someone with details by 11mar94, i will assume > that there has been no implementation experience, and return the > drafts to the WG for their decision on what to do with the documents. > your options woudl include Informational and Experimental RFCs. > > > your assistance in this is appreciated. > > DigiBoard has implemented PPP over ISDN and successfully exchanged LCP, and NCP frames with products from at least two other vendors, namely cisco and ACC. I also think Network Express has tested with our implementation to that extent. Although the DigiBoard implementation is not released, it appears to demonstrate implementation of the subject of the PPP over ISDN RFC. tc - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 14:44:07 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA07024 for ; Wed, 2 Mar 1994 14:44:06 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA09623; Wed, 2 Mar 94 11:44:01 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA01879; Wed, 2 Mar 94 12:43:23 -0700 Date: Wed, 2 Mar 94 12:43:23 -0700 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9403021943.AA01879@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: re: PLEASE NOTE > From: stev@tri-flow.ftp.com (stev knowles) > > i have been slow in getting the SONET and ISDN PPP rfc's out the > door. at this point, i am now in a mode of awaiting notification > about implementations. the last call does not seem to have generated > any, and the mail i sent to the mailing list does not either. > > i dont feel that it is in our community's best interest to put > somthing into the standards track that does not have more than one > implementation. you assistance would be appreciated. > > if i dont hear from someone with details by 11mar94, i will assume > that there has been no implementation experience, and return the > drafts to the WG for their decision on what to do with the documents. > your options woudl include Informational and Experimental RFCs. > > your assistance in this is appreciated. What kinds of reports of what sorts of implementation do you want? I know of an implemenation of the PPP over ISDN draft, but it hasn't been tested against others. Except for some oddities when running CCP, it works fine. Barring really strange and (I trust) unlikely actions from the various standards and regulatory bureaucracies, it will ship realsoonnow. I'm hoping for some private interoperability testing with other implementations any day now, and so I think there are several implementations at least as far along. Does it make sense to take about the SONET and ISDN PPP rfc's in the same breath, implying they are equally likely to be implemented and likely to have similar numbers of installations this year? I don't. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 18:48:37 1994 Received: from qualcomm.com (qualcomm.com [129.46.62.22]) by merit.edu (8.6.5/8.6.5) with ESMTP id SAA27201 for ; Wed, 2 Mar 1994 18:48:36 -0500 Received: from Bill.Simpson.QualComm.com (bill.simpson.qualcomm.com [129.46.36.36]) by qualcomm.com (8.6.6.Beta9/QC-main-2.3) via SMTP; id PAA26025 Wed, 2 Mar 1994 15:47:38 -0800 for Date: Wed, 2 Mar 94 14:42:47 PST From: "William Allen Simpson" Message-ID: <1208.bill.simpson@morningstar.com> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: dataencap-00 > From: Thomas Dimitri > I think I like "other multiprocotol encapsulation" best though since > it implies no favoritism. > Sounds good to me. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Wed Mar 2 18:48:42 1994 Received: from qualcomm.com (qualcomm.com [129.46.62.22]) by merit.edu (8.6.5/8.6.5) with ESMTP id SAA27205 for ; Wed, 2 Mar 1994 18:48:42 -0500 Received: from Bill.Simpson.QualComm.com (bill.simpson.qualcomm.com [129.46.36.36]) by qualcomm.com (8.6.6.Beta9/QC-main-2.3) via SMTP; id PAA26036 Wed, 2 Mar 1994 15:47:45 -0800 for Date: Wed, 2 Mar 94 14:44:30 PST From: "William Allen Simpson" Message-ID: <1209.bill.simpson@morningstar.com> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: dataencap-00 > From: jmh@anubis.network.com (Joel Halpern) > I was trying to keep it general, so we could use it as a tool in our > toolkit in the future, when this same type of dispute arises again. > What do other people think? I think that we should give only Frame-Relay as an example. Other things that use this later should simply point to this document. Including others that clearly don't apply (SMDS and ATM) doesn't make it "general". > (In reference to ATM Bill says it does not apply since ATM has no > NLPID use. Aside from the fact that ATM does have a frame-relay > compatibility mode which uses NLPIDs, the document never talks > about NLPIDs. They are not a distinguishing characteristic.) > ATM has a compatibility mode for everything under the sun. That doesn't make ATM an HDLC variant which could use PPP Protocol numbers. The appropriate references should appear in the respective foo/ATM documents. > I do not want to try to provide a "exhaustive" list, since then it will > have to be updated any time a "relevant" option is created. On the > other hand one needs enough of a sample to warn implementors. > The list needs to include every known problem. As we go to draft and full standards, the list has to be updated. Let's just do this like all other RFCs, eh? Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Thu Mar 3 03:50:39 1994 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.5/8.6.5) with SMTP id DAA02010 for ; Thu, 3 Mar 1994 03:50:37 -0500 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <19306-0@relay1.pipex.net>; Thu, 3 Mar 1994 08:50:21 +0000 Received: by widow.spider.co.uk; Thu, 3 Mar 94 09:00:12 GMT From: Gerry Meyer Date: Thu, 3 Mar 94 08:58:51 GMT Message-Id: <25702.9403030858@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Thu, 3 Mar 94 08:58:51 GMT To: stev@tri-flow.ftp.com Subject: PPP & ISDN Cc: ietf-ppp@merit.edu >i have been slow in getting the SONET and ISDN PPP rfc's out the >door. at this point, i am now in a mode of awaiting notification >about implementations. the last call does not seem to have generated >any, and the mail i sent to the mailing list does not either. Spider has been shipping PPP/ISDN for over a year. Gerry - - - - - - - - - - - - - - - - - From list-admin Thu Mar 3 04:21:51 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by merit.edu (8.6.5/8.6.5) with SMTP id EAA03884 for ; Thu, 3 Mar 1994 04:21:51 -0500 Received: from lager.cisco.com by hubbub.cisco.com with SMTP id AA20578 (8.6.4/IDA-1.5 for ietf-ppp@merit.edu); Thu, 3 Mar 1994 01:21:08 -0800 Message-Id: <199403030921.AA20578@hubbub.cisco.com> To: stev@tri-flow.ftp.com Cc: ietf-ppp@merit.edu Subject: Re: PPP & ISDN Date: Thu, 03 Mar 94 01:21:08 PST From: Jim Forster Cisco has been shipping PPP over ISDN in our ISDN routers for over a year. Besides the already mentioned interoperability, we also work with Sun (OK, they only do PAP, we only do CHAP, bfd). -- Jim - - - - - - - - - - - - - - - - - From list-admin Thu Mar 3 18:35:10 1994 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA06143 for ; Thu, 3 Mar 1994 18:35:10 -0500 Received: from lager.cisco.com by hubbub.cisco.com with SMTP id AA26515 (8.6.4/IDA-1.5 for ietf-ppp@merit.edu); Thu, 3 Mar 1994 15:34:32 -0800 Message-Id: <199403032334.AA26515@hubbub.cisco.com> To: stev@mailserv-D.ftp.com Cc: ietf-ppp@merit.edu Subject: Re: PPP over ISDN Date: Thu, 03 Mar 94 15:34:27 PST From: Jim Forster Sorry to send 2 messages when 1 should have been enough...I wasn't close enough to our PPP (guess that means I should have kept my mouth shut). We now do PAP as well as CHAP. -- Jim >Cisco has been shipping PPP over ISDN in our ISDN routers for over a year. >Besides the already mentioned interoperability, we also work with Sun (OK, >they only do PAP, we only do CHAP, bfd). - - - - - - - - - - - - - - - - - From list-admin Fri Mar 4 11:14:45 1994 Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA16404 for ; Fri, 4 Mar 1994 11:14:41 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA20170; Fri, 4 Mar 94 10:17:55 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA07761; Fri, 4 Mar 94 10:14:33 CST Date: Fri, 4 Mar 94 10:14:33 CST From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9403041614.AA07761@anubis.network.com> To: ietf-ppp@merit.edu Subject: dataencap-00 After reading the comments, I will change the document name, and appropriate internal reverences, from data encapsulation to multiprotocol encapsulation. With regard to teh use of the term "Native", I think "other" is to broad. Would people accept "Nominal"? This was suggested in private e-mail, and seems like it might be sufficiently lacking in "connotations" to be an acceptable compromise. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation - - - - - - - - - - - - - - - - - From list-admin Mon Mar 7 11:57:27 1994 Received: from heifetz.msen.com (heifetz.msen.com [148.59.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA04574 for ; Mon, 7 Mar 1994 11:57:26 -0500 Received: from anton.UUCP by heifetz.msen.com with UUCP (Smail3.1.28.1 #12) id m0pdiPR-000ZZdC; Mon, 7 Mar 94 11:44 EST Received: from smtpgtwy.nei.com (internet-mail.nei.com) by nei.comp (5.0/SMI-SVR4) id AA00473; Mon, 7 Mar 94 11:39:40 EST Received: from ccMail by smtpgtwy.nei.com id AA763069327 Mon, 07 Mar 94 11:42:07 EST Date: Mon, 07 Mar 94 11:42:07 EST From: itoh@nei.com Message-Id: <9402077630.AA763069327@smtpgtwy.nei.com> To: stev@mailserv-D.ftp.com (stev knowles), tomc@digibd.com (Tom Coradetti) Cc: ietf-ppp@merit.edu Subject: Re[2]: PLEASE NOTE content-length: 711 > DigiBoard has implemented PPP over ISDN and successfully exchanged > LCP, and NCP frames with products from at least two other vendors, > namely cisco and ACC. I also think Network Express has tested with our > implementation to that extent. Although the DigiBoard implementation is not > released, it appears to demonstrate implementation of the subject of > the PPP over ISDN RFC. > > tc We, Network Express, have successfully communicated with DigiBoard using PPP (LCP, IPCP and PAP) over ISDN. We have also tested with Sun successfully and are testing with SGI and more other vendors. Keisuke Ito/Network Express 4251 Plymouth Rd. Ann Arbor, MI 48105 Tel: (313) 761-5051 Fax: (313) 995-1114 - - - - - - - - - - - - - - - - - From list-admin Mon Mar 7 16:32:25 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA01797 for ; Mon, 7 Mar 1994 16:32:25 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 7 Mar 1994 16:32:24 -0500 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA27073; Mon, 7 Mar 94 16:31:51 EST Date: Mon, 7 Mar 94 16:31:51 EST Message-Id: <9403072131.AA27073@mailserv-D.ftp.com> To: ietf-ppp@merit.edu Subject: one more time . . . . From: stev@ftp.com (stev knowles) Sender: stev@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Mar 7 16:31:10 1994] Originating-Client: d-cell.ftp.com Content-Length: 451 in the process of moving dave rand's "reliable" ID into the standards track, i need to check for current implementations. from my reading of the archives, there appears to have been some interest, but i woudl, as always, like a bit of private correpsondance to back up my reading of the archives. if you have implemented this technology (PPP over LAPB) please drop me a quick note, public disclosure is not necessary. . . . thanx for the help. - - - - - - - - - - - - - - - - - From list-admin Fri Mar 11 00:52:30 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.5/8.6.5) with SMTP id AAA22338 for ; Fri, 11 Mar 1994 00:52:13 -0500 From: Allen_Rochkind@3Mail.3Com.COM Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwgsl14771; Fri, 11 Mar 94 00:51:08 -0500 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA17178; Thu, 10 Mar 94 16:22:51 PST Received: by gw.3Com.COM id AA20746 (5.65c/IDA-1.4.4 for ietf-ppp@Merit.edu); Thu, 10 Mar 1994 16:22:18 -0800 Date: Thu, 10 Mar 94 16:25 PST Subject: Comments on the 6.5 Multilink Draft To: ietf-ppp@merit.edu Cc: Allen_Rochkind@3Mail.3Com.COM Message-Id: <940310.162529@3Mail.3Com.COM> 1. Section 1.2 says that multilink is selected for this link as part of some bundle via LCP option negotiation. Section 5.1 "Configuration Option Types" indicates that the Maximum Receive Reconstructed Unit is the only new configuration option introduced by multilink. However, the text does not say explicitly what option is the option that indeed selects multilink for the link. I am inferring from the text that the presence or absence of this new configuration option is what selects or not multilink for the link. Is this correct? Shouldn't there be some text that states explicitly the option that selects multilink? Speaking of the "Configuration Option Types", it appears that the Maximum Receive Reconstructed Unit size could in principle vary from one link to the next within the same bundle. Although such would be a stupid implementation, why not have a sentence explicitly stating that a common value for a bundle must be set in each LCP's maximum received reconstructed unit option. This in reality is a minor flaw in the architectural compromise of not explicitly negotiating a virtual LCP over a bundle since this parameter applies to the bundle as a whole and not to each individual consituent link. If we were to add other multilevel configuration options on a link by link basis, we would probably face the same redundancy issue. 2. From some of the emails that have been received recently, I get the impression that the group is not agreed on using PPP authentication identification mechanisms as a means to identify the bundle. However, assuming that we use authentication IDs to identify the bundle, I believe a sentence should be added that "...all links of the same bundle must be authenticated using the same authentication identifier". 3. By the way a section should be added that PROCEDURALLY summarizes the steps required from LCP negotiation, through authentication to get a link to start or join a bundle. That way the reader can get an overview of how all the pieces fit together to get a link to join a bundle. I had a hard time seeing the forest through the trees. The only thing which made it clear to me how it all worked is that I have been following this discussion group and I know the context. Even reading some recent emails in this discussion group, there were people still talking about MCP negotiation (the previous way to do things), and I thought we abandoned that in favor of LCP configuration options. So do we all really understand how we get a link to join a bundle by reading the current text? How about those implementors who have not participated in this group's discussions and read the future RFC? So I think the procedural overview will do us all a great service. 4. The draft also equivocates between "Only one multilink 'bundle' may exist between peer systems" in Section 1.2 and the next to last paragraph of Section 7, "Although explicitly forbidden above, if there were several ....". I got the impression that the latter section gives an escape clause from the provision of Section 1.2. So do we allow it or not? Also I do not understand why we have to have the restriction of Section 1.2. - - - - - - - - - - - - - - - - - From list-admin Fri Mar 11 11:47:09 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA06951 for ; Fri, 11 Mar 1994 11:47:09 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04655; 11 Mar 94 11:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-compression-04.txt Date: Fri, 11 Mar 94 11:27:05 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403111127.aa04655@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP Compression Control Protocol (CCP) Author(s) : D. Rand Filename : draft-ietf-pppext-compression-04.txt Pages : 12 Date : 03/10/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data compression over PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-compression-04.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-compression-04.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940310095617.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-compression-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-compression-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940310095617.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Fri Mar 11 12:28:47 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA10280 for ; Fri, 11 Mar 1994 12:28:47 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04992; 11 Mar 94 11:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-multilink-07.txt Date: Fri, 11 Mar 94 11:36:04 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403111136.aa04992@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The PPP Multilink Protocol (MP) Author(s) : K. Sklower, B. Lloyd, G. McGregor, D. Carr Filename : draft-ietf-pppext-multilink-07.txt Pages : 15 Date : 03/10/1994 This document proposes a method for splitting and recombining datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two system, including async links. This is accomplished by means of new PPP options and protocols. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-multilink-07.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-multilink-07.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940310145844.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-multilink-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-multilink-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940310145844.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Fri Mar 11 13:26:29 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA14657 for ; Fri, 11 Mar 1994 13:26:20 -0500 From: Allen_Rochkind@3Mail.3Com.COM Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwguj05921; Fri, 11 Mar 94 13:25:25 -0500 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA17825; Fri, 11 Mar 94 10:25:38 PST Received: by gw.3Com.COM id AA06466 (5.65c/IDA-1.4.4 for ietf-ppp@Merit.edu); Fri, 11 Mar 1994 10:25:04 -0800 Date: Fri, 11 Mar 94 10:25 PST Subject: Comments on the 6.5 Multilink Draft To: ietf-ppp@merit.edu Message-Id: <940311.102819@3Mail.3Com.COM> Forwarded: Message from Allen Rochkind:HQDev:3Com of 3-10-94 I am resending because I received a non-delivery notification and I'm not sure who on the list received this. Sorry for any redundant messages. Also just now received notice that there is a 7.0 draft. However, the comments below are responding to the 6.5 draft. --------------------- Forwarded Message Body --------------------- Date: 3-10-94 4:25pm From: Allen Rochkind:HQDev:3Com To: {ietf-ppp@Merit.edu}:ugate cc: Allen Rochkind:HQDev:3Com Subj: Comments on the 6.5 Multilink Draft ------------------------------------------------------------------ 1. Section 1.2 says that multilink is selected for this link as part of some bundle via LCP option negotiation. Section 5.1 "Configuration Option Types" indicates that the Maximum Receive Reconstructed Unit is the only new configuration option introduced by multilink. However, the text does not say explicitly what option is the option that indeed selects multilink for the link. I am inferring from the text that the presence or absence of this new configuration option is what selects or not multilink for the link. Is this correct? Shouldn't there be some text that states explicitly the option that selects multilink? Speaking of the "Configuration Option Types", it appears that the Maximum Receive Reconstructed Unit size could in principle vary from one link to the next within the same bundle. Although such would be a stupid implementation, why not have a sentence explicitly stating that a common value for a bundle must be set in each LCP's maximum received reconstructed unit option. This in reality is a minor flaw in the architectural compromise of not explicitly negotiating a virtual LCP over a bundle since this parameter applies to the bundle as a whole and not to each individual consituent link. If we were to add other multilevel configuration options on a link by link basis, we would probably face the same redundancy issue. 2. From some of the emails that have been received recently, I get the impression that the group is not agreed on using PPP authentication identification mechanisms as a means to identify the bundle. However, assuming that we use authentication IDs to identify the bundle, I believe a sentence should be added that "...all links of the same bundle must be authenticated using the same authentication identifier". 3. By the way a section should be added that PROCEDURALLY summarizes the steps required from LCP negotiation, through authentication to get a link to start or join a bundle. That way the reader can get an overview of how all the pieces fit together to get a link to join a bundle. I had a hard time seeing the forest through the trees. The only thing which made it clear to me how it all worked is that I have been following this discussion group and I know the context. Even reading some recent emails in this discussion group, there were people still talking about MCP negotiation (the previous way to do things), and I thought we abandoned that in favor of LCP configuration options. So do we all really understand how we get a link to join a bundle by reading the current text? How about those implementors who have not participated in this group's discussions and read the future RFC? So I think the procedural overview will do us all a great service. 4. The draft also equivocates between "Only one multilink 'bundle' may exist between peer systems" in Section 1.2 and the next to last paragraph of Section 7, "Although explicitly forbidden above, if there were several ....". I got the impression that the latter section gives an escape clause from the provision of Section 1.2. So do we allow it or not? Also I do not understand why we have to have the restriction of Section 1.2. - - - - - - - - - - - - - - - - - From list-admin Fri Mar 11 18:46:46 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA10330 for ; Fri, 11 Mar 1994 18:46:46 -0500 From: Allen_Rochkind@3Mail.3Com.COM Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwgvf02745; Fri, 11 Mar 94 18:45:41 -0500 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA18308; Fri, 11 Mar 94 15:45:57 PST Received: by gw.3Com.COM id AA01984 (5.65c/IDA-1.4.4 for ietf-ppp@Merit.edu); Fri, 11 Mar 1994 15:45:23 -0800 Date: Fri, 11 Mar 94 15:50 PST Subject: Re: Comments on the 6.5 Multilink Draft To: ietf-ppp@merit.edu Cc: Allen_Rochkind@3Mail.3Com.COM Message-Id: <940311.154838@3Mail.3Com.COM> --------------------- Forwarded Message Body --------------------- Date: 3-11-94 11:57am From: {brian@lloyd.com}:ugate:3Com To: Allen Rochkind:hq:3Com Subj: Re: Comments on the 6.5 Multilink Draft ----------------------------------------------------------------- Original header follows: Received: from gatekeeper.3Com.COM by gw.3Com.COM with SMTP id AA09811 (5.65c/IDA-1.4.4 for ); Fri, 11 Mar 1994 11:04:44 -0800 Return-Path: Received: from lloyd.com (harry.lloyd.com) by gatekeeper.3Com.COM with SMTP id AA17564 (5.65c/IDA-1.4.4-910725 for ); Fri, 11 Mar 1994 11:04:35 -0800 Received: from [192.216.176.104] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0pfCVK-000ERwC; Fri, 11 Mar 94 11:04 PST Message-Id: Date: Fri, 11 Mar 94 11:04 PST X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Allen_Rochkind@3mail.3com.com From: brian@lloyd.com (Brian Lloyd) Subject: Re: Comments on the 6.5 Multilink Draft ----------------------------------------------------------------- >1. Section 1.2 says that multilink is selected for this link as part of > some bundle via LCP option negotiation. Section 5.1 "Configuration > Option Types" indicates that the Maximum Receive Reconstructed Unit > is the only new configuration option introduced by multilink. > However, the text does not say explicitly what option is the option > that indeed selects multilink for the link. I am inferring from the > text that the presence or absence of this new configuration option > is what selects or not multilink for the link. Is this correct? >>Yes. So my comment is that the text should be more explicit that this is the fundamental configuration option that turns on multilink for that link. > Shouldn't there be some text that states explicitly the option that > selects multilink? Speaking of the "Configuration Option Types", it > appears that the Maximum Receive Reconstructed Unit size could in > principle vary from one link to the next within the same bundle. >>No. The MRU may vary from physical link to physical link but the MMRU >>is fixed for the "bundle". Yes I understand that the MRU is the standard option for the specific link and applies only to that link. My point was that according to the LCP protocol procedure, the multilink MRRU parameter is negotiated in exactly the same way as another configuration option separately on each link, but semantically the option does not apply to a single link, but to the whole bundle. You have something which is procedurally done on a link by link basis, but semantically applies to the whole bundle. This is what leaves open the door for redundancy. In spite of this I do like the new architecture of negotiating multilink at the link level because it allows each new link to optionally "subscribe" to bundle participation as the link comes up. I just think that using a negotiation option has this redundancy side effect. I can live with this, but the text should be clear about making sure the MRRU configuration option is set the same over all "subscribing" links. >4. The draft also equivocates between "Only one multilink 'bundle' may > exist between peer systems" in Section 1.2 and the next to last > paragraph of Section 7, "Although explicitly forbidden above, if > there were several ....". I got the impression that the latter > section gives an escape clause from the provision of Section 1.2. > So do we allow it or not? Also I do not understand why we have to > have the restriction of Section 1.2. >>This was an area where there was still some disagreement. The bottom >>line is that even though there may only be one multilink "bundle" >>between two peers, you may have other links that are not part of the >>"bundle" with which you may do anything that pleases you. This was an >>escape clause that allows people to continue to run non-multilink >>inverse multiplexing schemes already in use. O.K. so it may be this will be cleaned up after the IETF meeting when the disagreement is resolved. I presume that this draft will eventually be put on the standards track. So my point is that an RFC standard should not in its language admittedly contradict itself. Therefore, the language "although explicitly forbidden above...." should eventually be removed. We either allow this and use SHOULD language to recommend the preferred procedure or absolutely forbid this. My preference is to allow the possibility of multiple bundles between 2 systems (e.g. 2 routers), each bundle identified by separate authentication identifiers. In this case this whole spec applies in multiple instantiations, with one instantiation per bundle. I do not see what you buy by making a restriction of one bundle per pair of systems. Just leave it up to each implementation. Allen B. Rochkind 3Com Corporation (408) 764 - 6014 - - - - - - - - - - - - - - - - - From list-admin Sat Mar 12 16:50:58 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA19327 for ; Sat, 12 Mar 1994 16:50:55 -0500 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0pfbZz-000ERtC; Sat, 12 Mar 94 13:50 PST Message-Id: Date: Sat, 12 Mar 94 13:50 PST X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Allen_Rochkind@3mail.3com.com, ietf-ppp@merit.edu From: brian@lloyd.com (Brian Lloyd) Subject: Re: Comments on the 6.5 Multilink Draft Cc: Allen_Rochkind@3mail.3com.com >>4. The draft also equivocates between "Only one multilink 'bundle' may >> exist between peer systems" in Section 1.2 and the next to last >> paragraph of Section 7, "Although explicitly forbidden above, if >> there were several ....". I got the impression that the latter >> section gives an escape clause from the provision of Section 1.2. >> So do we allow it or not? Also I do not understand why we have to >> have the restriction of Section 1.2. > >>>This was an area where there was still some disagreement. The bottom >>>line is that even though there may only be one multilink "bundle" >>>between two peers, you may have other links that are not part of the >>>"bundle" with which you may do anything that pleases you. This was an >>>escape clause that allows people to continue to run non-multilink >>>inverse multiplexing schemes already in use. > >O.K. so it may be this will be cleaned up after the IETF meeting when >the disagreement is resolved. I presume that this draft will eventually >be put on the standards track. So my point is that an RFC standard >should not in its language admittedly contradict itself. Therefore, the >language "although explicitly forbidden above...." should eventually be >removed. We either allow this and use SHOULD language to recommend the >preferred procedure or absolutely forbid this. My preference is to >allow the possibility of multiple bundles between 2 systems (e.g. 2 >routers), each bundle identified by separate authentication identifiers. >In this case this whole spec applies in multiple instantiations, with >one instantiation per bundle. > >I do not see what you buy by making a restriction of one bundle per pair >of systems. Just leave it up to each implementation. I was trying to converge on simplicity. We kept seeing more and more confusion and complexity that it was getting rather difficult to see the forest for the trees. Let us consider the "usual" way that multilink will be use: to open multiple similar links between two participating system in such a manner that they may be treated as one logical link. The dominant usage will be with ISDN and modem connections. I can also see applications in areas where multiple T1s are cheaper than a T3. I expect running one multilink bundle between peers with no "un-bundled" links to be the rule rather than the exception. Given this I wanted the absolutely simplest approach that would provide multilink support. Let's not get too carried away with complexity again. There is elegance (and cost savings!) in simplicity. > > >Allen B. Rochkind >3Com Corporation >(408) 764 - 6014 Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Sun Mar 13 16:56:08 1994 Received: from pm002-05.dialip.mich.net (pm002-05.dialip.mich.net [35.1.48.86]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA00807 for ; Sun, 13 Mar 1994 16:56:06 -0500 Date: Sun, 13 Mar 94 21:23:54 GMT From: "William Allen Simpson" Message-ID: <2039.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: pppext-hdlc-fs-00 I have forwarded a new draft to internet-drafts. It may also be found at ftp.morningstar.com:pub/ppp-wg-drafts/hdlc.txt. It has change bars, for those of you familiar with the old versions. The change bars are for how things have really changed, not changes from the horrendous reformatting hack job the RFC Editor did to RFC 1549. Summary of changes: 1) The ISO/IEC references have been updated from 1979 to 1991. (We did all of this work based on the original, and various addendums. They finally got around to publishing a new edition, and we didn't even notice.) 2) The new addendum to the new 3309 isn't interoperable with PPP. So, a few implementation notes were added to describe how to be more compatible, if you like. Compatibility is not required (MAY). 3) a couple of spots where FCS errors should not be counted are noted. 4) 32-bit FCS is now defined and referenced, with the publication of RFC 1570. 5) A new appendice implementation note on auto-recognition of PPP LCP frames at login time. Anything else folks want, speak now or hold your peace for a very very long time! Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Sun Mar 13 19:33:54 1994 Received: from pm002-17.dialip.mich.net (pm002-17.dialip.mich.net [35.1.48.98]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA08548 for ; Sun, 13 Mar 1994 19:33:52 -0500 Date: Mon, 14 Mar 94 00:18:27 GMT From: "William Allen Simpson" Message-ID: <2041.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: pppext-lcp-fs-00 I have forwarded a new draft to internet-drafts. It may also be found at ftp.morningstar.com:pub/ppp-wg-drafts/lcp.txt. It has change bars, for those of you familiar with the old versions. The change bars are for how things have really changed, not changes from the horrendous reformatting hack job the RFC Editor did to RFC 1548. Summary of changes: 1) The references have been updated. 2) I removed most of the Protocols. They were just too many. Only those actually referenced remain. 3) some commas. Anything else folks want, speak now or hold your peace for a very very long time! Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Mon Mar 14 14:40:47 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA26826 for ; Mon, 14 Mar 1994 14:40:45 -0500 From: Allen_Rochkind@3Mail.3Com.COM Received: from cixgate.3com.com (via [192.156.136.10]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhfq28946; Mon, 14 Mar 94 14:40:07 -0500 Received: from gw.3Com.COM by cixgate.3com.com (4.1/SMI-4.1/3com-cixgate-GCA-931027-01) id AA19688; Mon, 14 Mar 94 11:40:34 PST Received: by gw.3Com.COM id AA17823 (5.65c/IDA-1.4.4 for ietf-ppp@Merit.edu); Mon, 14 Mar 1994 11:39:54 -0800 Date: Mon, 14 Mar 94 11:36 PST Subject: Re: Comments on the 6.5 Multilink Draft To: ietf-ppp@merit.edu Cc: Allen_Rochkind@3Mail.3Com.COM Message-Id: <940314.114310@3Mail.3Com.COM> Forwarded: Message from {brian@lloyd.com}:ugate:3Com of 3-12-94 Thank you, for your clarification. I too want to move toward simplicity, but I do not want to lose basic functionality. This issue may be a question of what you consider the "usual way way that multilink will be used ...." as you indicated below. 3Com sells routers and one characteristic of routers is that a single router box may have several "logical ports". For example consider a router located in San Jose. An example of several "logical ports" is that on the same router box in San Jose, one logical port consists of several bundled lines which go, say, to Seattle and another port consists of a set of bundled lines which go to San Francisco. On one port we are routing protocols between San Jose and Seattle. On the other port we are routing protocols between San Jose and San Francisco. We would like to be able configure the different logical ports depending on (logical port specific) bandwidth requirements so that we can apply on some ports bundles of multiple channels, and perhaps on other ports, only one channel. The router box in San Jose (which represents a single implementation of PPP), may therefore have several different bundles of channels or perhaps some channels not associated with any bundle (the latter channel, e.g., supporting a logical port which uses only one channel for physical transport). I believe this is a very "usual" configuration for a router since one of their prime features is to offer lots of logical ports (i.e. the ability to internet to lots of different subnets) on a single box and configurable bandwidth on any of those logical ports. I hope this clarifies my concern in raising this issue. --------------------- Forwarded Message Body --------------------- Date: 3-12-94 02:22pm From: {brian@lloyd.com}:ugate:3Com To: Allen Rochkind:hq:3Com Subj: Re: Comments on the 6.5 Multilink Draft ----------------------------------------------------------------- Original header follows: Received: from gatekeeper.3Com.COM by gw.3Com.COM with SMTP id AA12903 (5.65c/IDA-1.4.4 for ); Sat, 12 Mar 1994 13:50:54 -0800 Return-Path: Received: from lloyd.com (harry.lloyd.com) by gatekeeper.3Com.COM with SMTP id AA23545 (5.65c/IDA-1.4.4-910725 for ); Sat, 12 Mar 1994 13:50:51 -0800 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0pfbZz-000ERtC; Sat, 12 Mar 94 13:50 PST Message-Id: Date: Sat, 12 Mar 94 13:50 PST X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Allen_Rochkind@3mail.3com.com, ietf-ppp@merit.edu From: brian@lloyd.com (Brian Lloyd) Subject: Re: Comments on the 6.5 Multilink Draft Cc: Allen_Rochkind@3mail.3com.com ----------------------------------------------------------------- >>4. The draft also equivocates between "Only one multilink 'bundle' may >> exist between peer systems" in Section 1.2 and the next to last >> paragraph of Section 7, "Although explicitly forbidden above, if >> there were several ....". I got the impression that the latter >> section gives an escape clause from the provision of Section 1.2. >> So do we allow it or not? Also I do not understand why we have to >> have the restriction of Section 1.2. > >>>This was an area where there was still some disagreement. The bottom >>>line is that even though there may only be one multilink "bundle" >>>between two peers, you may have other links that are not part of the >>>"bundle" with which you may do anything that pleases you. This was an >>>escape clause that allows people to continue to run non-multilink >>>inverse multiplexing schemes already in use. > >O.K. so it may be this will be cleaned up after the IETF meeting when >the disagreement is resolved. I presume that this draft will eventually >be put on the standards track. So my point is that an RFC standard >should not in its language admittedly contradict itself. Therefore, the >language "although explicitly forbidden above...." should eventually be >removed. We either allow this and use SHOULD language to recommend the >preferred procedure or absolutely forbid this. My preference is to >allow the possibility of multiple bundles between 2 systems (e.g. 2 >routers), each bundle identified by separate authentication identifiers. >In this case this whole spec applies in multiple instantiations, with >one instantiation per bundle. > >I do not see what you buy by making a restriction of one bundle per pair >of systems. Just leave it up to each implementation. >> I was trying to converge on simplicity. We kept seeing more >>and more confusion and complexity that it was getting rather difficult >>to see the forest for the trees. >>Let us consider the "usual" way that multilink will be use: to open >>multiple similar links between two participating system in such a >>manner that they may be treated as one logical link. The dominant >>usage will be with ISDN and modem connections. I can also see >>applications in areas where multiple T1s are cheaper than a T3. I >>expect running one multilink bundle between peers with no "un-bundled" >>links to be the rule rather than the exception. Given this I wanted >>the absolutely simplest approach that would provide multilink support. >>Let's not get too carried away with complexity again. There is >>elegance (and cost savings!) in simplicity. > > >Allen B. Rochkind >3Com Corporation >(408) 764 - 6014 Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Mon Mar 14 21:41:56 1994 Received: from lloyd.com (harry.lloyd.com [158.222.1.6]) by merit.edu (8.6.5/8.6.5) with SMTP id VAA28706 for ; Mon, 14 Mar 1994 21:41:50 -0500 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #3) id m0pgP4e-000ERoC; Mon, 14 Mar 94 18:41 PST Message-Id: Date: Mon, 14 Mar 94 18:41 PST X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Allen_Rochkind@3mail.3com.com, ietf-ppp@merit.edu From: brian@lloyd.com (Brian Lloyd) Subject: Re: Comments on the 6.5 Multilink Draft Cc: Allen_Rochkind@3mail.3com.com At 11:36 3/14/94 -0800, Allen_Rochkind@3Mail.3Com.COM wrote: >Thank you, for your clarification. I too want to move toward >simplicity, but I do not want to lose basic functionality. This issue >may be a question of what you consider the "usual way way that multilink >will be used ...." as you indicated below. > >3Com sells routers and one characteristic of routers is that a single >router box may have several "logical ports". For example consider a >router located in San Jose. An example of several "logical ports" is >that on the same router box in San Jose, one logical port consists of >several bundled lines which go, say, to Seattle and another port >consists of a set of bundled lines which go to San Francisco. On one >port we are routing protocols between San Jose and Seattle. On the >other port we are routing protocols between San Jose and San Francisco. >We would like to be able configure the different logical ports depending >on (logical port specific) bandwidth requirements ... I am having trouble visualizing what you are talking about. Please define "logical port" more clearly for me. Is a "logical port" a group of physical interfaces "bundled" together, e.g. two T1's between SJ and SF and perhaps two T1's between SJ and Seattle? If so, I would expect that you would have one "bundle" between SJ and each of the other places. From the point of view of multilink, you have a "bundle" between each pair of endpoints. Several "bundles" may originate at a single router since each "bundle" would most commonly be assiciated with an interface from an IP, IPX, Appletalk, etc., point of view. Are you saying that you want to have more or fewer physical links in the bundle depending on protocol? For instance: ,-----------. IP+IPX+AT ,----------. | +--------------------+ | | Router A | | Router B | | +--------------------+ | `-----------' IP only `----------' So you would like to "bundle" the two links together for IP but run only IPX and Appletalk over the first link? If so, I don't think that the multilink we are describing is going to do you much good. The goal of the multilink we are working on is to combine multiple physical links an make them function like one logical link. All the ULPs may travel over the "bundle" equally. However, there is nothing preventing you from bringing up each link as a separate PPP link and then doing your own proprietary thing (bank teller algorithm?) over the links. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 - - - - - - - - - - - - - - - - - From list-admin Tue Mar 15 10:36:58 1994 Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA21040 for ; Tue, 15 Mar 1994 10:36:55 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA13826; Tue, 15 Mar 94 09:40:19 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA24982; Tue, 15 Mar 94 09:36:49 CST Date: Tue, 15 Mar 94 09:36:49 CST From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9403151536.AA24982@anubis.network.com> To: ietf-ppp@merit.edu Subject: Re: Comments on the 6.5 Multilink Draft On the topic of multiple bundles, I would like to publicly straddle the fence (ouch). For practicallity and simplicity, I was and am willing to accept only one bundle between two systems, with the ability to keep some links unbundled. However, the requirement for multiple links is not fallacious. We have a number of customers who, in order to internally provide guarantees of minimum service levels would like to be able to keep traffic for different protocols separate. For example, Appletalk is broadcast heavy, so they want to keep it out of the way. This is why I need, at least, to be able to keep some links out of the bundle. Given that premise, it is clear that the amount of bandwidth desired for such purposes can easily call for separate bundles rather than separate links. Thus, if we are really to solve the customers problem, we would support multiple parallel bundles. However, at least for now, it seems much simpler to only allow one bundle and extra links. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation - - - - - - - - - - - - - - - - - From list-admin Tue Mar 15 12:26:56 1994 Received: from digibd.com (digibd.digibd.com [192.83.159.205]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA00248 for ; Tue, 15 Mar 1994 12:26:55 -0500 Received: by digibd.com (5.65/DBI-1.19) id AA27674; Tue, 15 Mar 94 11:21:20 -0600 From: tomc@digibd.com (Tom Coradetti) Message-Id: <9403151721.AA27674@digibd.com> Subject: Re: Multiple bundles To: jmh@anubis.network.com (Joel Halpern) Date: Tue, 15 Mar 1994 11:21:20 -0600 (CST) Cc: ietf-ppp@merit.edu In-Reply-To: <9403151536.AA24982@anubis.network.com> from "Joel Halpern" at Mar 15, 94 09:36:49 am X-Mailer: ELM [version 2.4 PL16] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2904 > > Joel Halpern writes: > On the topic of multiple bundles, I would like to publicly straddle the > fence (ouch). > > For practicallity and simplicity, I was and am willing to accept only one > bundle between two systems, with the ability to keep some links unbundled. > > However, the requirement for multiple links is not fallacious. We have > a number of customers who, in order to internally provide guarantees of > minimum service levels would like to be able to keep traffic for different > protocols separate. For example, Appletalk is broadcast heavy, so they > want to keep it out of the way. This is why I need, at least, to be able > to keep some links out of the bundle. Given that premise, it is clear > that the amount of bandwidth desired for such purposes can easily call > for separate bundles rather than separate links. > > Thus, if we are really to solve the customers problem, we would support > multiple parallel bundles. However, at least for now, it seems much > simpler to only allow one bundle and extra links. This was exactly the motivation for the bundle identifier option I proposed in the days of the multilink control protocol drafts. By identifying which bundle you wanted a new link to initiate or join (or identifying a group of bundles from which the answerer would select a particular one and inform the caller of the choice) the multiple bundles can be supported. Vernon Schryer aptly pointed out that it creates a security hole to do this after authentication has taken place. If there is no multilink NCP, as is the state of the current draft, the link is associated with a bundle during the LCP negotiation. There is a subtle problem created by the current draft. It associates a link with a bundle during LCP negotiation, but the link can not actually be used to carry network protocol data fragments until authentication occurs on the link. The concept of declaring a link capable of multilink fragmentation (defined now by use of the MRRU LCP option) should be distinguished from actually permitting fragmentation packets to be sent. In the interim, association with one of multiple bundles can occur. There are at least two ways to do this: (1) Use authentication to make the association. (2) Use a bundle id LCP option to identify a bundle to join, recognizing that the link is not able to participate in the bundle until after authentication. Approach (1) requires authentication and is vaguely defined. Approach (2) works without authentication and can provide definitive feedback when the answer participates in the decision of which bundle to join. It does not defeat authentication. Neither approach requires either endpoint to specify a particular bundle to join. If the bundle identification is left out of either the LCP or authentication exchange, the side which knows how to do multiple bundles can pick a default bundle. tc - - - - - - - - - - - - - - - - - From list-admin Tue Mar 15 14:20:31 1994 Received: from ucdavis.ucdavis.edu (ucdavis.ucdavis.edu [128.120.250.250]) by merit.edu (8.6.5/8.6.5) with ESMTP id OAA10538 for ; Tue, 15 Mar 1994 14:20:30 -0500 From: itdavid@ucdavis.edu Received: from localhost by ucdavis.ucdavis.edu (8.6.5/UCD2.50) id LAA29396; Tue, 15 Mar 1994 11:10:18 -0800 Date: Tue, 15 Mar 1994 11:10:18 -0800 Message-Id: <199403151910.LAA29396@ucdavis.ucdavis.edu> To: ietf-ppp@merit.edu Subject: ---------------------- Forwarded Message Follows ---------------------- Received: from localhost by ucdavis.ucdavis.edu (8.6.5/UCD2.50) id RAA28320; Mon, 14 Mar 1994 17:33:33 -0800 Sender: ietf-ppp-request@ucdavis Received: from seraph.uunet.ca by ucdavis.ucdavis.edu (8.6.5/UCD2.50) id RAA27778; Mon, 14 Mar 1994 17:29:19 -0800 Received: from uuisis by mail.uunet.ca with UUCP id <101994(5)>; Mon, 14 Mar 1994 20:29:00 -0500 Received: from plntree by uuisis.isis.org id aa18268; 14 Mar 94 20:19 EST Received: from cc:Mail by plntree.isis.org (2.0/Outmail) id Message-ID: <531@plntree.isis.org>; Mon, 14 Mar 94 20:19:46 EST Date: Mon, 14 Mar 1994 20:19:46 -0500 From: Christian@plntree.isis.org, Francoise@plntree.isis.org Message-ID: <531@plntree.isis.org> To: ietf-ppp@ucdavis.edu Subject: implementations of ppp for Windows Text item: Text_1 I need a list of vendors of implementations of ppp for pc under Windows. I would be thanksfull to anyone who could help me build one. - - - - - - - - - - - - - - - - - From list-admin Tue Mar 15 16:18:05 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA21257 for ; Tue, 15 Mar 1994 16:18:04 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12699; 15 Mar 94 15:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-lcp-fs-00.txt Date: Tue, 15 Mar 94 15:27:44 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403151527.aa12699@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The Point-to-Point Protocol (PPP) Author(s) : W. Simpson Filename : draft-ietf-pppext-lcp-fs-00.txt Pages : 61 Date : 03/14/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating multi-protocol datagrams. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the PPP organization and methodology, and the PPP encapsulation, together with an extensible option negotiation mechanism which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. The PPP Link Control Protocol (LCP) is described in terms of this mechanism. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-lcp-fs-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lcp-fs-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940314114050.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-lcp-fs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lcp-fs-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940314114050.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Tue Mar 15 16:18:04 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA21255 for ; Tue, 15 Mar 1994 16:18:03 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12660; 15 Mar 94 15:27 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-hdlc-fs-00.txt Date: Tue, 15 Mar 94 15:27:38 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403151527.aa12660@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP in HDLC Framing Author(s) : W. Simpson Filename : draft-ietf-pppext-hdlc-fs-00.txt Pages : 23 Date : 03/14/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of HDLC for framing PPP encapsulated packets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-hdlc-fs-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-hdlc-fs-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940314113308.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-hdlc-fs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-hdlc-fs-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940314113308.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Tue Mar 15 21:25:25 1994 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by merit.edu (8.6.5/8.6.5) with SMTP id VAA13758 for ; Tue, 15 Mar 1994 21:25:24 -0500 Received: from uucp5.uu.net by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwhkj18737; Tue, 15 Mar 94 21:24:51 -0500 Received: from cendata.UUCP by uucp5.uu.net with UUCP/RMAIL ; Tue, 15 Mar 1994 21:24:51 -0500 Received: from juggler.cd.com by bif.cd.com (4.1/SMI-4.1) id AA08006; Tue, 15 Mar 94 15:49:28 CST Received: From FS1/WORKQUEUE by juggler.cd.com via Charon-4.0A-VROOM with IPX id 100.940315154431.448; 15 Mar 94 15:44:53 +0500 Message-Id: To: ietf-ppp@merit.edu From: "Jeff Roloff" Date: Tue, 15 Mar 1994 15:44:25 CST Subject: subscribe Priority: normal X-Mailer: WinPMail v1.0 (R1) Jeff Roloff Phone (217) 359-8010 X208 Central Data FAX (217) 359-6904 1602 Newton Drive Champaign, IL 61821 USA - - - - - - - - - - - - - - - - - From list-admin Wed Mar 16 09:31:00 1994 Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by merit.edu (8.6.5/8.6.5) with SMTP id JAA27776 for ; Wed, 16 Mar 1994 09:30:57 -0500 Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA23594; Wed, 16 Mar 94 08:34:18 -0600 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA09365; Wed, 16 Mar 94 08:30:46 CST Date: Wed, 16 Mar 94 08:30:46 CST From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9403161430.AA09365@anubis.network.com> To: ietf-ppp@merit.edu Subject: New Data Encapsulation draft I have submitted, and attached below, a revision of the draft of "PPP Option for Data Encapsulation Selection". This revision attempts to clarify three issues that were previously raised: 1) It retains the references to many potentially applicable technologies, but indicates that Frame Relay is the current issue. 2) It changes the term used to refer to existing encapsulations from "native" to "nominal" 3) It tries to clarify the description of the "Loss of Shared State" problem, and indicate what cases are being solved. It does not list all LCP related Shared State which could be lost, since the document neither creates nor resolves those problems. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation -------------------------------------------------------------------------- Network Working Group Joel M. Halpern Internet Draft Network Systems Corporation Expires in six months March 1994 PPP Option for Data Encapsulation Selection draft-ietf-pppext-dataencap-02.txt Status of this Memo This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. 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. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating the encapsulation to be used for the transfer of data by PPP. It applies only to media for which there exists a "nominal" data encapsulation outside of PPP. Joel M. Halpern expires in six months [Page i] DRAFT PPP Option for Data Encapsulation Selection March 1994 1. Introduction As defined by the base RFC [1], PPP is a set of state machines (semantics) and encapsulations (syntax). The use of this combination results in the robust and reliable negotiation of options and transmission of data over Point-to-Point links. As part of this, PPP defines an extensible Link Control Protocol (LCP) for establish, configuring, and testing the data-link connection. Several extensions to this are defined in an additional RFC [2]. This document defines a new option for use with the LCP. In recent years, several wide area technologies with multi-point non-broadcast characteristics have developed. For each of these, data encapsulation syntax and operational semantics have been developed within the IETF ([3], [4], [5], [6]). The syntax used in each case was developed to meet a range of requirements. As work with these technologies has advanced, the desire for parameter negotiation, and additional capabilities, has become clear. Different techniques have been used in different cases. For X.25, for example, the solution was to use PPP over separate circuits than for previous encapsulations. In the Frame relay case, that was considered insufficient. In particular, there was a desire to make use of the powerful PPP state machine and negotiation mechanism over Frame Relay circuits operating with previously accepted RFCs. Also, there was a desire to make the full power of the PPP machinery available to Frame Relay users. The first step in doing this was to define how to carry PPP negotiation frames over Frame Relay. A series of drafts have been written to address this. As these were discussed, it became clear that there was a further issue. Once one has a way to carry PPP negotiation frames, one could also carry PPP data frames using PPP syntax. The question then becomes one of inter-operation. It is clearly desirable, in the abstract, that stations use uniform encapsulation when practical. The first step towards resolving this was taken in the PPP drafts for the individual media. These documents state that even after the PPP LCP has entered the open state, data can be exchanged using the media "nominal" encapsulation for any protocol whose NCP has not been negotiated. This document proposes an LCP option which, when negotiated, allows appropriate data to be transferred in the media nominal encapsulation after the protocol NCP has been negotiated. Joel M. Halpern expires in six months [Page 1] DRAFT PPP Option for Data Encapsulation Selection March 1994 2. The Data Encapsulation Option There exist several media for which there is an nominal data encapsulation, distinct from the PPP encapsulation, and over which there is a desire to use PPP. The goal of this is to provide two capabilities, full PPP operation and pure parameter negotiation. In starting to meeting these goals, the documents on PPP over the individual media state that after a PPP NCP is negotiated, the data transfer will take place using the PPP data encapsulation for that NCP. This gives strong operation of the PPP NCP and data transfer mechanisms over media which have underlying data encapsulations. In order to meet the goal of pure parameter negotiation, an indication is needed that the reduced data encapsulation behavior is desired upon completion of parameter negotiation. This option fills that role. When negotiated, this option indicates that even after an NCP is negotiated to the open state, the nominal data encapsulation will be used for that protocol. This option is incompatible with NCP options which affect the data transfer semantics. Generally, any NCP option which would change the way the data is sent for that NCP can not be used if the Nominal- Data-Encapsulation LCP option has been negotiated. For example, if the LCP Nominal-Data-Encapsulation option is negotiated, one may not use the Bridging NCP option for Bridge LAN ID, or the IP NCP option for VJ Header compression. 2.1. Usage As with all LCP options, use of this option is at the discretion of the end-station. For compatibility, it is important to note that while a station may not force another station to use an option, it may refuse to open the connection without it. Thus, a station desiring to use only the nominal data encapsulations may refuse to complete LCP negotiation unless the remote side accepts the LCP Nominal-Data-Encapsulation option. Alternatively, such a station may open the LCP, but refuse to perform any NCP negotiations, so as to prevent the usage of any data encapsulations other than the nominal. Joel M. Halpern expires in six months [Page 2] DRAFT PPP Option for Data Encapsulation Selection March 1994 3. Configuration Option Format Description The LCP Nominal-Data-Encapsulation Configuration Option negotiates the use of the media nominal data encapsulation for NCP data, rather than the PPP encapsulation. If the LCP and NCP are opened without this option, the PPP encapsulation is used for any protocol whose NCP is open. A summary of the Nominal-Data-Encapsulation Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (14) Length = 2 Joel M. Halpern expires in six months [Page 3] DRAFT PPP Option for Data Encapsulation Selection March 1994 4. Loss of State There is a potential problem (undetected loss of shared state) as a result of the interaction between PPP LCP/NCP and the use of nominal data encapsulation. When nominal encapsulation is used, either because the NCP has not been negotiated, or because the Nominal-Data-Encapsulation was negotiated, there is the possibility for invisible loss of shared state. If the two sides have agreed to use the LCP Nominal-Data- Encapsulation option, then they will be exchanging data using the media specific encapsulation. If the "remote" unit is then transparently reset or replaced, it could choose to send data without initiating any LCP (or NCP) negotiation. Since it would use the same data format, communication would appear to be taking place properly, when in fact the shared state does not exist. This problem affects LCP shared state even in the absence of the LCP Nominal-Data-Encapsulation Configuation Option, since the nominal encapsulation is used for any protocols for which no NCP has been negotiated. (Thus, one could have shared LCP state which is lost, even when no NCPs have been negotiated.) This document does not change that. The use of the LCP Nominal-Data- Encapsulation option causes the problem to apply to shared NCP state as well. This would include such attributes as IP address assignment, etc ... Joel M. Halpern expires in six months [Page 4] DRAFT PPP Option for Data Encapsulation Selection March 1994 Security Considerations As outlined in the section on Loss of State, the use of the LCP Nominal-Data-Encapsulation option leaves the systems open to certain undetected restart or replacement scenarios. In particular, the strength of the identity associated with any initial authentication protocol is weakened, since there is the possibility of replacement of the remote system transparently. Said replacement includes redirection of the underlying communications technology. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP), RFC 1548, 1993 December. [2] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, 1994 January. [3] Bradley, T.; Brown, C.; Malis, A. Multiprotocol Interconnect over Frame Relay, RFC 1490, 1993 July. [3] Piscitello, D.; Lawrence, J. Transmission of IP datagrams over the SMDS Service, RFC 1209, 1991 March [4] Malis, A.; Robinson, D.; Ullmann, R. Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode, RFC 1356, 1992 August [5] Heinanen, J. Multiprotocol Encapsulation over ATM Adaptation Layer 5, RFC 1483, 1993 July Acknowledgments Joel M. Halpern expires in six months [Page 5] DRAFT PPP Option for Data Encapsulation Selection March 1994 Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California 93117 EMail: fbaker@acc.com Author's Address Questions about this memo can also be directed to: Joel M. Halpern Network Systems Corporation 7600 Boone Avenue North Brooklyn Park, MN 55428 +1 612 424-1606 EMail: jmh@network.com Joel M. Halpern expires in six months [Page 6] DRAFT PPP Option for Data Encapsulation Selection March 1994 Table of Contents 1. Introduction .......................................... 1 2. The Data Encapsulation Option ......................... 2 2.1 Usage ........................................... 2 3. Configuration Option Format ........................... 3 4. Loss of State ...................................... 4 SECURITY CONSIDERATIONS ................................... 5 REFERENCES ................................................ 5 ACKNOWLEDGEMENTS ............................................. 5 CHAIR'S ADDRESS .............................................. 6 AUTHOR'S ADDRESS ............................................. 6 - - - - - - - - - - - - - - - - - From list-admin Wed Mar 16 13:55:54 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA18583 for ; Wed, 16 Mar 1994 13:55:48 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB11864; Wed, 16 Mar 94 10:55:06 PST Message-Id: <9403161855.AB11864@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Mar 1994 10:54:53 -0800 To: stev@ftp.com (stev knowles) From: fbaker@acc.com (Fred Baker) Subject: Bridging and Compression Cc: ietf-ppp@merit.edu, dlr@daver.bungi.com (Dave Rand), "Rich Bowen" , gregl@novell.com (Greg Linn), scoya@nri.reston.va.ue Stev: We have run a last call on the bridging and compression documents, and have no substantive comments. The working group is prepared for these to become Proposed Standards. Would you please advise Steve Coya to issue the IESG last call, and make them happen? updated Bridging/PPP, to Proposed Standard: draft-ietf-pppext-for-bridging-03.txt Compression, and supporting compression algorithms: draft-ietf-pppext-compression-04.txt to Proposed Standard draft-ietf-pppext-bsd-compress-00.txt FYI (supporting above) draft-ietf-pppext-gandalf-00.txt FYI (supporting above) draft-ietf-pppext-hpppc-00.txt FYI (supporting above) draft-ietf-pppext-predictor-00.txt FYI (supporting above) draft-ietf-pppext-stacker-00.txt FYI (supporting above) The reason that the various algorithm documents are not on a standards track is because patents apply to these and some represent businesses of their author's companies. There can, therefore, never be multiple interoperable implementations of same. The documents are structured in this way specifically to enable businesses to persue their courses with minimum impact of their patents and claims on the standard or the process that generates it. The IESG should be aware that there is a patent claim being made by Motorola regarding the compression specification itself. Novell asserts that significant prior art invalidates the claim. The discussions between those two companies have not at this point resolved the issue. In my (non-legal) opinion, compression is a minefield of patent claims and counter-claims, and no standard can be written which doesn't face the issues. Therefore, the PPP Working Group and the IETF are forced into the position of permitting a claim of patent rights to disable us from agreeing on a standard, or forging ahead and allowing industry to settle that question. ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Wed Mar 16 14:04:03 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA19491 for ; Wed, 16 Mar 1994 14:04:01 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB12024; Wed, 16 Mar 94 11:03:55 PST Message-Id: <9403161903.AB12024@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Mar 1994 11:03:42 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: PPP Extensions Agenda at IETF Cc: ietf-announce-post@cnri.reston.va.us My agenda includes, at the moment, three subjects and four documents, and we have two seesions (thrusday morning and afternoon, last I checked) in which to discuss them. We will discuss in the following order: draft-ietf-pppext-netbios-fcp-04.txt Dimitri It would appear that Shiva and Microsoft have some disagreements here, and I would like to get closure so that both can move on. draft-ietf-pppext-multilink-07.txt Sklower I expect to spend the bulk of the morning meeting on this. I see no reason that we cannot complete this at this IETF. draft-ietf-pppext-dataencap-02.txt Halpern draft-ietf-pppext-frame-relay-02.txt Simpson This is the reconciliation of the IPLPDN/PPP issue we have discussed. I expect to spend the bulk of the afternoon meeting on this. I see no reason that we cannot complete this at this IETF. ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Wed Mar 16 15:13:58 1994 Received: from ftp.com (wd40.ftp.com [128.127.2.122]) by merit.edu (8.6.5/8.6.5) with SMTP id PAA25368 for ; Wed, 16 Mar 1994 15:13:57 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 16 Mar 1994 15:13:57 -0500 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA15587; Wed, 16 Mar 94 15:13:19 EST Date: Wed, 16 Mar 94 15:13:19 EST Message-Id: <9403162013.AA15587@mailserv-D.ftp.com> To: fbaker@acc.com Subject: Re: Bridging and Compression From: stev@ftp.com (stev knowles) Cc: ietf-ppp@merit.edu, rich_bowen@vnet.IBM.COM, gregl@novell.com, scoya@nri.reston.va.ue Sender: stev@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 16 15:13:13 1994] Originating-Client: d-cell.ftp.com Content-Length: 163 wow, we have been *busy*. OK, scoya, let me have the ballots. as in the past, information from the community abotu implementations woudl be appreicated. - - - - - - - - - - - - - - - - - From list-admin Wed Mar 16 15:14:00 1994 Received: from vangogh.CS.Berkeley.EDU ([128.32.130.2]) by merit.edu (8.6.5/8.6.5) with ESMTP id PAA25324 for ; Wed, 16 Mar 1994 15:12:36 -0500 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.6.7/8.6.6) id MAA11487 for ietf-ppp@merit.edu; Wed, 16 Mar 1994 12:10:35 -0800 Date: Wed, 16 Mar 1994 12:10:35 -0800 From: Keith Sklower Message-Id: <199403162010.MAA11487@vangogh.CS.Berkeley.EDU> To: ietf-ppp@merit.edu Subject: Re: Compression and Multilink Gerry: I think the compression people should have the final say over whether default is compression above or below multilink, and what the protocol numbers are. The mutlilink draft does cite the compression spec. Draft 7 puts down what I thought the consensus was; everybody queried said that they were planning to run compression above multilink, although a number of people said they thought that having an escape hatch to do it below was a good idea. At the time, I was unaware that IANA had formally blessed a protocol ID for running compression on the link instead of the bundle. It certainly wouldn't hurt to make the paragraph in the mutlilink draft more clear by (redundantly) enumerating the protocol ID numbers specified in the compression draft. But I really didn't (and still don't) think that that the two paragraphs you quoted are in conflict. - - - - - - - - - - - - - - - - - From list-admin Wed Mar 16 20:28:28 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA17793 for ; Wed, 16 Mar 1994 20:28:27 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA08353; Wed, 16 Mar 94 17:28:20 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA01110; Wed, 16 Mar 94 18:16:24 -0700 Date: Wed, 16 Mar 94 18:16:24 -0700 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9403170116.AA01110@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: Compression and Multilink > From: sklower@vangogh.CS.Berkeley.EDU (Keith Sklower) > > I think the compression people should have the final say over > whether default is compression above or below multilink, and > what the protocol numbers are. The mutlilink draft does cite > the compression spec. > > Draft 7 puts down what I thought the consensus was; everybody > queried said that they were planning to run compression above > multilink, although a number of people said they thought that > having an escape hatch to do it below was a good idea. > > At the time, I was unaware that IANA had formally blessed a protocol > ID for running compression on the link instead of the bundle. It > certainly wouldn't hurt to make the paragraph in the mutlilink > draft more clear by (redundantly) enumerating the protocol ID > numbers specified in the compression draft. But I really didn't > (and still don't) think that that the two paragraphs you quoted > are in conflict. I do not see a conflict either. I do not understand how the idea of "default" applies to compression over or under the bundle. Each uses a different protocol number. There is no notion that makes sense for "default over" or "default under." I hope no one wants words like "an implementation that compresses MUST use protocol 0xZZ to compress above/below multilink but also MAY use protocol 0xYY to compreess below/above mulitlink." I would object to such words as unnecessary and fascist (i.e. "a political philosophy, movement, or regime that exalts nation and race and stands for a centralized autocratic government headed by a dictatorial leader ..."). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Thu Mar 17 04:50:53 1994 Received: from relay1.pipex.net (relay1.pipex.net [158.43.128.4]) by merit.edu (8.6.5/8.6.5) with SMTP id EAA13564 for ; Thu, 17 Mar 1994 04:50:45 -0500 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <17877-0@relay1.pipex.net>; Thu, 17 Mar 1994 09:50:28 +0000 Received: by widow.spider.co.uk; Thu, 17 Mar 94 10:00:59 GMT From: Gerry Meyer Date: Thu, 17 Mar 94 09:51:10 GMT Message-Id: <8460.9403170951@orbweb.spider.co.uk> Received: by orbweb.spider.co.uk; Thu, 17 Mar 94 09:51:10 GMT To: vjs@rhyolite.wpd.sgi.com Subject: Re: Compression and Multilink Cc: gerry@spider.co.uk, ietf-ppp@merit.edu >I do not understand how the idea of "default" applies to compression over >or under the bundle. Each uses a different protocol number. There is no >notion that makes sense for "default over" or "default under." >I hope no one wants words like "an implementation that compresses MUST >use protocol 0xZZ to compress above/below multilink but also MAY use >protocol 0xYY to compreess below/above mulitlink." >I would object to such words as unnecessary and fascist (i.e. "a >political philosophy, movement, or regime that exalts nation and race >and stands for a centralized autocratic government headed by a >dictatorial leader ..."). My use of "default" was perhaps mis-understood. If I negotiate IPCP on a link it 'defaults' to the bundle (and migrates to other links if you want to bypass MCP). Or getting the word compresion in: If VJ compression is negotiated it clearly 'defaults' to the bundle and *not* the individual links. Really all I'm trying to ensure is that one or other document defines the compression Protocol I-Ds for running over as well as under the bundle. Dave's document has the I-D for under. I believe he seems to have taken an action to write a separate 'connector' document which will contain the I-D for over. Good, as long as its somewhere. It would be useful if the mutilink (or Dave's new) document could say something to the effect that in the absense of two protocol I-Ds, where there is potential ambiguity (compression, encryption), the operation is defined to run under/over (take your pick) the link.  Gerry - - - - - - - - - - - - - - - - - From list-admin Thu Mar 17 09:33:19 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id JAA28807 for ; Thu, 17 Mar 1994 09:33:18 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA17383; Thu, 17 Mar 94 06:33:10 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA00917; Thu, 17 Mar 94 07:33:03 -0700 Date: Thu, 17 Mar 94 07:33:03 -0700 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9403171433.AA00917@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu > From: Gerry Meyer > ... > Really all I'm trying to ensure is that one or other document defines > the compression Protocol I-Ds for running over as well as under the bundle. > Dave's document has the I-D for under. I believe he seems to have taken > an action to write a separate 'connector' document which will contain the > I-D for over. Good, as long as its somewhere. > > It would be useful if the mutilink (or Dave's new) document could say > something to the effect that in the absense of two protocol I-Ds, > where there is potential ambiguity (compression, encryption), the > operation is defined to run under/over (take your pick) the link. Oh. Those sound like two good things. I'd put both compression ID's in the same document. It's not as if there is a shortage of PPP documents. vjs - - - - - - - - - - - - - - - - - From list-admin Thu Mar 17 13:03:23 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA15686 for ; Thu, 17 Mar 1994 13:03:20 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05914; 17 Mar 94 11:14 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-dataencap-01.txt Date: Thu, 17 Mar 94 11:14:38 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403171114.aa05914@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Option for Data Encapsulation Selection Author(s) : J. Halpern Filename : draft-ietf-pppext-dataencap-01.txt Pages : 6 Date : 03/16/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating the encapsulation to be used for the transfer of data by PPP. It applies only to media for which there exists a "nominal" data encapsulation outside of PPP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-dataencap-01.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-dataencap-01.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940316134856.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-dataencap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-dataencap-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940316134856.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Thu Mar 17 16:18:26 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA03128 for ; Thu, 17 Mar 1994 16:18:25 -0500 Received: from [129.192.64.5] (coal.acc.com) by fennel.acc.com (4.1/SMI-4.1) id AA09898; Thu, 17 Mar 94 13:18:06 PST Message-Id: <9403172118.AA09898@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Mar 1994 13:17:52 -0800 To: stev@ftp.com (stev knowles) From: fbaker@acc.com (Fred Baker) Subject: Re: Bridging and Compression Cc: ietf-ppp@merit.edu, dlr@daver.bungi.com (Dave Rand), gregl@novell.com (Greg Linn), scoya@cnri.reston.va.us Stev: This message clarifies a stetement I made yesterday regarding the PPP Compression Control Protocol (CCP) specification proposed by the PPP Extensions work group. Motorola has raised the issue that one or more Motorola patents may cover the proposed compression specification. Work group members have raised the possibility that prior art invalidates claims in the Motorola patents. At this time, Novell (as a participant in the work group) has not reached any definitive conclusion with respect to these patent issues. All contact between these companies have been technical discussions of the compression specification rather than legal discussions with respect to patents. It is not now, nor was it yesterday, my intent to speak on Novell's behalf, legally or otherwise. ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Thu Mar 17 19:43:01 1994 Received: from fcr (fcr.fcr.com [192.52.71.142]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA20348 for ; Thu, 17 Mar 1994 19:42:59 -0500 Received: from stemwinder.fcr.com by fcr (4.1/SMI-4.1) id AA00952; Thu, 17 Mar 94 19:37:10 EST Received: by stemwinder.fcr.com (4.1/SMI-4.1) id AA00887; Thu, 17 Mar 94 19:36:18 EST Date: Thu, 17 Mar 94 19:36:18 EST From: brad@fcr.com (Brad Parker) Message-Id: <9403180036.AA00887@stemwinder.fcr.com> To: ietf-ppp@merit.edu Subject: Generic Authentication Protocol (GAP) In the process of trying to support proprietary security systems such as "SecurID", I found that I needed a simple "request-response" protocol which would run during the authentication phase of a PPP session. To that end, I've written a draft of a "Generic Authentication Protocol" for PPP. It's very simple, but I've found (so far) that it will support systems like SecurID. I hope to also support Kerberos with it (but I must admit to knowing *nothing* about Kerberos). It's my hope that others may also find it useful. In any case, if you are interested in this, the draft will be called "" and should pop out on the ietf mailing list and ftp repositories shortly. I'd like to have a quick discussion on this at the next IETF in Seattle. Fred has added an item to the agenda to cover this (thanks!). -brad Brad Parker FCR Software, Inc. - - - - - - - - - - - - - - - - - From list-admin Thu Mar 17 20:40:09 1994 Received: from pm002-13.dialip.mich.net (pm002-13.dialip.mich.net [35.1.48.94]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA24131 for ; Thu, 17 Mar 1994 20:40:07 -0500 Date: Fri, 18 Mar 94 01:22:23 GMT From: "William Allen Simpson" Message-ID: <2084.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Cc: Rick Stevens Reply-to: bsimpson@morningstar.com Subject: IPXCP Question > From: Rick Stevens > > Hi Bill, > > While reading the rfc1552 (IPXCP), i notice that the IPX-Router-Name > can contain characters A->Z, _, -, and @. But my Novell > documentation gives example names that have numbers in them like > 'SERVER1'. Is this just an oversight or did someone have a reason > during the standardization process for excluding numbers? > > Thanks, > -rick > > Rick Stevens; rcstevens@eng.xyplex.com > Xyplex > Littleton, MA > No reason. I just did what I was told. Anybody else out there want a change in the next version? Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri Mar 18 11:41:58 1994 Received: from newsun (newsun.Novell.COM [130.57.4.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA01492 for ; Fri, 18 Mar 1994 11:41:57 -0500 Received: from va.SJF.Novell.COM by newsun (4.1/SMI-4.1) id AA00444; Fri, 18 Mar 94 08:32:35 PST Received: from sjf-dhub.sjf.novell.com by va.SJF.Novell.COM (4.1/SMI-4.1) id AA02258; Fri, 18 Mar 94 08:32:28 PST X-Nvlenv-01Date-Transferred: 18-Mar-1994 8:39:48 -0500; at sjf-domain-hub.Novell X-Nvlenv-01Date-Posted: 18-Mar-1994 08:44:13 -0500; at sjf-mail-engr.Novell To: rcstevens%xap.xyplex.com@sjf-dhub.SJF.Novell.COM Message-Id: Subject: Re: IPXCP Question From: MALLEN@Novell.COM (Allen, Michael) Date: 18 Mar 94 08:39:46 EST In-Reply-To: References: Cc: ietf-ppp%merit.edu@sjf-dhub.SJF.Novell.COM >> While reading the rfc1552 (IPXCP), i notice that the IPX-Router-Name >> can contain characters A->Z, _, -, and @. But my Novell >> documentation gives example names that have numbers in them like >> 'SERVER1'. Is this just an oversight or did someone have a reason >> during the standardization process for excluding numbers? >> >> Thanks, >> -rick >> >> Rick Stevens; rcstevens@eng.xyplex.com >> Xyplex >> Littleton, MA >> >No reason. I just did what I was told. Anybody else out there want a >change in the next version? > >Bill.Simpson@um.cc.umich.edu RFC 1551 (IPXWAN) suffers from the same oversight - a point that was brought to my attention. Numbers are allowed for IPXWAN -- may be they should also be allowed in IPXCP. -------------------------------------------------------------------------- -- Michael Allen (mallen@novell.com) Novell Inc. (408) 577-8412 - - - - - - - - - - - - - - - - - From list-admin Fri Mar 18 13:58:03 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id NAA13809 for ; Fri, 18 Mar 1994 13:58:02 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AE22954; Fri, 18 Mar 94 10:57:57 PST Message-Id: <9403181857.AE22954@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Mar 1994 10:57:42 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: PPP Extensions Agenda at IETF, redux Cc: ietf-announce-post@cnri.reston.va.us I have gotten a few agenda updates, from Brad Parker and Bill Simpson. My agenda includes, at the moment, five subjects and seven documents. I'm changing the order because a WG member has a conflict. We have two sessions (thursday morning and afternoon, last I checked) in which to discuss them. We will discuss in the following order: draft-ietf-pppext-lcp-fs-00.txt Simpson draft-ietf-pppext-hdlc-fs-00.txt Take the LCP and normal HDLC operation to Full Standard (ta-dah!) draft-ietf-pppext-netbios-fcp-04.txt Dimitri It looks to me like Shiva and Microsoft have some disagreements here, although Thomas assures me that they don't; Marty et al havn't replied to my poll. So, this is the opportunity to change anything that needs to be changed prior to saying "ship it!" draft-ietf-pppext-dataencap-02.txt Halpern draft-ietf-pppext-frame-relay-02.txt Simpson This is the reconciliation of the IPLPDN/PPP issue we have discussed. I expect to spend the bulk of the morning meeting on this. I see no reason that we cannot complete this at this IETF. draft-ietf-pppext-multilink-07.txt Sklower I expect to spend the bulk of the afternoon meeting on this. I see no reason that we cannot complete this at this IETF. draft-ietf-pppext-gap-auth-00.txt Parker Brad wants to discuss authentication by other mechanisms; I have had some other comments about authentication, so let's kick this one around. ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Fri Mar 18 15:29:32 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id PAA22238 for ; Fri, 18 Mar 1994 15:29:31 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08926; 18 Mar 94 13:36 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-gap-auth-00.txt Date: Fri, 18 Mar 94 13:36:16 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403181336.aa08926@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The Generic Athentication Protocol (GAP) Author(s) : B. Parker Filename : draft-ietf-pppext-gap-auth-00.txt Pages : 8 Date : 03/17/1994 The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines a generic protocol for Authentication: the Generic Authentication Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-gap-auth-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-gap-auth-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940317160218.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-gap-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-gap-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940317160218.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Fri Mar 18 20:23:26 1994 Received: from pm002-00.dialip.mich.net (pm002-00.dialip.mich.net [35.1.48.81]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA16883 for ; Fri, 18 Mar 1994 20:23:24 -0500 Date: Sat, 19 Mar 94 00:36:24 GMT From: "William Allen Simpson" Message-ID: <2088.bill.simpson@um.cc.umich.edu> To: ietf-ppp@merit.edu Cc: brad@fcr.com (Brad Parker) Cc: David Carrel Reply-to: bsimpson@morningstar.com Subject: PPP Authentication Protocols For some time, we have been discussing PPP Authentication issues in the NAS WG, which is in the security area. I would prefer that PPP security issues be discussed there, where there are several drafts floating about, rather than the PPP afternoon session, which I cannot attend. The PPP Authentication Protocols have been waiting (and waiting) for the IP Security Architecture proposal from the IRTF. So, no matter what we discuss in the short term, we cannot yet advance new protocols. We can't even advance the old ones. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Fri Mar 18 20:45:20 1994 Received: from large.cisco.com (large.cisco.com [131.108.11.58]) by merit.edu (8.6.5/8.6.5) with ESMTP id UAA18306 for ; Fri, 18 Mar 1994 20:45:19 -0500 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by large.cisco.com (8.6.7/8.6.5) with SMTP id RAA23044; Fri, 18 Mar 1994 17:44:45 -0800 Message-Id: <199403190144.RAA23044@large.cisco.com> X-Authentication-Warning: large.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: bsimpson@morningstar.com cc: ietf-ppp@merit.edu, brad@fcr.com (Brad Parker) Subject: Re: PPP Authentication Protocols In-reply-to: Your message of "Sat, 19 Mar 1994 00:36:24 GMT." <2090.bill.simpson@um.cc.umich.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Mar 1994 17:44:45 -0800 From: David Carrel Well, this is surely a shame. I hate to see things standing still. I still will mail out the draft that I have been working on. Due to UPS (not the delivery company) outages today, I won't be mailing it out 'till Monday. I'll make sure we talk in Seattle. I'd like to understand this better. I'll work on getting some time set aside in NASREQ. Dave > For some time, we have been discussing PPP Authentication issues in the > NAS WG, which is in the security area. I would prefer that PPP security > issues be discussed there, where there are several drafts floating > about, rather than the PPP afternoon session, which I cannot attend. > > The PPP Authentication Protocols have been waiting (and waiting) for the > IP Security Architecture proposal from the IRTF. So, no matter what we > discuss in the short term, we cannot yet advance new protocols. We > can't even advance the old ones. > > Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Sun Mar 20 00:14:25 1994 Received: from pm002-15.dialip.mich.net (pm002-15.dialip.mich.net [35.1.48.96]) by merit.edu (8.6.5/8.6.5) with SMTP id AAA16943; Sun, 20 Mar 1994 00:14:21 -0500 Date: Sun, 20 Mar 94 04:23:20 GMT From: "William Allen Simpson" Message-ID: <2095.bill.simpson@um.cc.umich.edu> To: IETF@CNRI.Reston.VA.US Cc: ietf-ppp@merit.edu Reply-to: bsimpson@morningstar.com Subject: Re: Last Call: PPP Reliable Transmission to Proposed Standard > From: Joachim Martillo Thank you for your thorough ISO review of our document. Again, you illustrate our peril should ISO folks come to the IETF en masse. > ISO 7776-1986(E) obliquely references associating the presence or > absence of flag synchronization with conceptual equivalents of Up and > Down events. > It's hard for me to remember where the ANSI 1978 X.25 precursor stops and ISO LAPB starts, but the CCITT LAPD at hand clearly requires "data link layer/physical layer service primitives", at the "physical layer service access point", has a nice half-page illustration, and references 3 other documents, to tell us we need "PH-DATA-REQUEST/INDICATION", et alia in 6 pages. I think he's right, and said it in fewer words. I'll take this moment to remind the peanut gallery (who often complain how _large_ PPP has grown), that all by itself CCITT Q.921 is _much_ bigger than all the PPP RFCs combined. > On Page 4. > > Window > > Window here is equivalent to ISO 7776-1986 (E) k. Window is usually > associated with packet layer flow control. The draft should be > rewritten to reflect standard usage. > > Maximum number of outstanding I frames k > Yes, I've always found "Maximum number of outstanding I frames k" to be clearer and easier to say than "window". And: > sender should send without receiving an acknowledgement. If > window < 8, then modulo 8 sequencing is used on the link. > Otherwise, modulo 128 sequencing is used. > ... compared with: > sender should send without receiving an acknowledgement. In the > case of ISO 7776-1986 (E) DTE/remote DTE operation, the value of > the DTE k system parameter may be different from the value of the > remote DTE k system parameter. If both DTE k and remote DTE k < 8, > then modulo 8 sequencing is used on the link. > Otherwise, modulo 128 sequencing is used. > ... leaves me with a clear idea which one I'd like to see in a standard. "remote DTE k system parameter" indeed. > ISO 7776-1986 (E) p. 11 states the following. > > For DTE/DTE use (point-to-point non-switched applications), the > assignment of A/B (single link operation) or C/D (multilink operation) > addresses shall be made prior to initialization and should be capable > of being fixed at system generation time. > Fortunately, we're using PPP -- a self-configuring protocol -- and don't have to rely on "assignment ... prior to initialization", and "fixed at system generation time." > The problems described above are sufficiently large that different > implementations of "PPP Reliable Transmission" have a very good chance > of not interoperation. "PPP Reliable Transmission" should not move > into the status of Proposed Standard. > Really? You should show the people who've had it working for 2 years, I think they'd be a bit surprised. Oh, you mean it might not be interoperable with NON-PPP implementations. Do you even have a PPP implementation? > Joachim Martillo > Manager of Internetworking Research > Penril Datability Networks > Penril Datability Advanced Communications Research Center I don't know how Clearpoint ever let you get away.... > 190 N. Main Street > Natick, MA 01760 > And it was such a nice New England town. Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Sun Mar 20 11:54:52 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA21047 for ; Sun, 20 Mar 1994 11:54:52 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA07910; Sun, 20 Mar 94 08:54:40 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf@venera.isi.edu id AA01039; Sun, 20 Mar 94 09:54:06 -0700 Date: Sun, 20 Mar 94 09:54:06 -0700 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9403201654.AA01039@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu, ietf@venera.isi.edu Subject: appology > From: bill.simpson@um.cc.umich.edu (William Allen Simpson) Mr. Martillo's comments may or may not have been technically sound. I cannot tell without expending more effort than PPP over reliable links is worth to me. Without hearing from Mr. Martillo, it is difficult to know if Mr. Simpson's unnecessarily sarcastic but somewhat responsive technical comments address Mr. Marillo's concerns. > ... > I don't know how Clearpoint ever let you get away.... > ... > And it was such a nice New England town. Because of some unfortunate history, there might be several readers of the PPP mailing list who would be careful about responding to Mr. Martillo. However, to allow Mr. Simpson's words to stand without repudiation would shame each of us who has contributed to the mailing list. Mr. Simpson's closing words in no way represent my views. If Mr. Martillo understood Mr. Simpson to be speaking as editor of PPP documents and so on my behalf, then I appologize for the offense his words must have given. I hope the leaders of the PPP working group will also repudiate Mr. Simpson's words. There is no doubt that Mr. Simpson's goal was to so anger and irritate Mr. Martillo that he would go away. Mr. Simpson has used that tactic against many others, with distressingly frequent success. That we continue to allow Mr. Simpson to speak for us as editor of PPP documents is terrible. Mr. Simpson's undeniable contributions to the timely completion of the documents are not worth the shame he brings all of us. This childish nastiness is worse than the politics of an ANSI, OSI, or IEEE organization. Mr. Simpson does more to elevate the stature of ISO style standards than Mr. Martillo could ever hope (assuming without clear evidence the correctness of Mr. Simpson's charge to that effect). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 10:17:02 1994 Received: from tsx-11.MIT.EDU (TSX-11.MIT.EDU [18.172.1.2]) by merit.edu (8.6.5/8.6.5) with SMTP id KAA18455 for ; Mon, 21 Mar 1994 10:17:01 -0500 Received: by tsx-11.MIT.EDU with sendmail-5.61/1.2, id AA19659; Mon, 21 Mar 94 10:16:47 EST Date: Mon, 21 Mar 94 10:16:47 EST From: tytso@ATHENA.MIT.EDU (Theodore Ts'o) Message-Id: <9403211516.AA19659@tsx-11.MIT.EDU> To: Vernon Schryver Cc: ietf-ppp@merit.edu, ietf@isi.edu In-Reply-To: Vernon Schryver's message of Sun, 20 Mar 94 09:54:06 -0700, <9403201654.AA01039@rhyolite.wpd.sgi.com> Subject: Re: appology Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 While I can not condone Bill Simpson's response to Mr. Martillo, this is also not Mr. Martillo's first such "contribution" to the IETF list. In my entire career, I have only put two people on my mail sorter's "auto-delete" list. Mr. Martillo was almost #3; the only thing that has saved him from that list is that he's so clueless that the amusement factor is worth the occasional moment or two of my time to glance through his missives. While Bill Simpson's posting was unprofessional, there is at least some part of me that sympathizes with the goal of driving away clearly incompetent people. Perhaps this "childish nastiness" really is worse than the politics of an ANSI, OSI, or IEEE organization. However, while I must agree with you that it would be better if we could get away from such attacks, I would hope that in the process of becoming more civilized, that we continue to be intolerant of technical incompetence, and that we continue to be intolerant of documents which are equally unreadable no matter whether you are a native speaker of English or of French. - Ted - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 11:21:26 1994 Received: from pluto.dss.com (pluto.dss.com [192.41.217.2]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA25497 for ; Mon, 21 Mar 1994 11:21:23 -0500 Received: by pluto.dss.com (4.1/SMI-4.0) id AA07683; Mon, 21 Mar 94 11:17:41 EST Date: Mon, 21 Mar 94 11:17:41 EST From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9403211617.AA07683@pluto.dss.com> To: bsimpson@morningstar.com Cc: IETF@CNRI.Reston.VA.US, ietf-ppp@merit.edu, martillo@pluto.dss.com In-Reply-To: William Allen Simpson's message of Sun, 20 Mar 94 04:23:20 GMT <2095.bill.simpson@um.cc.umich.edu> Subject: Last Call: PPP Reliable Transmission to Proposed Standard Date: Sun, 20 Mar 94 04:23:20 GMT Sender: ietf-request@IETF.CNRI.Reston.VA.US From: William Allen Simpson Reply-To: bsimpson@morningstar.com > From: Joachim Martillo Thank you for your thorough ISO review of our document. Again, you illustrate our peril should ISO folks come to the IETF en masse. This comment is gratuitous. "PPP Reliable Transmission" is explicitly dependent on ISO 7776-1986(E). One would think that good engineering practice would require the Internet Draft be reviewed within the context of reading and understanding the ISO document. Page 1 of "PPP Reliable Transmission" makes the following statement. This document defines a method for negotiating and using Numbered- Mode, as defined by ISO 7776 [2], to provide a reliable serial link. ISO 7776 [2] is defined in References section as follows. [2] ISO 7776, Information Processing Systems - Data Communication - High Level Data Link Control Procedures - Description of the X.25 LAPB-Compatible DTE Data Link Procedures While my opinion of ISO 7776 is not particularly relevant to the review of "PPP Reliable Transmission," I will state for the record that ISO 7776 should never have become an international standard in its current form. The DTE-remote-DTE mode was apparently added to the document very late or as an afterthought and is not well integrated into the text. > ISO 7776-1986(E) obliquely references associating the presence or > absence of flag synchronization with conceptual equivalents of Up and > Down events. It's hard for me to remember where the ANSI 1978 X.25 precursor stops and ISO LAPB starts, but the CCITT LAPD at hand clearly requires "data link layer/physical layer service primitives", at the "physical layer service access point", has a nice half-page illustration, and references 3 other documents, to tell us we need "PH-DATA-REQUEST/INDICATION", et alia in 6 pages. I think he's right, and said it in fewer words. ^^ I assume he refers to D. Rand and the issue under question is the following passage. Control Signals While PPP does not normally require the use of control signals, implementation of Numbered-Mode LAPB or LAPD requires the provision of control signals, which indicate when the link has become connected or disconnected. These in turn provide the Up and Down events to the LCP state machine. There is no mention in ISO 7776 of control signals. Having implemented LAPB and LAPD many times since 1976, I know for a fact that the provision of control signals which indicate when the link has become connected or disconnected is completely unnecessary. In fact in many networks, the control signals are completely untrustworthy for this purpose, and flag synchronization is a better indication of link status. I'll take this moment to remind the peanut gallery (who often complain how _large_ PPP has grown), that all by itself CCITT Q.921 is _much_ bigger than all the PPP RFCs combined. This comment is irrelevant and indicates misspeaking or a lack of understanding. CCITT Q.921 is a packet network relay/access protocol. PPP is point-to-point packet encapsulation. Its primary purpose is the carriage of Q.931 signaling information. Q.921 can do double duty for data carriage and for the transport of signaling information. PPP and Q.921 are not really comparable. In any case, if we ignore for the moment the silliness of this comparison of apples and oranges, I have some doubts about the veracity of Simpson's assertion in the case where the length of the data carriage portion of Q.921 (LAPD) is compared with the length of all the PPP specifications, extensions and drafts, PPP management and compression excluded. > On Page 4. > Window > Window here is equivalent to ISO 7776-1986 (E) k. Window is usually > associated with packet layer flow control. The draft should be > rewritten to reflect standard usage. > Maximum number of outstanding I frames k Yes, I've always found "Maximum number of outstanding I frames k" to be clearer and easier to say than "window". The point is irrelevant. The "PPP Reliable Transmission" document explicitly states a dependency on ISO 7776. "PPP Reliable Transmission" cannot be properly implemented without consulting ISO 7776. The two documents should use the same terminology. And I doubt that ISO will be changing the terminology in ISO 7776 any time soon. And: > sender should send without receiving an acknowledgement. If > window < 8, then modulo 8 sequencing is used on the link. > Otherwise, modulo 128 sequencing is used. ... compared with: > sender should send without receiving an acknowledgement. In the > case of ISO 7776-1986 (E) DTE/remote DTE operation, the value of > the DTE k system parameter may be different from the value of the > remote DTE k system parameter. If both DTE k and remote DTE k < 8, ^^^^ > then modulo 8 sequencing is used on the link. > Otherwise, modulo 128 sequencing is used. > ... leaves me with a clear idea which one I'd like to see in a standard. "remote DTE k system parameter" indeed. The critical issue was the absence of "both" in the "PPP Reliable Transmission" document because this document stated 1) if k (the window) is less than 8, modulo 8 sequencing must be used, 2) receive and transmit k need not be the same and 3) it is not permissible to use modulo 8 sequencing in one direction and modulo 128 sequencing in the other. Conditions 1 and 3 are in contradiction if k in one direction is less than 8 but k in the other direction is greater than 8. The document should simply be emended so that the contradiction is removed. > ISO 7776-1986 (E) p. 11 states the following. > For DTE/DTE use (point-to-point non-switched applications), the > assignment of A/B (single link operation) or C/D (multilink operation) > addresses shall be made prior to initialization and should be capable > of being fixed at system generation time. Fortunately, we're using PPP -- a self-configuring protocol -- and don't have to rely on "assignment ... prior to initialization", and "fixed at system generation time." Sure, PPP can self-configure the address but which address? The CMD or the RSP address. The document must explicitly state which address is being autoconfigured. > The problems described above are sufficiently large that different > implementations of "PPP Reliable Transmission" have a very good chance > of not interoperation. "PPP Reliable Transmission" should not move > into the status of Proposed Standard. Really? You should show the people who've had it working for 2 years, I think they'd be a bit surprised. And this sort of insoucience with respect to explicitness of detail is precisely the problem which writing an explicit standards document address. Of course a small clique who have similar perspective and understanding will always be able to develop interoperable systems. The problems arise when the standard must be implemented outside the confines of the original clique by people who have different perspectives and understanding. Oh, you mean it might not be interoperable with NON-PPP implementations. Interoperability with non-PPP implementations was never the issue. But I should point out that even though CCITT documents are miserable to read, in my experience implementors generally get full interoperability with X.25 far quicker than with PPP even though X.25 is a far more complex protocol and even though there are no X.25 bake-a-thons. Do you even have a PPP implementation? Yes, we do. It is particularly robust and full-featured. An IETF standards guru tried to get PPP to work in the Constellation system but failed miserably. Saul Agronoff of Harris & Jeffries and I made it work. > Joachim Martillo > Manager of Internetworking Research > Penril Datability Networks > Penril Datability Advanced Communications Research Center I don't know how Clearpoint ever let you get away.... > 190 N. Main Street > Natick, MA 01760 And it was such a nice New England town. Bill.Simpson@um.cc.umich.edu In general, the tone of Bill Simpson's response was not consistent with good engineering practices. Normally, I accept that e-mail discussions can turn rather ballistic rather quickly, but in this case a final review of the document was actively solicited. This attitude which Simpson and other IETF standards gurus continually evince that only a member of the clique may dare to participate in the analysis of these standards is a major problem with the IETF. Joachim Martillo - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 12:54:06 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA04307 for ; Mon, 21 Mar 1994 12:54:05 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB17454; Mon, 21 Mar 94 09:53:29 PST Message-Id: <9403211753.AB17454@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Mar 1994 09:53:31 -0800 To: Vernon Schryver , ietf-ppp@merit.edu, ietf@isi.edu From: fbaker@acc.com (Fred Baker) Subject: Re: appology >Mr. Simpson's closing words in no way represent my views. If Mr. >Martillo understood Mr. Simpson to be speaking as editor of PPP >documents and so on my behalf, then I appologize for the offense his >words must have given. I hope the leaders of the PPP working group >will also repudiate Mr. Simpson's words. I believe that Mr. Simpson was speaking as a member of the working group; I saw nothing in his comments that indicated otherwise. I will echo two sentiments of his that I have offered to Sr. Martillo in the past: those who are critical of standards should participate in the process of getting them right in the first place. I appreciate the thorough technical review. ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 12:53:03 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA04081 for ; Mon, 21 Mar 1994 12:53:02 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB17454; Mon, 21 Mar 94 09:52:32 PST Message-Id: <9403211752.AB17454@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Mar 1994 09:52:22 -0800 To: bsimpson@morningstar.com From: fbaker@acc.com (Fred Baker) Subject: Re: Last Call: PPP Reliable Transmission to Proposed Standard Cc: ietf-ppp@merit.edu, iesg@cnri.reston.va.us Bill: Thanks for your review of Joachim's comments. I think you are suggesting that we pick up the following changes: Am I correct? ============================================================================= Fred Baker (fbaker@acc.com) Advanced Computer Communications - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 15:02:06 1994 Received: from ftp.com (ftp.com [128.127.2.122]) by merit.edu (8.6.5/8.6.5) with SMTP id PAA16309 for ; Mon, 21 Mar 1994 15:02:05 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 21 Mar 1994 15:01:14 -0500 Received: from stev.d-cell.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA06246; Mon, 21 Mar 94 15:00:28 EST Date: Mon, 21 Mar 94 15:00:28 EST Message-Id: <9403212000.AA06246@mailserv-D.ftp.com> To: martillo@pluto.dss.com Subject: Re: Last Call: PPP Reliable Transmission to Proposed Standard From: stev@ftp.com (stev knowles) Cc: bsimpson@morningstar.com, IETF@CNRI.Reston.VA.US, ietf-ppp@merit.edu, martillo@pluto.dss.com Sender: stev@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Mon Mar 21 15:00:20 1994] Originating-Client: d-cell.ftp.com Content-Length: 2614 >In general, the tone of Bill Simpson's response was not consistent >with good engineering practices. Normally, I accept that e-mail >discussions can turn rather ballistic rather quickly, but in this case >a final review of the document was actively solicited. This attitude >which Simpson and other IETF standards gurus continually evince that >only a member of the clique may dare to participate in the analysis of >these standards is a major problem with the IETF. > >Joachim Martillo allow me a few statements, and, to avoid confusion, all readers should realize that i have my IESG Internet Area AD hat firmly pushed down on my head, almost blocking my eyes (since i inherited the hat from noel chiappa, and my ego is not as large, the hat is a mite big). i read bill simpson's note as reflecting his own views. i would note that mr simpson is not the author of the document, david rand is. i would not refer to bill as the PPP editor, rather i woudl refer to him as a prolific contributor. i dont appreciate the tone of bill's note, but this is a free mailing list, and he has the right, and he excercises it. i will note that mr martillo has also excercised his right on this list in the past, unfortunately, in the same manner that bill did today. i would suggest that the only RFC guru's i know are joyce reynolds and jon postel. i woudl certainly not give bill simpson in that title. on the other hand, bill has contributed a great amount to the furthering of the "art" with his contributions and publications. i would also suggest that the IETF does not seem to have the attitude that joachim suggests. rather, i would view the IETF attitude as one of indifference, occasionally raising to a rightous indignation over something that the speaker has ignored until the last possible moment, only to find that the people who have invested the work dont apprecaite that the comments come so late in the process. fortunately, the process is set up to allow mistakes to be caught, even if they are caught late. the process would work much better if people who were interested in technologies paid a bit more attention to the specifications earlier in the cycle. i await the comments of the author, whom i view as the WG's spokesman concerning this document. in closing, i woudl like to remind you all that you are supposedly professionals, and you will find it easier to make your technical opinions understood and accepted if you act as such. the more childish an individual acts, the less likely they are to be taken seriously by the WG. stev knowles one of the IESG Internet Area AD's. - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 15:27:34 1994 Received: from pm002-01.dialip.mich.net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.5/8.6.5) with SMTP id PAA18461; Mon, 21 Mar 1994 15:27:31 -0500 Date: Mon, 21 Mar 94 20:52:17 GMT From: "William Allen Simpson" Message-ID: <2118.bill.simpson@um.cc.umich.edu> To: fbaker@acc.com (Fred Baker) Cc: ietf-ppp@merit.edu, IETF@CNRI.Reston.VA.US Reply-to: bsimpson@morningstar.com Subject: Re: Last Call: PPP Reliable Transmission to Proposed Standard > From: fbaker@acc.com (Fred Baker) > Thanks for your review of Joachim's comments. I think you are suggesting > that we pick up the following changes: > > > > > > > Am I correct? > In the entirety. Actually, there is an issue, raised in his second message. "PPP Reliable Transmission" is explicitly dependent on ISO 7776-1986(E). I don't think there was an intention to dependency. It just referenced a feature or two. If it were dependent, he would have just gone ahead and used 7776 itself, wouldn't he? I received the same comment during the "PPP in HDLC Framing" last call, from Albert Langer in Australia. He felt we were incorporating ISO 3309 by reference, and should only ADD (rather than substract) features. In my latest draft, I clearly state: This should not be construed to indicate that every feature of the above recommendations are included in PPP. Each feature included is explicitly described in the following sections. Maybe we should just start eliminating ISO references? After all, ISO 7776 completely re-specifies ISO 3309 and 4335, as does CCITT Q.921, right down to the FCS series. I think we should, too. This will help get specifications on-line faster, while avoiding copyright problems. We should stop taking shortcuts, like trying to reference the usable parts of ISO. I will try to eliminate as many as I can from PPP LCP and HDLC. As ISO 7776 doesn't claim to be _exactly_ LAPB (only "LAPB-compatible DTE Data Link Procedures"), my next version will be called: "PPP in HDLC-like Framing". Bill.Simpson@um.cc.umich.edu - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 16:53:10 1994 Received: from ginger.lcs.mit.edu (GINGER.LCS.MIT.EDU [18.26.0.82]) by merit.edu (8.6.5/8.6.5) with SMTP id QAA27091 for ; Mon, 21 Mar 1994 16:53:09 -0500 Received: by ginger.lcs.mit.edu id AA26956; Mon, 21 Mar 94 16:52:45 -0500 Date: Mon, 21 Mar 94 16:52:45 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403212152.AA26956@ginger.lcs.mit.edu> To: bsimpson@morningstar.com, martillo@pluto.dss.com Subject: Re: Last Call: PPP Reliable Transmission to Proposed Standard Cc: IETF@cnri.reston.va.us, ietf-ppp@merit.edu, jnc@ginger.lcs.mit.edu >> Maximum number of outstanding I frames k > Yes, I've always found "Maximum number of outstanding I frames k" to be > clearer and easier to say than "window". The "PPP Reliable Transmission" document explicitly states a dependency on ISO 7776. "PPP Reliable Transmission" cannot be properly implemented without consulting ISO 7776. The two documents should use the same terminology. I don't agree. I think it's entirely appropriate to use short, simple, clear, well-understood terms in general use in the industry in place of the term used in the original document, when it helps the clarity of the IETF document. For example, I'm not familiar with 7776, but does it use the term "PDU" for "packet"? Should we use "PDU" because it's in 7776? It would probably be good to make sure the definition of "window" in this I-D includes a sentence like: "This term is used in the document in place of the term 'Maximum number of outstanding I frames k' used in ISO 7776." Once having said that, I think it's entirely desirable to use the simple, clear, "window" thenceforth in that document. In general, the tone of Bill Simpson's response was not consistent with good engineering practices. Well, for me at least, "good engineering practise" doesn't bring to mind rules for interaction among people. Perhaps the term "good manners" is what you were looking for? Noel - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 18:54:26 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA08885 for ; Mon, 21 Mar 1994 18:54:25 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15183; 21 Mar 94 17:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-for-bridging-04.txt Date: Mon, 21 Mar 94 17:29:01 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403211729.aa15183@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Bridging Control Protocol (BCP) Author(s) : F. Baker, R. Bowen Filename : draft-ietf-pppext-for-bridging-04.txt Pages : 31 Date : 03/18/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-for-bridging-04.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-for-bridging-04.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940318142941.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-for-bridging-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-for-bridging-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940318142941.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 19:28:49 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA11244 for ; Mon, 21 Mar 1994 19:28:48 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16663; 21 Mar 94 18:05 EST To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: PPP Bridging Control Protocol (BCP) to Proposed Standard Date: Mon, 21 Mar 94 18:05:26 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9403211805.aa16663@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "PPP Bridging Control Protocol (BCP)" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us, or ietf@cnri.reston.va.us mailing lists by April 11, 1994. IESG Secretary - - - - - - - - - - - - - - - - - From list-admin Mon Mar 21 19:46:52 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id TAA12541 for ; Mon, 21 Mar 1994 19:46:51 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16707; 21 Mar 94 18:06 EST To: IETF-Announce:; Cc: IESG cc: ietf-ppp@merit.edu From: IESG Secretary Subject: Last Call: The PPP Compression Control Protocol (CCP) to Proposed Standard Date: Mon, 21 Mar 94 18:06:05 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9403211806.aa16707@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Point-to-Point Protocol Extensions Working Group to consider "The PPP Compression Control Protocol (CCP)" for the status of Proposed Standard. Associated with the CPP protocol are the following five internet-drafts which will be considered for publication as Informational RFCs: 1. PPP Stacker LZS Compression Protocol 2. PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol 3. PPP Gandalf FZA Compression Protocol 4. PPP Predictor Compression Protocol' 5. PPP BSD Compression Protocol ; Mon, 21 Mar 1994 20:19:49 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16247; 21 Mar 94 17:54 EST To: IETF-Announce:; Cc: Jon Postel -- RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Cc: The Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: PPP over SONET/SDH to Proposed Standard Date: Mon, 21 Mar 94 17:54:47 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9403211754.aa16247@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "PPP over SONET/SDH" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Stev Knowles and David Piscitello. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This specification is intended for those implementations which desire to use the PPP encapsulation over high speed private point-to-point links, such as intra-campus single-mode fiber which may already be installed and unused. Working Group Summary While there is usually large amounts of discussion about every technical issue brought up in the PPPEXT working group, SONET seems to have seen little action on the mailing list or at the meetings. Protocol Quality This document was reviewed by Stev Knowles, Internet Area Director, for the IESG. while there appears to be little current interest in this technology, there appears to be more working going on in SONET/SDH in research institutions at this time. there are currently no known implementations of this specifications, and the AD is not fluent enough in SONET technology to know if the specification is complete enough. The AD feels, however, that the Author, and the PPPEXT working group, have exhibited the attention to detail and thoroughness in their collective works to suggest that this specification move to Proposed Standard status. It is understood by all parties that several independent implementations will be necessary for this to move to Draft Standard. - - - - - - - - - - - - - - - - - From list-admin Tue Mar 22 08:47:52 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id IAA03666 for ; Tue, 22 Mar 1994 08:47:51 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16313; 21 Mar 94 17:56 EST To: IETF-Announce:; Cc: Jon Postel -- RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu Cc: The Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: PPP over ISDN to Proposed Standard Date: Mon, 21 Mar 94 17:56:05 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9403211756.aa16313@IETF.CNRI.Reston.VA.US> The IESG has approved the Internet-Draft "PPP over ISDN" as a Proposed Standard, once the references to "works in progress" are removed. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Stev Knowles and David Piscitello. Technical Summary The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This specification is intended for those implementations which desire to use the PPP encapsulation over ISDN point-to-point links. PPP is not designed for multi-point or multi-access environments. As cited from one of the references, "It is clear that there is never likely to be a single, monolithic, worldwide ISDN." The goal of this document is to describe a few common implementations, chosen from the current wide variety of alternatives, in an effort to promote interoperability. Working Group Summary The PPPEXT working group is never a dull place to be. The working group, as it usually does, has spent a considerable amount of time debating the finer, even the arcane, technical merits of this proposal. Out of these discussions has come a specification of running PPP wover ISDN B channels. The RFC assumes that the reader has some familiarity with ISDN. Protocol Quality This Draft was reviewed by Stev Knowles, Internet Area Director, for the IESG. While not a long specification, it seems reasonably complete. The specification has been implemented by a large number of organizations, with it appearing that some have already shipped product based on this document. Note to RFC Editor: Stev Knowles will work the the I-D author to produce a version of the document which does not include references to Internet-Drafts. - - - - - - - - - - - - - - - - - From list-admin Tue Mar 22 11:39:47 1994 Received: from apache (apache.telebit.com [143.191.3.1]) by merit.edu (8.6.5/8.6.5) with SMTP id LAA19600 for ; Tue, 22 Mar 1994 11:39:41 -0500 Received: from america.Sunnyvale.Telebit.CO (america-bb.sunnyvale.telebit.com) by apache (4.1/SMI-4.1/Telebit-Apache-Brent-930718) id AA09594 to ietf-ppp@merit.edu; Tue, 22 Mar 94 08:39:33 PST Received: from yoyo.telebit.com by america.Sunnyvale.Telebit.COM (4.0/america.telebit.com-DBC-930718) id AA08695 to ietf-ppp@merit.edu; Tue, 22 Mar 94 08:39:30 PST Date: Tue, 22 Mar 94 08:39:30 PST From: mlewis@Telebit.COM (Mark S. Lewis) Message-Id: <9403221639.AA08695@america.Sunnyvale.Telebit.COM> Received: by yoyo.telebit.com (4.1/SMI-4.1) id AA01689; Tue, 22 Mar 94 08:39:30 PST To: ietf-ppp@merit.edu Subject: PPP interoperability testing at Microsoft April 18-22, 1994 Reply-To: Mark.S.Lewis@Telebit.COM Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII -- Open Invitation -- PPP Interoperability Testing Session The next PPP interoperability testing session will be held at Microsoft's campus in Redmond Washington. The session will be held the week of April 18-22, 1994. This week will be dedicated to testing PPP. The testing of Winsock and TCP/IP stacks will follow. The goals of this event are threefold. 1) Test interoperability in a spirit of cooperation to identify problems and limitations. 2) Resolve interoperability problems during the session and later. 3) Identify areas for improvement in the specification of PPP. This event is open to any organization with a PPP implementation. There is no attendence fee required. It will be a strictly technical effort to test interoperability. The results of the testing are provided to participants only and will not be made available to the public. This policy is designed to encourage vendor participation by removing the threat of negative publicity. This is the third such meeting of the PPP Consortium. These testing sessions have proved to be very beneficial to the participants and indirectly to customers. Also, a number of positive articles have been published (Network World and Communications Week) about how the members were working towards greater interoperability. This is good for the participants and the PPP industry in general. General Testing Plan ==================== An interoperability matrix will be compiled. Participants will be matched-up based on what PPP protocols they support over which links (i.e. sync, async, isdn). The primary protocols of interest are: Link Control (LCP), Password Authentication (PAP), Challenge Authentication (CHAP), Link Quality Monitoring (LQM), Internet Protocol (IPCP), AppleTalk (ATKCP), and Novell IPX (IPXCP). The details of the testing plan will be determined based upon the desires of the group. Included below is a proposal by Microsoft on how to test PPP. Please provide comments on the attached questionaire and e-mail it back. Location ======== The PPP testing session will be held in Building 15 at Microsoft's corporate campus. For security reasons, the test room will be open to vendors only between the hours of 8am and 5pm pacific time. Directions from Sea-Tac International Airport: * Follow signs TO FREEWAYS. This puts you on East 518. * Follow signs to INTERSTATE 5 and INTERSTATE 405 * Take NORTH INTERSTATE 405 -- RENTON exit (center lane). Continue on North Interstate 405 through Renton and Bellevue approximately 14 mi. * Take EAST HWY 520 -- REDMOND exit. * Take NE 51st ST exit * Turn right at stop sign onto NE 51st ST. * Turn right at first light onto 156th AVE NE * Turn left at NE 36th ST into the Microsoft PLACE office park Accommodations ============== You will need to make hotel and travel arrangements directly with any of the hotels in the Seattle area and your favorite airline. The Residence Inn 14455 NE 29th Place Bellevue (206) 882-1222 The Residence Inn has a block of rooms reserved for this event. You will need to make reservations by April 1, 1994. They are offering a special rate of $89 for studio rooms. Ask for the "PPP Interop" block. You will need to guarantee your room. Equipment Provided by Microsoft Corporation =========================================== * Analog phone lines * Ethernet backbone network * Power and cooling for up to 60 computers in the test room Equipment Provided by Vendors ============================= * Router/host to run PPP (including ethernet/token ring as necessary) * Workstation or PC host (if necessary) * Modems for async testing (if necessary) * CSU/DSU for synchronous testing (if necessary) * Helpful debugging equipment, such as line monitors * Appropriate cabling and tools Equipment Delivery ================== Due to limited resources for organizing equipment delivery, we strongly recommend that vendors bring their equipment with them. Portable computers are encouraged. For those of you who need to ship equipment to Microsoft, please send your equipment to: Attn: Patrick Awuah, Program Manager Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 For return delivery, please enclose a pre-paid self address federal express mailing slip. Microsoft PPP Test Proposal =========================== In order to better ensure interoperability for our mutual customers, Microsoft is recommending this year that we test three categories of PPP options (Recommended, Desirable, and Work in Progress). This plan is a proposal. Comments and suggestions are welcome. Recommended =========== These are options that we recommend all vendors support. We are not trying to establish conforming vs. non-conforming implementations of PPP. It is up to each vendor to decide whether to implement the following options. At a minimum, implementations that do not support a specific option must reject that option gracefully. Implementations that support a specific option and attempt to communicate with an implementation that rejects the option must handle the rejection gracefully. RFC Protocol Option --- -------- ------------------------------------- 1570 LCP MRU (Max Receive Unit) 1570 LCP ACCM (Async control char mapping - xon/xoff mapped out) 1570 LCP PFC (Protocol field compression - 1 byte compression) 1570 LCP ACFC (Address and control field compression - 2 byte) 1332 IP CP Address assigned by server 1332 IP CP Address requested by client 1144 IP CP Compression (Van Jacobson) 1552 IPX CP 1553 IPX CP IPX header Compression Draft CCP Negotiate Compression 1334 PAP PAP only 1334 CHAP CHAP only 1334 CHAP Negotiate CHAP fall back to PAP Note: Vendors are free to test PPP interoperability with other protocols such as AppleTalk, DECNET, OSI, NetBios, XNS, etc. The list above focuses on the two protocols that are most prevalent today in the PPP arena. Desirable ========= These options are considered desirable but are a lower priority than the options in the "Recommended" section. They will be given lower priority in the test schedule. However, all vendors are encouraged to support these options now or in the near future. As with all other PPP options, rejection of a specific option must be handled gracefully by both the server and client computers. RFC Protocol Option --- -------- ------------------------------------- 1570 LCP Magic Number 1570 LCP Quality Protocol 1570 LCP 32 bit FCS (Frame Check Sequence) Work In Progress ================ These are options that are still in definition stage and as such cannot be considered firm interoperability standards. They will therefore be given lower priority in the test schedule. RFC Protocol Option --- -------- ------------------------------------- Draft NBF CP Draft Multi-Link CP Draft Bridging CP Microsoft Schedule Proposal =========================== Monday AM Setup begins. Set up machines, modems, each vendor's remote workstation connecting to the same vendor's remote server. IP CP setup begins Monday PM IP CP testing begins Tuesday AM IP CP testing continues Tuesday PM IPX CP setup begins. IPX CP testing begins Wednesday PPP option testing IPX CP continues Thursday Stress test. Send lots of data through dial up links and see if routers perform well. Friday AM Stress testing contininues Friday PM Bake off Ends. Allow afternoon for dismantling and packing equipment RSVP ==== We need to know as soon as possible if your company would like to participate. Please fill out the following questionaire and e-mail it back to bakeoff@microsoft.com. More details will follow shortly. Hope you can make it. Signed, The PPP Consortium and Microsoft Corp. -------------------------- Cut Here ------------------------------ Please e-mail the completed questionaire to bakeoff@microsoft.com. Yes, we would like to participate in the 3rd meeting of the PPP Consortium held at Microsoft Corp. April 18-22, 1994. Company: Address: Address: Address: Address: COMPANY REPRESENTATIVES Name E-mail Voice Fax ==== ------ ----- --- PROTOCOL MEDIA MATRIX (Check the protocols of interest for each link) ------------ Link ----------- Protocol Aync Sync ISDN Other ======== ----- ---- ---- ----- Link Control (LCP) Password Authentication (PAP) Challenge Authentication (CHAP) Link Quality Monitoring (LQM) Internet Protocol (IPCP) AppleTalk (ATKCP) Novell IPX (IPXCP) IPX Header Compression (CIPX) Data Compression (CCP) Xerox NS DECnet Phase IV OSI Network Layer Bridging PDU Other (specify) Commments: -------------------------- Cut Here ------------------------------ Liability Release and Non-Disclosure ==================================== (Please execute and present the following release at the entrance to the PPP interoperability event.) By executing this release and accepting the badge provided to you to use while at the 1994 PPP interoperability event, you are releasing Microsoft Corp. from any liability against lost, stolen, or damaged property, including hardware and software, and against personal injury to you or your employees while at the event. You are solely responsible, and assume all risk, for any loss to yourself, your employees, or your property used at the event. You also release Microsoft Corp. from any and all liability and claims arising from the performance or non-performance of your company's products as it relates to your participation in the 1994 PPP Interoperability event testing. By signing this, you agree to respect the confidentiality of the results of this interoperability testing and the participating vendors' preliminary software. The foregoing is agreed to and accepted. Company: __________________________________ By: __________________________________ Title: __________________________________ Date: __________________________________ -------------------------- Cut Here ------------------------------ - - - - - - - - - - - - - - - - - From list-admin Thu Mar 24 18:33:04 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA16368 for ; Thu, 24 Mar 1994 18:33:04 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07698; 24 Mar 94 11:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-magnalink-00.txt Date: Thu, 24 Mar 94 11:18:55 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403241118.aa07698@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Variable Resource Compression Author(s) : D. Schremp, J. Black, J. Weiss Filename : draft-ietf-pppext-magnalink-00.txt Pages : 6 Date : 03/23/1994 The Point-to-Point Protocol (PPP) provides a standard method of encapsulating multiple protocol datagrams over point-to-point links. The PPP Compression Control Protocol provides a method for negotiating data compression over PPP links. The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-magnalink-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-magnalink-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940323101103.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-magnalink-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-magnalink-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940323101103.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Thu Mar 24 18:32:57 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA16363 for ; Thu, 24 Mar 1994 18:32:55 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07684; 24 Mar 94 11:18 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-aha-auth-00.txt Date: Thu, 24 Mar 94 11:18:46 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403241118.aa07684@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The Arbitrary Handshake Authentication (AHA) protocol Author(s) : D. Carrel Filename : draft-ietf-pppext-aha-auth-00.txt Pages : 16 Date : 03/23/1994 The Point-to-Point Protocol (PPP) provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol. This document describes a new authentication mechanism: the Arbitrary Handshake Authentication (AHA) protocol. AHA seeks to provide for arbitrary length authentication handshakes and an authentication abstraction that allows the PPP client and server implementations to provide authentication service while knowing as little as possible of the details of the authentication protocol. AHA is not an authentication protocol but rather is a carrier for authentication protocols. AHA adds an additional protocol negotiation phase in order to add the principal's declared identity into the decision of which authentication protocol to use. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-aha-auth-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-aha-auth-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940323101226.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-aha-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-aha-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940323101226.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Thu Mar 24 22:07:32 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id WAA02411 for ; Thu, 24 Mar 1994 22:07:30 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB25659; Thu, 24 Mar 94 19:06:50 PST Message-Id: <9403250306.AB25659@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Mar 1994 19:06:36 -0800 To: dlr@daver.bungi.com (Dave Rand) From: fbaker@acc.com (Fred Baker) Subject: Re: I-D ACTION:draft-ietf-pppext-magnalink-00.txt Cc: ietf-ppp@merit.edu, stev@ftp.com Dave: Magnalink has posted yet another compression algorithm. Could you look this over? seems like the right way to handle this, given your concurrence, is to ask the RFC editor to handle this along with the other compression algorithms, and to ask IANA to assign a compression type... At 11:18 AM 3/24/1994 -0500, Internet-Drafts@CNRI.Reston.VA.US wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Point-to-Point Protocol >Extensions Working Group of the IETF. > > Title : PPP Variable Resource Compression > Author(s) : D. Schremp, J. Black, J. Weiss > Filename : draft-ietf-pppext-magnalink-00.txt > Pages : 6 > Date : 03/23/1994 > >The Point-to-Point Protocol (PPP) provides a standard method of >encapsulating multiple protocol datagrams over point-to-point links. The >PPP Compression Control Protocol provides a method for negotiating data >compression over PPP links. > >The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide >range of interoperable compression implementations whose performance >characteristics are a function of available CPU and memory resources. > >Internet-Drafts are available by anonymous FTP. Login with the >username "anonymous" and password "guest". After logging in, >Type "cd internet-drafts". > "get draft-ietf-pppext-magnalink-00.txt". > >Internet-Drafts directories are located at: > > o US East Coast > Address: ds.internic.net (198.49.45.10) > > o US West Coast > Address: ftp.isi.edu (128.9.0.32) > > o Pacific Rim > Address: munnari.oz.au (128.250.1.21) > > o Europe > Address: nic.nordu.net (192.36.148.17) > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ds.internic.net. In the body type: > "FILE /internet-drafts/draft-ietf-pppext-magnalink-00.txt". > >For questions, please mail to Internet-Drafts@cnri.reston.va.us. > > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the Internet-Draft. > >Content-Type: text/plain >Content-ID: <19940323101103.I-D@CNRI.Reston.VA.US> > >[This attachment must be fetched by mail. >Open the stationery below and send the resulting >message to get the attachment.] >Attachment converted: Data:I-D ACTION-draft-ietf-pppext- 4 (EuSn/CSOm) >(000025E9) >Content-Type: Message/External-body; > name="draft-ietf-pppext-magnalink-00.txt"; > site="ds.internic.net"; > access-type="anon-ftp"; > directory="internet-drafts" > >Content-Type: text/plain >Content-ID: <19940323101103.I-D@CNRI.Reston.VA.US> _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... - - - - - - - - - - - - - - - - - From list-admin Fri Mar 25 01:26:00 1994 Received: from daver.bungi.com (daver.bungi.com [192.216.238.2]) by merit.edu (8.6.5/8.6.5) with SMTP id BAA14878 for ; Fri, 25 Mar 1994 01:25:56 -0500 Received: by daver.bungi.com (Smail3.1.28.1 #1) id m0pk5Kd-0000ChC; Thu, 24 Mar 94 22:25 PST Message-Id: From: dlr@daver.bungi.com (Dave Rand) Date: Thu, 24 Mar 1994 22:25:20 PST In-Reply-To: Fred Baker's message on Mar 24, 19:06. X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: fbaker@acc.com (Fred Baker) Subject: Re: I-D ACTION:draft-ietf-pppext-magnalink-00.txt Cc: ietf-ppp@merit.edu, stev@ftp.com [In the message entitled "Re: I-D ACTION:draft-ietf-pppext-magnalink-00.txt" on Mar 24, 19:06, Fred Baker writes:] > > Magnalink has posted yet another compression algorithm. Could you look this > over? seems like the right way to handle this, given your concurrence, is > to ask the RFC editor to handle this along with the other compression > algorithms, and to ask IANA to assign a compression type... > Looks ok to me, except for the "more legal stuff goes here..." comment. Either delete it, or fill it in. -- Dave Rand Internet: dlr@daver.bungi.com - - - - - - - - - - - - - - - - - From list-admin Fri Mar 25 14:45:06 1994 Received: from localhost (ljb@localhost) by merit.edu (8.6.5/8.6.5) with SMTP id OAA13825; Fri, 25 Mar 1994 14:45:04 -0500 Message-Id: <199403251945.OAA13825@merit.edu> To: ietf-ppp@merit.edu, nas-req@merit.edu Date: Fri, 25 Mar 1994 14:45:01 -0500 From: "Larry J. Blunk" An Internet Draft has been submitted for the PPP Kerberos Authentication Protocol. Given that this may not show up in the internet drafts archive before the IETF meeting, I've placed a copy on merit.edu in the /pub/ppp directory. -Larry Blunk Merit Network, Inc. - - - - - - - - - - - - - - - - - From list-admin Fri Mar 25 18:17:25 1994 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by merit.edu (8.6.5/8.6.5) with SMTP id SAA02014 for ; Fri, 25 Mar 1994 18:17:25 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16252; 25 Mar 94 16:57 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: ietf-ppp@merit.edu From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-pppext-kap-auth-00.txt Date: Fri, 25 Mar 94 16:57:36 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9403251657.aa16252@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP Kerberos Authentication Protocol (KAP) Author(s) : L. Blunk, J. Vollbrecht Filename : draft-ietf-pppext-kap-auth-00.txt Pages : 15 Date : 03/25/1994 The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the Kerberos Authentication Protocol. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-pppext-kap-auth-00.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-kap-auth-00.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940325151356.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-ietf-pppext-kap-auth-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-kap-auth-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940325151356.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From list-admin Tue Mar 29 12:57:17 1994 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by merit.edu (8.6.5/8.6.5) with SMTP id MAA09203 for ; Tue, 29 Mar 1994 12:57:17 -0500 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (931110.SGI/910110.SGI) for ietf-ppp@merit.edu id AA28896; Tue, 29 Mar 94 09:57:04 -0800 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:ietf-ppp@merit.edu id AA02085; Tue, 29 Mar 94 10:56:27 -0700 Date: Tue, 29 Mar 94 10:56:27 -0700 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9403291756.AA02085@rhyolite.wpd.sgi.com> To: ietf-ppp@merit.edu Subject: Re: PPP LCP Extensions for ISDN > From: knx@ess.cs.ucl.ac.uk (kn-X) > ... > We (KNX Ltd) are using PPP for LAN bridging over ISDN. We have found that a > big problem in inter-working in this case is with the "cost saving" feature > of temporarily dropping the call when the link is idle, and then automatically > re-connecting it when data is to be transmitted. With this feature, > protocol sessions using the link are kept alive whilst the link is down, > and do not know that it has been dropped. > > The problem comes about because there is no way to differentiate the link > being dropped for this reason from final call termination. > > I would like to suggest the following new LCP requests: > > Suspend Request / Suspend Acknowledge > This would request that the PPP call be temporarily terminated without > clearing down any protocol sessions using the link. Parameters (which > could be negotiated) could include: > - The maximum time before the connection will be resumed > (in case one end dies whilst the call is suspended). > - Possibly an indication of the protocol sessions which are to > be kept alive whilst the call is suspended. > > Resume Request / Resume Acknowledge > This would resume a suspended call. > > This will give the two ends a controlled method of temporarily dropping a > PPP connection without the current problem of one end wondering why the > call has been terminated. How do the machines that are creating and dropping the PPP link know anything about any "protocol sessions"? They might if the applications are running on them, so that the network topology is exceptionally trivial. If the machines are only acting as bridges or routers, then how do they know much of anything? I presume my demand-dialing PPP code is like most people's. When there is more traffic than can fit on the current combination of links (modem, ISDN, whatever), it brings up another, subject to a configurable maximum. When more than a configurable minimum links are active, and it looks if too much bandwidth is committed for the current raffic, it takes it down a link. There is configurable hysteresis in both directions. It snoops inside of TCP headers for VJ-compression and for an unreliable indication of TCP circuits in order to adjust the tear-down hysterisis. (I'm foolishly proud of that idea of using the VJ compression state to infer a little about future activity.) Your code must be different. How do you get a reliable indication into PPP about "protocol sessions"? Why does the other end "wonder why the call has been terminated"? Why does it care whether there will be no more application traffic or your friendly phone person has decided to borrow your pairs and the link will be restored as soon as possible? What do you do about authentication? Don't you have to do all of the LCP, authentication, CCP, multilink negotiations identically when "[resuming] a suspended call"? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From list-admin Tue Mar 29 14:50:49 1994 Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by merit.edu (8.6.5/8.6.5) with SMTP id OAA18508; Tue, 29 Mar 1994 14:50:47 -0500 Received: by darkstar.isi.edu (5.65c/5.61+local-16) id ; Tue, 29 Mar 1994 11:50:46 -0800 Date: Tue, 29 Mar 1994 11:50:46 -0800 Message-Id: <199403291950.AA19080@darkstar.isi.edu> From: Clifford Neuman To: carrel@cisco.com, ljb@merit.edu, jrv@merit.edu Subject: Comments on KAP and AHA Cc: ietf-ppp@merit.edu, nas-req@merit.edu I have read through the drafts of the KAP authentication, and the AHA authentication for PPP. My general feeling between them is that I would like to see the KAP stuff included as part of the AHA draft, rather than appearing separately. I also think that the the specification for the use of Kerberos in AHA is better than that in KAP. First, some thoughts on KAP spec. Wherever identifier is specified, it states that it must be changed each time an initiate is sent. It also states that the initiate might have to be retried. Does the identifier have to change on retries of an attempt to initiate the same association? In section 2.2.2, you separate the principal name into a name, instance and realm. This is fine for V4, but not for V5, where the name and instance have been replaced with a variable length sequence of strings. In section 2.2.6, on page 13, under value, you indicate that the response value is the des encryption of the challenge value, but you do not say what mode of encryption is used. Is it CBC, and if so, what is the IV. I much prefer the way that this was specified in the AHA spec. That is it wasn't, Instead the AHA spec for Kerberos actually uses the Kerberos routines to generate and verify the authenticator, instead of rolling its own. Now for my comments on the AHA specification of Kerberos authentication. I really like this specification. For the list of algorithms in 2.2.1, I would eventually add an algorithm for GSSAPI. Unfortunately, GSSAPI does not define how one obtains credentials from an authentication server, so you might not be able to define this right away. So certainly in the meantime, you should support Kerberos V4 and V5 directly as you have proposed to do. In 2.2.3.3 on page 12, when you show the response to the peer, you return two sets of credentials. This is fine, but you might want to make it clear that to obtain the K_(user,NAS), the authenticator (NAS) is actually making a second "initial" authentication request, instead of using the more traditional approach of obtaining the TGT, then using that to get the ticket for the NAS (which it can't do, since the authenticator correctly does not have the peers key, needed to use the TGT) On the issue of the timestamp in this section, and later in the document, I think it is a mistake to trust the timestamp from the authenticator, even after mutual authentication is complete. The reason is that the authenticator may have been compromised. It is not as secure as the KDC itself. You would like to limit what can be done by a compromised NAS. Without setting the time from the NAS, the compromised NAS is no more dangerous than a compromised router. That is if the client uses end-to-end security, the NAS can not impersonate the client. But, if the NAS can change the timestamp on the client, then it might be able to compromise the client (whether this is really possible depends on quite a number of factors). However, the client might be able to set its time based on the authtime timestamp in the encrypted part of the response from the KDC, which in V5 is accompanied by a client generated nonce which should be verified before doing this. This will allow synchronization to the time on the KDC, which can be considered trusted. In Section 2.2.3.3.1, on preauthentication support. Although it is indicated that this is not finished, I think a better way to handle this is to pass through as a ServerMsg, any KDC_ERR_PREAUTH_REQUIRED Kerberos error messages, complete with the e-data field of the error, which contains the server supplied parameters for preauthentication. This would then be followed by a ClientResponse including the preauthentication data to be sent to the KDC in the request, perhaps separately, or perhaps with a new set of parameters that were sent in the begin packet (we need to think about this some more to decide if these are likely to change as a result of the preauthentication request). Handling preauthentication this way, means that the peer (the client) must know how to handle any preauthentication that the KDC might require of it (which the KDC might base on the identity of the client). I think this is the right place, though. The authenticator (the NAS) should not have to know about specific preauthentication methods. In section 2.2.3.5 and 6, I am not sure what these methods are (since they are under development). I assume, however, that they are simple handshake assuming that key distribution was handled by out of band means. This is similar to CHAP, right? Under security considerations, I already discussed the timestamp and clock setting issue earlier in my comments. ~ Cliff - - - - - - - - - - - - - - - - - From list-admin Thu Mar 31 20:41:32 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA25014 for ; Thu, 31 Mar 1994 20:41:31 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB20156; Thu, 31 Mar 94 17:41:27 PST Message-Id: <9404010141.AB20156@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Mar 1994 17:40:35 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: RFC 1333: PPP Link Quality Monitoring Bill: About 18 months have elapsed since RFC 1333 was published; I would like to advance it to Draft Standard. Could you please advise me: who has implemented it? has it proven interoperable? are there any issues that require RFC 1334 to be updated? _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... - - - - - - - - - - - - - - - - - From list-admin Thu Mar 31 20:29:43 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA24010 for ; Thu, 31 Mar 1994 20:29:42 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB20070; Thu, 31 Mar 94 17:29:37 PST Message-Id: <9404010129.AB20070@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Mar 1994 17:28:44 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: HDLC document to Full Standard To take this document to Full Standard, I need two interoperable octet synchronous (SONET or ISDN) implementations. Would octet synchronous folks please contact me? _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... - - - - - - - - - - - - - - - - - From list-admin Thu Mar 31 20:29:49 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA24013 for ; Thu, 31 Mar 1994 20:29:48 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB20070; Thu, 31 Mar 94 17:29:43 PST Message-Id: <9404010129.AB20070@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Mar 1994 17:28:51 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: LCP document to Full Standard Will everybody please reply to me whether your implementation is async, octet synchronous, or bit synchronous, and which of the following options it supports: Maximum-Receive-Unit Async-Control-Character-Map Authentication-Protocol Quality-Protocol Magic-Number Protocol-Field-Compression Address-and-Control-Field-Compression If you have two implementations, please reply separately. _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... - - - - - - - - - - - - - - - - - From list-admin Thu Mar 31 20:37:04 1994 Received: from fennel.acc.com (fennel.acc.com [129.192.64.25]) by merit.edu (8.6.5/8.6.5) with SMTP id UAA24600 for ; Thu, 31 Mar 1994 20:37:01 -0500 Received: from by fennel.acc.com (4.1/SMI-4.1) id AB20080; Thu, 31 Mar 94 17:36:54 PST Message-Id: <9404010136.AB20080@fennel.acc.com> X-Sender: fbaker@129.192.64.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Mar 1994 17:36:03 -0800 To: ietf-ppp@merit.edu From: fbaker@acc.com (Fred Baker) Subject: PPP Minutes Minutes of the PPP Working Group 29th IETF, Seattle Fred Baker, Chair PPP Authentication (Lunch invitational meeting 3/28/94 and discussion session 3/30/94) A group of people met for lunch to discuss PPP authentication. This effort is in part an outgowth of the NASREQ Working Group. The people who met were: Andy Nicholson Microsoft Bill Simpson Daydreamer Brad Parker FCP David Carrel Cisco Fred Baker ACC John Vollbrecht Merit Larry Blunk Merit Mike O'Dell Alternet Shirley Sun 3COM/Centrum Ted Ts'o MIT Tim Kolar Cisco Clifford Neuman ISI Three proposals have been posted to Internet Drafts within the last few days for providing enhanced authentication procedures for PPP. These drafts are: draft-ietf-pppext-aha-auth-00.txt Carrel draft-ietf-pppext-gap-auth-00.txt Parker draft-ietf-pppext-kap-auth-00.txt Vollbrecht and Blunk We agreed on certain organizational details and timelines, to whit: - Larry Blunk will create a mailing list ppp-auth@merit.edu for preliminary discussion of this topic by the interested parties, and inform the PPP list of its existence. - David Carrel will edit a "PPP Authentication Requirements" draft to guide the discussion. This should be stable by June 1, preferably earlier. The objective of this document is to provide a problem statement and set of guidelines that will govern the solution. This will be posted as an internet draft. - An editor (to be named) will merge the above proposals in accordance with the agreed requirements and post it as an internet draft by the July IETF meeting. This editor will present a solution to the problem to the PPP working group at that meeting. - after that, discussion of PPP authentication will proceed on the ietf-ppp@merit.edu mailing list and will be an open discussion. - ideally, we should be prepared to advance the current Internet Draft to Proposed Standard status by the winter IETF meeting. - we expect that the documents published as RFCs will include: the requirements document one or more "framework" documents several documents describing individual authentication procedures The model here is PPP compression, which has a number of procedures, mostly covered by patent claims, and mostly proprietary. We wrote one standards track document which indicates how these procedures can be accomodated (PPP CCP), and the various vendors provided FYI description RFCs for their procedures. Here, the supporting RFCs may be FYI or standards track, and may or may not be supplied by vendors. However, the framework is standards track. We also discussed the requirements that we felt needed to be addressed. Points mentioned included: - ARA-like procedures need in-band authentication. The solution MUST enable various procedures to be usable, including but not limited to: password authentication (PAP) challenge authentication (CHAP) Token Card Authentication (SecureId and similar systems) Kerberos 4 and 5 X.509/PEM - we want to specify the behavior on the line, but not the user interface that will supply the tokens used on it. There may, however, be unavoidable user interface implications. - MUST determine the authentication procedure and database based on an identity presented by the system being authenticated; providers often have different authentication databases by peer that need to be inspected. - The actual authentication procedure used MUST NOT be negotiated or announced. - the scheme MUST work for error-prone end users and for automated peers such as dial on demand routers. - whatever solution we come up with MUST cooperate with the larger security and service framework being discussed in other areas. A solution to a small peice of the total problem may be worse than no solution at all. - SHOULD PERHAPS provide, through some mechanism, features like: authentication retry password modification various encryption/privacy procedures call-back General Meeting Thursday March 31 draft-ietf-pppext-lcp-fs-00.txt Simpson draft-ietf-pppext-hdlc-fs-00.txt Take the LCP and normal HDLC operation to Full Standard. Bill will add a sentence to the Authentication section of LCP explaining that the Authentication Option states "you must authenticate with me", and how the authentication phase is intended to proceed and terminate. We will ship this up. Bill will write an informational overview RFC for all of PPP, as some have found a need for an overview. There is a need, in order to go to Full Standard, for one implementation to have implemented the entire standard. Fred Baker will poll the list regarding LCP options and correlate the responses, seeking preferably, one implementation that has implemented all second best, that all options have in fact been implemented. HDLC has a problem in that the same implementation is most unlikely to have implemented async, bit-sync, AND octet sync. The AD advises that two interoperable implementations of each are adequate. Fred Baker will poll the list seeking two octet synchronous implementations. draft-ietf-pppext-dataencap-02.txt Halpern draft-ietf-pppext-frame-relay-02.txt Simpson Joel and Bill will finalize some language in each of these documents and post drafts. We will then start the last call process to go to Proposed Standard on each. draft-ietf-pppext-netbios-fcp-04.txt Dimitri Thomas will add a sentence added defining canonical format and specifying that it should be used, and making a few other editorial changes. NETBIOS name defence will also be beefed up - there is a fair amount of state in name defence, and this needs to be clarified. There needs to be some implementation notes regarding timing in name defence, as the peer needs to be considerate of flooded implementations in generating its multicasts. Specific changes required: define and require cannonical MAC Address format MAC address becomes a boolean option clarify name defence Applicability Statement (dial-in end systems) We will take the updated draft to Proposed Standard. draft-ietf-pppext-gap-auth-00.txt Parker draft-ietf-pppext-kap-auth-00.txt Vollbrecht and Blunk draft-ietf-pppext-aha-auth-00.txt Carrel This is work spun off by NASREQ; Brad reported on the meetings earlier in the week. Narren ? will write an update to call-back; it doesn't quite do the authentication job now, and there is another possible use in dial-up in the face of congestion. This will be discussed on the ppp-auth@merit.edu list and then taken to the main list for wider discussion. draft-ietf-pppext-multilink-07.txt Sklower Compression may be done above or below the link; two protocol identifiers have been assigned. Although this is described in the compression document, there is text left here as this is the one thing that can be in either place. Number space size we will have the following sequence space, with no negotiation: 0 1 2 3 4 5 6 7 8 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|E| reserved | 24 bit sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This preserves memory boundary alignment (needed by many 16 bit controllers) and satisfies the need for a large sequence space in long delay high bandwidth (satellite T3) The two packet loss detection methods (timer based reassembly and and increasing sequence number per link) will be re-organized somewhat reflecting this. Define the concept of "packet migration" and a negotiation that says "I am willing to receive messages out of sequence". Keith will define an option to this effect, and we will get Dave Carr to spell out the algorithms and motivations. Endpoint Identification (what system I am) We agreed to define an LCP option that identifies the endpoint system. it is not authenticated, it is advisory, to help distinguish instances of an entity. Tom Coradetti to provide text. Bundle Identification Option (whom you wish to become part of) Tom Coradetti agrees that authentication should be used to identify the bundle. Tom Coradetti to provide text. Make it clear that padding is a feature specific to the link within the bundle, and that it is required to be done the same way (no pad, self identifying pad, or message with length field) for all messages of a given protocol type on a link. Make it clear in the text that the multi-link specification defines what is happening within a bundle, and that "bundle" is defined by the combination of "authenticated name"-using-"endpoint" pairs. Need to clarify protocol reject: messages received on the bundle should, if rejected, be rejected on the bundle. Keith will outlaw asymetric configurations, where fragmentation and other procedures are only legal in one direction. MLCP may not have LCP Configuration request, ack, or reject, but other messages may run on it. IESG Review of Compression Draft (John Klensin) There is a view that the CCP cannot be standardized because there exist separate compression options. The IESG would like for the working group to select one and make it a requirement of the standard. This is not an IESG "position" at this point, but a major concern. Dave Rand is to clarify the language about exactly what is being standardized. The IESG wants to be able to know what MUST be interoperable for the draft to be considered a Full Standard. Symplex Communications may make its standard licensed for the price of the documentation, and will post a draft indicating that. For the information of the working group, Motorola claims to have a patent on CCP's dictionary reset mechanism... ISDN MIB: Fred Baker to talk to Marshall and Stev about a MIB development. _______________________________________________________________________ "There's nothing like hay when you're thirsty!" The White King... - - - - - - - - - - - - - - - - -