From owner-ietf-ppp@merit.edu Tue Sep 1 02:44:52 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA28278; Tue, 1 Sep 1998 02:44:26 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 02:40:10 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA28238 for ietf-ppp-outgoing; Tue, 1 Sep 1998 02:40:10 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA28234 for ; Tue, 1 Sep 1998 02:40:04 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id XAA21873 for ; Mon, 31 Aug 1998 23:40:04 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Mon, 31 Aug 1998 23:40:03 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC In-Reply-To: <35EB595E.7EFBBB4F@cimaron.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Mon, 31 Aug 1998, Shahrukh Merchant wrote: > [ regarding fixed stuff columns in concatenated mappings: ] > lest it be assumed that this was a recent change, the "bulk fill" > mapping into VC-4-4c and VC-4-16c virtual containers has not changed > since at least the 3/96 publically available version of G.707, and those > containers exclude 3 and 15 fixed stuff columns, respectively. (I've > long since discarded the 3/93 version, but I'm almost sure that these > were clearly specified back then too.) That last comment is correct. The (X-1) fixed stuff columns in a VC-4-Xc were specified in Section 3.1.7 and illustrated in Figure 3-8/G.709 of the 3/93 version of G.709. /cmh - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 10:53:11 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA05867; Tue, 1 Sep 1998 10:50:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 10:41:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA05702 for ietf-ppp-outgoing; Tue, 1 Sep 1998 10:41:57 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA05695 for ; Tue, 1 Sep 1998 10:41:50 -0400 (EDT) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id KAA02138; Tue, 1 Sep 1998 10:41:48 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id KAA12360; Tue, 1 Sep 1998 10:41:48 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: smerchant@cimaron.com Cc: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC References: <35EB595E.7EFBBB4F@cimaron.com> Date: 01 Sep 1998 10:41:48 -0400 In-Reply-To: Shahrukh Merchant's message of Mon, 31 Aug 1998 22:18:06 -0400 Message-ID: Lines: 26 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu Shahrukh Merchant writes: > 3. HDLC FOR PPP MAPPING INTO STS-48c (VC-4-16c) ... > What would be helpful, though, is to eliminate some of the > less-expected-to-be-used HDLC options for the STS-48c case (esp. those > that yield different-length HDLC frames, which is where some of the > complexity comes in). E.g., > - CRC16 vs. CRC32: Require CRC32 always--this also addresses the > concerns of those who are worried about the scrambler interaction. I think this is a really good idea. I'd even like to see it used on slower links, although I'm not sure what the best way would be to handle that, given existing implementations that use 16-bit FCS. > - Address and Control Field "compression": Does this really need to be > optionable? Perhaps it could be specified as always enabled (i.e., no > address and control field) for STS-48c. Or, perhaps, require or recommend that neither Address and Control Field Compression nor Protocol Field Compression ever be used, resulting in a 32-bit-aligned upper layer header. Of course, an implementation can always do this unilaterally by rejecting these options. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 11:39:07 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA07034; Tue, 1 Sep 1998 11:37:31 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 11:33:24 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA06874 for ietf-ppp-outgoing; Tue, 1 Sep 1998 11:33:23 -0400 (EDT) Received: from algw2.lucent.com (algw2.lucent.com [205.147.213.2]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA06870 for ; Tue, 1 Sep 1998 11:33:12 -0400 (EDT) From: manchester@bell-labs.com Cc: smerchant@cimaron.com, ietf-ppp@merit.edu Received: from hotair.hobl.lucent.com by alig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id LAA27739; Tue, 1 Sep 1998 11:43:26 -0400 Received: from camus.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id LAA17737; Tue, 1 Sep 1998 11:32:24 -0400 Message-ID: <35EC1374.9DBCC0D1@bell-labs.com> Date: Tue, 01 Sep 1998 11:32:05 -0400 Original-From: James Manchester Reply-To: manchester@bell-labs.com Organization: Advanced Optical Data Networking X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: Karl Fox Original-CC: smerchant@cimaron.com, ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC X-Priority: 3 (Normal) References: <35EB595E.7EFBBB4F@cimaron.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Karl Fox wrote: > Shahrukh Merchant writes: > > 3. HDLC FOR PPP MAPPING INTO STS-48c (VC-4-16c) > ... > > What would be helpful, though, is to eliminate some of the > > less-expected-to-be-used HDLC options for the STS-48c case (esp. > those > > that yield different-length HDLC frames, which is where some of the > > complexity comes in). E.g., > > - CRC16 vs. CRC32: Require CRC32 always--this also addresses the > > concerns of those who are worried about the scrambler interaction. > > I think this is a really good idea. I'd even like to see it used on > slower links, although I'm not sure what the best way would be to > handle that, given existing implementations that use 16-bit FCS. > I think the existing implementations that only use 16-bit FCS are OC-3 only? Can anyone confirm or deny? Perhaps we should require for OC-12, and OC-48, one should go with the 32-bit FCS. New OC-3 implementations will be the only ones that need to support both. Note that this doesn't create an interworking problem as an STS-3c cannot be connected to an STS-12c, or an STS-48c. I know this should be obvious, but I think it helps to state it anyway. > > - Address and Control Field "compression": Does this really need to > be > > optionable? Perhaps it could be specified as always enabled (i.e., > no > > address and control field) for STS-48c. > > Or, perhaps, require or recommend that neither Address and Control > Field Compression nor Protocol Field Compression ever be used, > resulting in a 32-bit-aligned upper layer header. Of course, an > implementation can always do this unilaterally by rejecting these > options. > -- > Karl Fox, servant of God, employee of Ascend Communications > 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 > 4041 I agree with Karl here. No compression would be a nice thing to require/recommend. -- James Manchester manchester@bell-labs.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 12:52:22 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA08662; Tue, 1 Sep 1998 12:50:48 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 12:46:27 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA08562 for ietf-ppp-outgoing; Tue, 1 Sep 1998 12:46:27 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA08555 for ; Tue, 1 Sep 1998 12:46:20 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id JAA27859 for ; Tue, 1 Sep 1998 09:46:19 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Tue, 1 Sep 1998 09:46:19 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On 1 Sep 1998, Karl Fox wrote: > Shahrukh Merchant writes: > > 3. HDLC FOR PPP MAPPING INTO STS-48c (VC-4-16c) > ... > > What would be helpful, though, is to eliminate some of the > > less-expected-to-be-used HDLC options for the STS-48c case (esp. those > > that yield different-length HDLC frames, which is where some of the > > complexity comes in). E.g., [ excellent suggestion to require CRC32 elided ] > > > - Address and Control Field "compression": Does this really need to be > > optionable? Perhaps it could be specified as always enabled (i.e., no > > address and control field) for STS-48c. > > Or, perhaps, require or recommend that neither Address and Control > Field Compression nor Protocol Field Compression ever be used, > resulting in a 32-bit-aligned upper layer header. [ ... ] It is definitely preferable for the Address and Control Field always to be present to ensure that the upper layer data is 32-bit aligned. > [ ... ] Of course, an > implementation can always do this unilaterally by rejecting these > options. PPP over SONET test equipment, however, has to support whatever the specification permits. It's much easier on those of us who design test sets if options which are not useful are banned outright. (Consider how much more complicated it is to implement a pattern match to specific higher-layer header fields if the higher-layer header is preceded by a variable-length string of bytes.) Another option which seems to be permitted (correct me if I misread RFC 1662 on this point) but which is clearly useless for PPP over SONET is the Async Control Character Map. Again, no implementation is obliged to accept a non-zero value for the ACCM, but PPP over SONET test gear must be engineered to handle it if the spec allows it. It would be a lot simpler (at all speeds) if a non-zero ACCM was simply banned outright on SONET links. (If any existing implementation of PPP over SONET supports non-zero ACCM values I'd certainly appreciate being informed.) Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 13:21:40 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA09278; Tue, 1 Sep 1998 13:20:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 13:16:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA09175 for ietf-ppp-outgoing; Tue, 1 Sep 1998 13:15:59 -0400 (EDT) Received: from neonet_server1.nexabit.com (neonetserver1.nexabit.com [209.6.34.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA09168 for ; Tue, 1 Sep 1998 13:15:53 -0400 (EDT) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 1 Sep 1998 13:11:35 -0400 Message-ID: <1180113EC576D011AADE0060975B88B327D787@neonet_server1.nexabit.com> From: Chuck Benz To: ietf-ppp@merit.edu Subject: RE: SONET mappings and HDLC Date: Tue, 1 Sep 1998 13:11:34 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu I have a contrarian view on the CRC16 and Address/Control field compression (in the latter case, we already have heard "get rid of these unused fields" and "leave them for the 32 bit alignment"). The consensus in favor of keeping HDLC-like framing for OC48 in Chicago seemed to be based on a 'stay-the-course, we're close to product' attitude. Because of that, changes should be carefully considered. Is there any precedent in PPP for defaults other than the "standard LCP sync configuration defaults" ? Or is it almost always present, with recommended configuration reached by LCP negotiation ? I think that leaving the text as recommendations is strong enough. If an implementation goes 'lite' with just a CRC16, it can nak the negotiation. Everyone agrees that CRC32 is better, especially with the scrambler present. Address/control compression has proponents and detractors, as we've seen. On the other hand, I have no problem with banning non-zero ACCM - there may be a lot of support for that. (Separate question - is scrambling to be a LCP negotiated parameter, or manual configuration ? I suppose that the C2 value is NOT LCP negotiated.) \chuck benz Nexabit Networks, Inc. cbenz@nexabit.com (508)460-3355 x252 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 14:44:16 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA11091; Tue, 1 Sep 1998 14:42:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 14:38:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA10986 for ietf-ppp-outgoing; Tue, 1 Sep 1998 14:38:16 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA10982 for ; Tue, 1 Sep 1998 14:38:10 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id LAA23259 for ; Tue, 1 Sep 1998 11:38:10 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Tue, 1 Sep 1998 11:38:09 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: RE: SONET mappings and HDLC In-Reply-To: <1180113EC576D011AADE0060975B88B327D787@neonet_server1.nexabit.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 1 Sep 1998, Chuck Benz wrote: > (Separate question - is scrambling to be a LCP negotiated > parameter, or manual configuration ? I suppose that the C2 > value is NOT LCP negotiated.) I don't see how it would be feasible to negotiate scrambling, since both sides have to use it (or not use it) in order to be able to negotiate in the first place. To promote interoperability, the spec should mandate that (a) support for scrambling is REQUIRED; (b) a static configuration to disable scrambling MAY be supported, but if it is, it MUST default to scrambling enabled; (c) implementations MUST set the C2 byte to the correct value for the currently configured scrambling option (0x16 if scrambling is turned on, 0xCF if scrambling is turned off). > > I think that leaving the text as recommendations is strong > enough. If an implementation goes 'lite' with just a CRC16, > it can nak the negotiation. Everyone agrees that CRC32 is > better, especially with the scrambler present. Address/control > compression has proponents and detractors, as we've seen. Again, both sides MUST be using the same CRC in order to be able to negotiate. In order for negotiation to work, there must be a common default value with which both sides start. So you can't get away from having to choose something. If CRC16 is the default, then implementations which support CRC32 have to support CRC16 as well. That would be a pity, considering that CRC32 is preferred. However there is at least one OC-3 implementation whose literature states that scrambling cannot be supported if CRC32 is enabled, so it's probably too late to change this except for speeds higher than OC-3. As a practical matter I have always thought that negotiating the CRC was dangerous -- consider what happens if a non-default value is negotiated, one side reboots and reverts to the default. Static configuration seems much safer. Regardless of whether CRC negotiation is or is not supported, the question remains: for each X, what should be the default CRC that all OC-Xc PPP over SONET implementations MUST support? > > On the other hand, I have no problem with banning non-zero > ACCM - there may be a lot of support for that. I agree with this. From my perspective as a test equipment maker, I could deal with Address and Control Field compression and CRC16/CRC32 options (which might actually be useful) much more readily than with a non-zero ACCM (which is not useful at all). Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 14:51:29 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA11378; Tue, 1 Sep 1998 14:50:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 14:46:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA11181 for ietf-ppp-outgoing; Tue, 1 Sep 1998 14:46:02 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA11175 for ; Tue, 1 Sep 1998 14:45:57 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id OAA11590 for ietf-ppp@merit.edu; Tue, 1 Sep 1998 14:45:57 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA10957 for ; Tue, 1 Sep 1998 14:37:01 -0400 (EDT) Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id OAA12100; Tue, 1 Sep 1998 14:36:14 -0400 Received: from localhost (amalis@localhost) by spice.cascade (8.8.8+Sun/8.8.8) with SMTP id OAA02000; Tue, 1 Sep 1998 14:36:13 -0400 (EDT) X-Authentication-Warning: spice.cascade: amalis owned process doing -bs Date: Tue, 1 Sep 1998 14:36:13 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: manchester@bell-labs.com cc: Karl Fox , smerchant@cimaron.com, ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC In-Reply-To: <35EC1374.9DBCC0D1@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu James et al, > I think the existing implementations that only use 16-bit FCS are OC-3 > only? Can anyone confirm or deny? Perhaps we should require for OC-12, > and OC-48, one should go with the 32-bit FCS. New OC-3 implementations > will be the only ones that need to support both. I would prefer to mandate that PPP over SONET using scrambling MUST also use the 32-bit FCS, to counter scrambling error multiplication. That would leave non-scrambled (RFC 1619) POS as the only potential use of the 16-bit FCS. > I agree with Karl here. No compression would be a nice thing to > require/recommend. Ditto (again, on require). Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 15:42:32 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id PAA12737; Tue, 1 Sep 1998 15:39:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 15:31:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12520 for ietf-ppp-outgoing; Tue, 1 Sep 1998 15:31:46 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12512 for ; Tue, 1 Sep 1998 15:31:36 -0400 (EDT) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id PAA06185; Tue, 1 Sep 1998 15:31:34 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id PAA06081; Tue, 1 Sep 1998 15:31:33 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: "C. M. Heard/VVNET, Inc." Cc: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC References: Date: 01 Sep 1998 15:31:33 -0400 In-Reply-To: "C. M. Heard/VVNET, Inc."'s message of Tue, 1 Sep 1998 11:38:09 -0700 (PDT) Message-ID: Lines: 47 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu "C. M. Heard/VVNET, Inc." writes: > Again, both sides MUST be using the same CRC in order to be able to > negotiate. In order for negotiation to work, there must be a common > default value with which both sides start. So you can't get away > from having to choose something. If CRC16 is the default, then > implementations which support CRC32 have to support CRC16 as well. > That would be a pity, considering that CRC32 is preferred. However > there is at least one OC-3 implementation whose literature states that > scrambling cannot be supported if CRC32 is enabled, so it's probably > too late to change this except for speeds higher than OC-3. > > As a practical matter I have always thought that negotiating the CRC > was dangerous -- consider what happens if a non-default value is > negotiated, one side reboots and reverts to the default. See section 2.1, "FCS-Alternatives" of RFC 1570, "PPP LCP Extensions", for an explanation of how this works. The cases you mention are all covered. > Regardless of whether CRC negotiation is or is not supported, the question > remains: for each X, what should be the default CRC that all OC-Xc PPP > over SONET implementations MUST support? Correct. As the implementation note just before section 2.1.1 of RFC 1570 implies, we can choose different default FCS techniques for each speed, as long as it is not possible for different speeds to interconnect. > > On the other hand, I have no problem with banning non-zero > > ACCM - there may be a lot of support for that. Section 6, "Asynchronous to Synchronous Conversion", of RFC 1570 says To enable this functionality, synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous-to-synchronous converter. That would imply that maybe we shouldn't ban ACCM, although I wouldn't want my salary to depend on sales of a async-serial-to-SONET PPP converter box. :-) -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 22:39:33 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA19219; Tue, 1 Sep 1998 22:39:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 22:38:50 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA19189 for ietf-ppp-outgoing; Tue, 1 Sep 1998 22:38:50 -0400 (EDT) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA19182 for ; Tue, 1 Sep 1998 22:38:45 -0400 (EDT) From: manchester@bell-labs.com Received: from hotair.hobl.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id WAA21404; Tue, 1 Sep 1998 22:59:23 -0400 Received: from camus.hobl.lucent.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id WAA29437; Tue, 1 Sep 1998 22:38:35 -0400 Message-ID: <35ECAF96.AD75A110@bell-labs.com> Date: Tue, 01 Sep 1998 22:38:15 -0400 Original-From: James Manchester Reply-To: manchester@bell-labs.com Organization: Advanced Optical Data Networking X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: "ietf-ppp@merit.edu" Subject: PPP over SONET/SDH Interoperability Issues List X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu We had some good discussions today on PPP over SONET/SDH and I would like to make a first cut at creating a summary list of the issues. I have also listed with the issues what I <> as rough consensus thus far. I am sure there are others that have not spoken and also that my intrepretations may not be the same as other folks'. I know the wording isn't perfect...we can wordsmith the stuff later, but hopefully this will also give us some organization for the ongoing discussion. In general, I think these would also make good issues for applicability RFC, so perhaps Bill would consider drafting them in as we move along? NOTE that I realize that most of this stuff doesn't necessaryily need to be spelled out as an interface can reject many of the options; however, spelling it out may save folks some headaches and makes interoperabilty much more likely (which as it was explained to me is one of the primary goals of an applicability RFC). Issue#1: 1+X**43 Scrambling ----- a. Support is required for OC-3/12/48 concatenated mappings as a default configuration with 0x16 as the value for the C2 byte. b. The scambling may be disabled statically. 1. If scrambling is disabled, the C2 byte shall be coded as 0xCF. c. When using the 1+X**43 scrambler, the entire SONET/SDH payload (SPE minus the path overhead and any fixed stuff) shall be scrambled. An initial seed is unspecified and the scrambler shall run continuously and is not reset per SONET/SDH frame. Issue#2: 16/32 Bit FCS ----- a. OC-3 implementations must support the 16 or 32 bit FCS. 1. For OC-3 the 16 bit FCS is default. 2. Changing to the 32 bit FCS for OC-3 should be done statically. b. OC-12 implementations must support the 32 bit FCS as a default configuration. c. OC-48 implementations must support the 32 bit FCS as a default configuration. Issue#3: Address and Control Field Compression and Protocol Filed Compression ---- a. For OC-3/12/48 signals, Address and Control Field Compression and Protocol Field Compression shall not be used. Issue#4: Async Control Character Map ---- Does anyone wish to propose text for what they interpret as consensus? Issue#5: SONET/SDH Fixed Stuff for Concatenated Signals above OC-3 ---- a. PPP packets shall not be mapped over the fixed stuff for OC-12/48 concatenated mappings. b. When using the 1+X**43 scrambler, the entire SONET/SDH payload (SPE minus the path overhead and any fixed stuff) shall be scrambled. Any other issues folks want to add? -- James Manchester manchester@bell-labs.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 1 23:15:31 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA19638; Tue, 1 Sep 1998 23:15:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 1 Sep 1998 23:15:09 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA19616 for ietf-ppp-outgoing; Tue, 1 Sep 1998 23:15:09 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA19611 for ; Tue, 1 Sep 1998 23:15:02 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id UAA06130 for ; Tue, 1 Sep 1998 20:15:01 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Tue, 1 Sep 1998 20:15:01 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On 1 Sep 1998, Karl Fox wrote: > > > On the other hand, I have no problem with banning non-zero > > > ACCM - there may be a lot of support for that. > > Section 6, "Asynchronous to Synchronous Conversion", of RFC 1570 says > > To enable this functionality, synchronous PPP implementations MUST > always respond to the Async-Control-Character-Map Configuration > Option with the LCP Configure-Ack. However, acceptance of the > Configuration Option does not imply that the synchronous > implementation will do any ACCM mapping. Instead, all such octet > mapping will be performed by the asynchronous-to-synchronous > converter. > > That would imply that maybe we shouldn't ban ACCM, although I wouldn't > want my salary to depend on sales of a async-serial-to-SONET PPP > converter box. :-) What I thought this meant was that a synchronous PPP implementation needs to Configure-Ack the ACCM option when there is an async-to-sync converter in the path, but in this case the converter does the ACCM mapping. Even if a PPP over SONET implementation were not allowed to perform any ACCM mapping, it could still Configure-Ack the ACCM option if such a hypothetical async-serial-to-SONET PPP converter box happened to be installed, because such a box would to do the ACCM mapping :-) I assume that when there is no async-to-sync converter, the usual rules would apply, e.g., a synchronous PPP implementation would have to send Configure-Nak with an ACCM of zero if it did not wish to (or could not) perform ACCM mapping. So banning ACCM for PPP over SONET would imply that a PPP over SONET implementation would not be allowed to Configure-Ack a non-zero ACCM in the absence of an async-to-sync converter. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 2 07:29:13 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA25410; Wed, 2 Sep 1998 07:27:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Sep 1998 07:22:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA25298 for ietf-ppp-outgoing; Wed, 2 Sep 1998 07:22:52 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA25287 for ; Wed, 2 Sep 1998 07:22:46 -0400 (EDT) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id HAA15417; Wed, 2 Sep 1998 07:22:44 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id HAA12862; Wed, 2 Sep 1998 07:22:44 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: "C. M. Heard/VVNET, Inc." Cc: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC References: Date: 02 Sep 1998 07:22:44 -0400 In-Reply-To: "C. M. Heard/VVNET, Inc."'s message of Tue, 1 Sep 1998 20:15:01 -0700 (PDT) Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu "C. M. Heard/VVNET, Inc." writes: > What I thought this meant was that a synchronous PPP implementation > needs to Configure-Ack the ACCM option when there is an async-to-sync > converter in the path, but in this case the converter does the ACCM > mapping. Even if a PPP over SONET implementation were not allowed to > perform any ACCM mapping, it could still Configure-Ack the ACCM option > if such a hypothetical async-serial-to-SONET PPP converter box happened > to be installed, because such a box would to do the ACCM mapping :-) > > I assume that when there is no async-to-sync converter, the usual rules > would apply, e.g., a synchronous PPP implementation would have to send > Configure-Nak with an ACCM of zero if it did not wish to (or could not) > perform ACCM mapping. So banning ACCM for PPP over SONET would imply > that a PPP over SONET implementation would not be allowed to Configure-Ack > a non-zero ACCM in the absence of an async-to-sync converter. Ah, I understand now--I misunderstood what you all were saying. I agree with you that, although PPP over SONET encapsulates by doing octet stuffing, the link is always 100% transparent, therefore there's no need to ever actually byte-stuff (escape) any octets other than 7E (flag) and 7D (escape). I recommend, therefore, that the encapsulation always be done with an effective ACCM of zero, but that ACCM options in Configure-Requests always be simply Acked and the negotiated value ignored. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 2 10:27:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA29869; Wed, 2 Sep 1998 10:27:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Sep 1998 10:25:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA29756 for ietf-ppp-outgoing; Wed, 2 Sep 1998 10:25:27 -0400 (EDT) Received: from banyan.ee.iitm.ernet.in (525@[206.103.12.155]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA29749 for ; Wed, 2 Sep 1998 10:25:14 -0400 (EDT) Received: from localhost by banyan.ee.iitm.ernet.in; (8.8.7/1.1.8.2/14Nov95-0650PM) id TAA05205; Wed, 2 Sep 1998 19:51:01 +0530 Date: Wed, 2 Sep 1998 19:51:01 +0530 (IST) From: Muthu Kumar To: ietf-ppp@merit.edu Subject: Multilink PPP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi Guys Any body working on Multi Link PPP. I like to interact with you guys. I like to know about any public domain implementation of Multilink PPP. As a part of our remote access switc, I am in need of that. Thanks Muthu Kumar S - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 2 10:55:55 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA01278; Wed, 2 Sep 1998 10:55:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Sep 1998 10:54:16 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA01237 for ietf-ppp-outgoing; Wed, 2 Sep 1998 10:54:16 -0400 (EDT) Received: from services.paradyne.com (services.paradyne.com [135.90.253.90]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA01231 for ; Wed, 2 Sep 1998 10:54:08 -0400 (EDT) Received: from hermes.eng.paradyne.com ([135.26.1.14]) by services.paradyne.com (Netscape Messaging Server 3.6) with ESMTP id AAA5D3C for ; Wed, 2 Sep 1998 10:53:32 -0400 Received: from eng.paradyne.com ([135.26.17.199]) by hermes.eng.paradyne.com (8.7.5/8.7.3) with ESMTP id KAA06510 for ; Wed, 2 Sep 1998 10:54:04 -0400 (EDT) Message-ID: <35ED5BC2.8A92AF38@eng.paradyne.com> Date: Wed, 02 Sep 1998 10:52:51 -0400 From: Rollins Turner Organization: Paradyne Corporation X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: ietf-ppp@merit.edu Subject: Revisions to RFC 1483 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu At my presentation on L2TP Over ATM in the Chicage IETF someone mentioned that RFC 1483 was being revised at that same meeting. But I have been unable to find any information about it. Can someone point me to a document or person (i.e. email adr) ? -- Rollins Turner - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 2 12:04:25 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA03516; Wed, 2 Sep 1998 12:03:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Sep 1998 12:01:07 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA03433 for ietf-ppp-outgoing; Wed, 2 Sep 1998 12:01:07 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA03429 for ; Wed, 2 Sep 1998 12:01:03 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id MAA11993 for ietf-ppp@merit.edu; Wed, 2 Sep 1998 12:01:02 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.8.7/8.8.5) with SMTP id LAA02091 for ; Wed, 2 Sep 1998 11:27:11 -0400 (EDT) Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id LAA03503; Wed, 2 Sep 1998 11:26:06 -0400 Received: from localhost (amalis@localhost) by spice.cascade (8.8.8+Sun/8.8.8) with SMTP id LAA03274; Wed, 2 Sep 1998 11:26:05 -0400 (EDT) X-Authentication-Warning: spice.cascade: amalis owned process doing -bs Date: Wed, 2 Sep 1998 11:26:04 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: Rollins Turner cc: ietf-ppp@merit.edu, "Andrew G. Malis" Subject: Re: Revisions to RFC 1483 In-Reply-To: <35ED5BC2.8A92AF38@eng.paradyne.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Rollins, > At my presentation on L2TP Over ATM in the Chicage IETF someone > mentioned that RFC 1483 was being revised at that same meeting. > But I have been unable to find any information about it. Can > someone point me to a document or person (i.e. email adr) ? Dan Grossman is editing the revision. He missed the I-D deadline on his first draft, so it was only sent to the ion list. He expects to get the next revision out pretty soon reflecting the ion wg discussion. I'll forward you his original revision as a private email so as to not clog up the PPP list. If anyone else on the PPP list would like it as well, send me a reply. However, if you can wait, the next revision should be available within a few weeks or so at an internet-drafts directory near you. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 2 17:01:38 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id RAA12548; Wed, 2 Sep 1998 17:00:02 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 2 Sep 1998 16:58:53 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA12491 for ietf-ppp-outgoing; Wed, 2 Sep 1998 16:58:52 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA12483 for ; Wed, 2 Sep 1998 16:58:44 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id NAA09074 for ; Wed, 2 Sep 1998 13:58:40 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Wed, 2 Sep 1998 13:58:39 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: PPP over SONET/SDH Interoperability Issues List In-Reply-To: <35ECAF96.AD75A110@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 1 Sep 1998 manchester@bell-labs.com wrote: [ ... ] > Issue#4: Async Control Character Map > ---- > Does anyone wish to propose text for what they interpret as consensus? How about this (adapted from Karl's suggestion): "The encapsulation shall always be done with an effective ACCM of zero. ACCM options in Configure-Requests shall always be Acked and the negotiated value shall be ignored." Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 3 01:31:49 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA21404; Thu, 3 Sep 1998 01:30:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Sep 1998 01:29:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA21355 for ietf-ppp-outgoing; Thu, 3 Sep 1998 01:29:05 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA21351 for ; Thu, 3 Sep 1998 01:28:58 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id WAA07274; Wed, 2 Sep 1998 22:28:28 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id WAA26704; Wed, 2 Sep 1998 22:38:30 -0700 (PDT) Message-Id: <199809030538.WAA26704@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: heard@vvnet.com (C. M. Heard/VVNET, Inc.) cc: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC In-reply-to: Your message of "01 Sep 1998 18:38:09 GMT." Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 02 Sep 1998 22:38:29 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu > As a practical matter I have always thought that negotiating the CRC > was dangerous -- consider what happens if a non-default value is > negotiated, one side reboots and reverts to the default. Static > configuration seems much safer. It doesn't have to be dangerous, it is just that the very best method of avoiding trouble is probably covered by one of US patents 5307355 or 5553085. Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 3 08:47:26 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id IAA24865; Thu, 3 Sep 1998 08:44:21 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Sep 1998 08:39:43 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA24786 for ietf-ppp-outgoing; Thu, 3 Sep 1998 08:39:43 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA24778 for ; Thu, 3 Sep 1998 08:39:36 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id IAA23677; Thu, 3 Sep 1998 08:39:28 -0400 To: heard@vvnet.com ("C. M. Heard/VVNET, Inc.") cc: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC References: From: James Carlson Date: 03 Sep 1998 08:39:28 -0400 In-Reply-To: heard@vvnet.com's message of 1 Sep 1998 23:32:22 -0400 Message-ID: <863ea9jrpb.fsf@helios.nis.ironbridgenetworks.com> Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu heard@vvnet.com ("C. M. Heard/VVNET, Inc.") writes: > I assume that when there is no async-to-sync converter, the usual rules > would apply, e.g., a synchronous PPP implementation would have to send > Configure-Nak with an ACCM of zero if it did not wish to (or could not) > perform ACCM mapping. So banning ACCM for PPP over SONET would imply > that a PPP over SONET implementation would not be allowed to Configure-Ack > a non-zero ACCM in the absence of an async-to-sync converter. That's not the "usual rule." The rule for all synchronous devices is that you request nothing (no ACCM option in transmitted requests), and ack everything (any ACCM with a valid length is acked), but that you do no escaping at all. There's simply no way to tell if a converter is in place. If you send Configure-Ack for some ACCM, that is not a promise to ever actually omit escaping on an async link. It would be perfectly valid (perhaps silly, but operating within the standards) for an asynchronous PPP implementation to always send Configure-Ack for any received ACCM, but to always transmit frames with the ACCM set to FFFFFFFF. Changing the default behavior here away from RFC 1662 is, I think, a bad thing. I like having portable PPP implementations with as few kludges as possible. I do NOT like having the PPP state machine sniff down at the link to ask silly questions before generating an LCP Configure-Request. This shouldn't be necessary. "Are you an OC-3c? An OC-48c? A modem ... ?" -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 3 11:08:19 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA28468; Thu, 3 Sep 1998 11:07:49 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Sep 1998 11:06:31 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA28419 for ietf-ppp-outgoing; Thu, 3 Sep 1998 11:06:30 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA28411 for ; Thu, 3 Sep 1998 11:06:22 -0400 (EDT) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id LAA05007; Thu, 3 Sep 1998 11:06:18 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id LAA00857; Thu, 3 Sep 1998 11:06:17 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: James Carlson Cc: heard@vvnet.com ("C. M. Heard/VVNET, Inc."), ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC References: <863ea9jrpb.fsf@helios.nis.ironbridgenetworks.com> Date: 03 Sep 1998 11:06:17 -0400 In-Reply-To: James Carlson's message of 03 Sep 1998 08:39:28 -0400 Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu James Carlson writes: > Changing the default behavior here away from RFC 1662 is, I think, a > bad thing. I like having portable PPP implementations with as few > kludges as possible. I do NOT like having the PPP state machine sniff > down at the link to ask silly questions before generating an LCP > Configure-Request. This shouldn't be necessary. "Are you an OC-3c? > An OC-48c? A modem ... ?" Amen to that, brother! -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 3 11:48:33 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA29562; Thu, 3 Sep 1998 11:48:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Sep 1998 11:48:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA29534 for ietf-ppp-outgoing; Thu, 3 Sep 1998 11:48:05 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA29530 for ; Thu, 3 Sep 1998 11:47:59 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id IAA27170 for ; Thu, 3 Sep 1998 08:47:59 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Thu, 3 Sep 1998 08:47:58 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: SONET mappings and HDLC In-Reply-To: <863ea9jrpb.fsf@helios.nis.ironbridgenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On 3 Sep 1998, James Carlson wrote: > The rule for all synchronous devices is that you request nothing (no > ACCM option in transmitted requests), and ack everything (any ACCM > with a valid length is acked), but that you do no escaping at all. In other words, what RFC 1662 (and 1570) is saying is that a synchronous PPP implementation NEVER discards characters in the range 0x00 - 0x1f on receive, is NEVER obliged to escape these characters on transmit, and this cannot be changed by negotiation. That's exactly what I was asking for. Obviously, I misinterpreted the spec; thank you for the correction. > Changing the default behavior here away from RFC 1662 is, I think, a > bad thing. I like having portable PPP implementations with as few > kludges as possible. I do NOT like having the PPP state machine sniff > down at the link to ask silly questions before generating an LCP > Configure-Request. This shouldn't be necessary. "Are you an OC-3c? > An OC-48c? A modem ... ?" I retract any such suggestion. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Thu Sep 3 19:01:00 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA08595; Thu, 3 Sep 1998 19:00:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 3 Sep 1998 18:59:47 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA08554 for ietf-ppp-outgoing; Thu, 3 Sep 1998 18:59:47 -0400 (EDT) Received: from pinky.microsoft.com (pinky.microsoft.com [131.107.1.229]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA08548 for ; Thu, 3 Sep 1998 18:59:41 -0400 (EDT) Received: (from gwz@localhost) by pinky.microsoft.com (8.7.6/8.7.3) id PAA19138 for ietf-ppp@merit.edu; Thu, 3 Sep 1998 15:52:16 -0700 (PDT) Date: Thu, 3 Sep 1998 15:52:16 -0700 (PDT) From: Glen Zorn Message-Id: <199809032252.PAA19138@pinky.microsoft.com> To: ietf-ppp@merit.edu Subject: LCP internationalization option Sender: owner-ietf-ppp@merit.edu I just submitted the latest version of the internationalization draft (draft-ietf-pppext-lcp-charset-03.txt) to the I-D editors. I made the changes discussed in Chicago and change a few names to make things a bit clearer (I hope). One question, though: does/would it make sense for the Language-Tag field to be optional? If it was missing, the language would default to "i-default" expessed in whatever charset was appropriate... - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 00:19:42 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id AAA12437; Fri, 4 Sep 1998 00:19:20 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 00:18:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA12406 for ietf-ppp-outgoing; Fri, 4 Sep 1998 00:18:36 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA12394 for ; Fri, 4 Sep 1998 00:18:29 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id VAA16595 for ; Thu, 3 Sep 1998 21:18:28 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Thu, 3 Sep 1998 21:18:28 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: PPP over SONET/SDH Interoperability Issues List In-Reply-To: <199809031348.JAA28508@luna3.lc.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On 2 Sep 1998, Karl Fox wrote: > I recommend, therefore, that the encapsulation always be done with an > effective ACCM of zero, but that ACCM options in Configure-Requests > always be simply Acked and the negotiated value ignored. On 3 Sep 1998, James Carlson wrote: > The rule for all synchronous devices is that you request nothing (no > ACCM option in transmitted requests), and ack everything (any ACCM > with a valid length is acked), but that you do no escaping at all. On 3 Sep 1998, George Gross wrote: > I placed text in the PPP over ATM draft to say an end point MUST NOT > request ACCM, and it MUST reject it if it is requested. Thus, the ACCM option is handled differently when running over AAL5 or FUNI than when running directly over an octet-synchronous physical layer. An implementation of PPP over AAL5 or FUNI is supposed to reject ACCM, but an implementation of PPP over an octet-synchronous physical layer such as SONET is supposed to accept ACCM but ignore the value (in agreement with RFC 1662 section 6 and also with ). In neither case is any ACCM escaping done. Swift correction requested if I have this wrong. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 10:34:14 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA18500; Fri, 4 Sep 1998 10:31:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 10:12:14 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA18055 for ietf-ppp-outgoing; Fri, 4 Sep 1998 10:12:13 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA18051 for ; Fri, 4 Sep 1998 10:12:10 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA02143 for ietf-ppp@merit.edu; Fri, 4 Sep 1998 10:12:09 -0400 (EDT) Received: from ihgw1.lucent.com (ihgw1.lucent.com [207.19.48.1]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA26487 for ; Thu, 3 Sep 1998 09:49:06 -0400 (EDT) Received: from luna3.lc.lucent.com by ihig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id JAA11571; Thu, 3 Sep 1998 09:15:40 -0500 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id JAA28508; Thu, 3 Sep 1998 09:48:06 -0400 Date: Thu, 3 Sep 1998 09:48:06 -0400 Message-Id: <199809031348.JAA28508@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) To: "C. M. Heard/VVNET, Inc." , ietf-ppp@merit.edu Cc: gmgross@lucent.com Subject: Re: PPP over SONET/SDH Interoperability Issues List Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi, This thread about ACCM option negotiation for a PPP over SONET connection has a strong resemblance to the thread on the ACCM option wrt/ PPP over ATM that occurred in September/October on this list last year. One of the results of that discussion was Bill Simpson's ID on bridging convertors: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-conversion-01.txt Another result of that discussion is that I placed text in the PPP over ATM draft to say an end point MUST NOT request ACCM, and it MUST reject it if it is requested. I also added the following text: When viewed peer to peer, a PPP link may be bridged over multiple physical layer sections. For each such ATM section, the LCP framing options MUST be actively negotiated by the bridging convertors independently of the LCP framing options in use by other physical layer sections. Perhaps comparable text should be placed into the PPP over SONET ID? George - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 11:51:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA20117; Fri, 4 Sep 1998 11:49:15 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 11:43:41 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA19992 for ietf-ppp-outgoing; Fri, 4 Sep 1998 11:43:41 -0400 (EDT) Received: from andes.coppermountain.com (andes.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA19988 for ; Fri, 4 Sep 1998 11:43:35 -0400 (EDT) Received: by andes.coppermountain.com with Internet Mail Service (5.5.2232.9) id ; Fri, 4 Sep 1998 08:46:06 -0700 Message-ID: <31BFB6252086D111ADDF006008932DB51D3EF4@andes.coppermountain.com> From: Eric Michelsen To: ietf-ppp@merit.edu Subject: RE: PPP over SONET/SDH Interoperability Issues List Date: Fri, 4 Sep 1998 08:45:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu > -----Original Message----- > From: C. M. Heard/VVNET, Inc. [mailto:heard@vvnet.com] > Sent: Thursday, September 03, 1998 21:18 > To: ietf-ppp@merit.edu > Subject: Re: PPP over SONET/SDH Interoperability Issues List > > > On 2 Sep 1998, Karl Fox wrote: > > > I recommend, therefore, that the encapsulation always be > done with an > > effective ACCM of zero, but that ACCM options in > Configure-Requests > > always be simply Acked and the negotiated value ignored. > > On 3 Sep 1998, James Carlson wrote: > > > The rule for all synchronous devices is that you request nothing (no > > ACCM option in transmitted requests), and ack everything > (any ACCM > > with a valid length is acked), but that you do no escaping > at all. Isn't this standardized in RFC-1662? > > On 3 Sep 1998, George Gross wrote: > > > I placed text in the PPP over ATM draft to say an end point MUST NOT > > request ACCM, and it MUST reject it if it is requested. Isn't this just an oversight, which conflicts with RFC-1662? > > Thus, the ACCM option is handled differently when running over AAL5 or > FUNI than when running directly over an octet-synchronous physical > layer. An implementation of PPP over AAL5 or FUNI is > supposed to reject > ACCM, but an implementation of PPP over an octet-synchronous physical > layer such as SONET is supposed to accept ACCM but ignore the value > (in agreement with RFC 1662 section 6 and also with > ). In neither case is any ACCM > escaping done. Swift correction requested if I have this wrong. Isn't this unacceptable? How about if we just change the PPP/ATM draft to be consistent with RFC-1662? Why should PPP/ATM be any different than any other synchronous PPP? The whole idea is *interoperability*. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 14:55:12 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA24254; Fri, 4 Sep 1998 14:55:00 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 14:51:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA24143 for ietf-ppp-outgoing; Fri, 4 Sep 1998 14:51:28 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA24137 for ; Fri, 4 Sep 1998 14:51:24 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id OAA18037 for ietf-ppp@merit.edu; Fri, 4 Sep 1998 14:51:24 -0400 (EDT) Received: from algw1.lucent.com (algw1.lucent.com [205.147.213.1]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA23869 for ; Fri, 4 Sep 1998 14:36:04 -0400 (EDT) Received: from luna3.lc.lucent.com by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id OAA03658; Fri, 4 Sep 1998 14:56:31 -0400 Received: by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id OAA27915; Fri, 4 Sep 1998 14:35:14 -0400 Date: Fri, 4 Sep 1998 14:35:14 -0400 Message-Id: <199809041835.OAA27915@luna3.lc.lucent.com> From: gmg@luna3.lc.lucent.com (luna3!gmg) To: Eric Michelsen , ietf-ppp@merit.edu Cc: gmgross@lucent.com Subject: RE: PPP over SONET/SDH Interoperability Issues List Content-Type: text Sender: owner-ietf-ppp@merit.edu Hi Eric, My comments/annotations are inserted below. George > > > > On 2 Sep 1998, Karl Fox wrote: > > > > > I recommend, therefore, that the encapsulation always be > > done with an > > > effective ACCM of zero, but that ACCM options in > > Configure-Requests > > > always be simply Acked and the negotiated value ignored. > > > > On 3 Sep 1998, James Carlson wrote: > > > > > The rule for all synchronous devices is that you request nothing (no > > > ACCM option in transmitted requests), and ack everything > > (any ACCM > > > with a valid length is acked), but that you do no escaping > > at all. > > Isn't this standardized in RFC-1662? It is standardized that way for PPP in HDLC framing, whereas RFC2364 is PPP in AAL5 framing. While you may disagree, they are not bound to be the same. The goal is to avoid the idiosyncrasies of HDLC framing, both sync and async, as they do not belong in an AAL5 frame. In particular, saying that you do ACCM escaping when in fact you do not is an artifact of a particular assumed async/sync passive bridging convertor being in the path. But these days, we know more than when RFC1662 section 6 was written. Passive bridging convertors have inter-operability problems that were not recognized at the time. These problems are solved by active bridging convertors. When an ATM physical segment is actively bridged to another physical segment, the bridging convertor handles the LCP framing option negotiation independently on a per physical segment basis. The ATM physical segment will not see an ACCM option being offered in this case. This subject was discussed at length last year on this list. I would encourage reviewing those archives...or we can re-tread that ground :-( > > > > > On 3 Sep 1998, George Gross wrote: > > > > > I placed text in the PPP over ATM draft to say an end point MUST NOT > > > request ACCM, and it MUST reject it if it is requested. > > Isn't this just an oversight, which conflicts with RFC-1662? This is not an oversight. It directly reflects the requirement to do active bridging convertors when an async end point is connected to a PPP over ATM end point, and in particular avoid ACK'ing an LCP option that is _not_ implemented on that ATM physical segment. > > > > > Thus, the ACCM option is handled differently when running over AAL5 or > > FUNI than when running directly over an octet-synchronous physical > > layer. An implementation of PPP over AAL5 or FUNI is > > supposed to reject > > ACCM, but an implementation of PPP over an octet-synchronous physical > > layer such as SONET is supposed to accept ACCM but ignore the value > > (in agreement with RFC 1662 section 6 and also with > > ). In neither case is any ACCM > > escaping done. Swift correction requested if I have this wrong. > > Isn't this unacceptable? How about if we just change the PPP/ATM draft to > be consistent with RFC-1662? Why should PPP/ATM be any different than any > other synchronous PPP? The whole idea is *interoperability*. I agree, inter-operability is an important goal. Active bridging promotes and achieves this goal, but IMHO propagating RFC1662's section 6 and passive bridging does not. George - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 16:01:50 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA25694; Fri, 4 Sep 1998 16:01:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 15:58:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA25608 for ietf-ppp-outgoing; Fri, 4 Sep 1998 15:58:18 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA25603 for ; Fri, 4 Sep 1998 15:58:11 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id PAA12284; Fri, 4 Sep 1998 15:57:58 -0400 To: gmg@luna3.lc.lucent.com (luna3!gmg) cc: ietf-ppp@merit.edu Subject: Re: PPP over SONET/SDH Interoperability Issues List References: <199809031348.JAA28508@luna3.lc.lucent.com> From: James Carlson Date: 04 Sep 1998 15:57:58 -0400 In-Reply-To: gmg@luna3.lc.lucent.com's message of 4 Sep 1998 11:55:02 -0400 Message-ID: <86k93jbqgp.fsf@helios.nis.ironbridgenetworks.com> Lines: 47 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu gmg@luna3.lc.lucent.com (luna3!gmg) writes: > This thread about ACCM option negotiation for a PPP over SONET > connection has a strong resemblance to the thread on the ACCM option wrt/ > PPP over ATM that occurred in September/October on this list last year. > One of the results of that discussion was Bill Simpson's ID on bridging > convertors: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-conversion-01.txt Yep, here's the relevant section: Therefore, the use of passive converters is deprecated. For backward compatibility, bit-synchronous and octet-synchronous implementations SHOULD respond to the LCP Async-Control-Character-Map (ACCM) Configu- ration Option with a Configure-Ack, but MUST NOT include the ACCM in a Configure-Request. Thus, it should be sending Configure-Ack, not Configure-Reject. (An active converter, on the other hand, would never present the option in the filtered option list, and so this situation would never arise.) This I-D is consistent with RFC 1662, which says: To enable this functionality, synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous-to-synchronous converter. The RFC is more demanding (MUST rather than SHOULD) than the I-D, though. (The odd thing is that there are significant products out there already that get this wrong ...) > Another result of that discussion is that I placed text in the PPP over ATM > draft to say an end point MUST NOT request ACCM, and it MUST reject it if > it is requested. I also added the following text: That doesn't seem to be consistent with either Mr. Simpson's I-D or the RFC. -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 16:53:54 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26800; Fri, 4 Sep 1998 16:53:51 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 16:49:36 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA26723 for ietf-ppp-outgoing; Fri, 4 Sep 1998 16:49:36 -0400 (EDT) Received: from algw2.lucent.com (algw2.lucent.com [205.147.213.2]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26719 for ; Fri, 4 Sep 1998 16:49:30 -0400 (EDT) From: manchester@bell-labs.com Received: from hotair.hobl.lucent.com by alig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id RAA18803; Fri, 4 Sep 1998 17:00:13 -0400 Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.3.1 sol2) id QAA11283; Fri, 4 Sep 1998 16:49:21 -0400 Message-ID: <35EF008A.633A0FB8@bell-labs.com> Date: Thu, 03 Sep 1998 16:48:11 -0400 Original-From: James Manchester X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "ietf-ppp@merit.edu" Subject: Updated Issues Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Issue#1: 1+X**43 Scrambling ----- a. Support is required for OC-3/12/48 concatenated mappings as a default configuration with 0x16 as the value for the C2 byte. b. The scambling may be disabled statically. 1. If scrambling is disabled, the C2 byte shall be coded as 0xCF. c. When using the 1+X**43 scrambler, the entire SONET/SDH payload (SPE minus the path overhead and any fixed stuff) shall be scrambled. An initial seed is unspecified and the scrambler shall run continuously and is not reset per SONET/SDH frame. Issue#2: 16/32 Bit FCS ----- a. OC-3 implementations must support the 16 or 32 bit FCS. 1. For OC-3 the 16 bit FCS is default. 2. Changing to the 32 bit FCS for OC-3 should be done statically. b. OC-12 implementations must support the 32 bit FCS as a default configuration. c. OC-48 implementations must support the 32 bit FCS as a default configuration. Issue#3: Address and Control Field Compression and Protocol Filed Compression ---- a. For OC-3/12/48 signals, Address and Control Field Compression and Protocol Field Compression shall not be used. Issue#4: Async Control Character Map ---- The encapsulation shall always be done with an effective ACCM of zero. ACCM options in Configure-Requests shall always be Acked and the negotiated value shall be ignored. Issue#5: SONET/SDH Fixed Stuff for Concatenated Signals above OC-3 ---- a. PPP packets shall not be mapped over the fixed stuff for OC-12/48 concatenated mappings. b. When using the 1+X**43 scrambler, the entire SONET/SDH payload (SPE minus the path overhead and any fixed stuff) shall be scrambled. Does anyone want to go over the bit ordering issues? - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Fri Sep 4 16:56:35 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26846; Fri, 4 Sep 1998 16:56:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 4 Sep 1998 16:52:13 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA26765 for ietf-ppp-outgoing; Fri, 4 Sep 1998 16:52:12 -0400 (EDT) Received: from andes.coppermountain.com (andes.coppermountain.com [206.71.190.2]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA26759 for ; Fri, 4 Sep 1998 16:52:06 -0400 (EDT) Received: by andes.coppermountain.com with Internet Mail Service (5.5.2232.9) id ; Fri, 4 Sep 1998 13:54:36 -0700 Message-ID: <31BFB6252086D111ADDF006008932DB51D3EFB@andes.coppermountain.com> From: Eric Michelsen To: ietf-ppp@merit.edu Subject: RE: PPP over SONET/SDH Interoperability Issues List Date: Fri, 4 Sep 1998 13:54:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu > -----Original Message----- > From: gmg@luna3.lc.lucent.com [mailto:gmg@luna3.lc.lucent.com] > Sent: Friday, September 04, 1998 11:35 > To: Eric Michelsen; ietf-ppp@merit.edu > Cc: gmgross@lucent.com > Subject: RE: PPP over SONET/SDH Interoperability Issues List ... > > This subject was discussed at length last year on this list. > I would encourage > reviewing those archives...or we can re-tread that ground :-( I recall the discussion, though I temporarily forgot some of the implications. ... > I agree, inter-operability is an important goal. Active > bridging promotes > and achieves this goal, but IMHO propagating RFC1662's > section 6 and passive > bridging does not. Actually, I think they both are interoperable. I wanted to avoid *requiring* an active bridge, which may break existing non-active bridges. But since we're talking about an *option*, any PPP endpoint can CONF-REJ or CONF-NAK anything it wants. Passive bridges may get suboptimal performance, but I don't think that's worth worrying about. And active bridges obviously do the right thing. So upon more thought, I endorse the current text in this regard. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Sep 5 14:28:32 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA06548; Sat, 5 Sep 1998 14:26:31 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 5 Sep 1998 14:21:37 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA06472 for ietf-ppp-outgoing; Sat, 5 Sep 1998 14:21:37 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA06468 for ; Sat, 5 Sep 1998 14:21:30 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id OAA05644; Sat, 5 Sep 1998 14:21:28 -0400 To: emichelsen@coppermountain.com (Eric Michelsen) cc: ietf-ppp@merit.edu Subject: Re: PPP over SONET/SDH Interoperability Issues List References: <31BFB6252086D111ADDF006008932DB51D3EFB@andes.coppermountain.com> From: James Carlson Date: 05 Sep 1998 14:21:28 -0400 In-Reply-To: emichelsen@coppermountain.com's message of 4 Sep 1998 17:36:15 -0400 Message-ID: <86k93ih13r.fsf@helios.nis.ironbridgenetworks.com> Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu emichelsen@coppermountain.com (Eric Michelsen) writes: > Actually, I think they both are interoperable. I wanted to avoid > *requiring* an active bridge, which may break existing non-active bridges. > But since we're talking about an *option*, any PPP endpoint can CONF-REJ or > CONF-NAK anything it wants. Passive bridges may get suboptimal performance, > but I don't think that's worth worrying about. And active bridges obviously > do the right thing. Yes, any given implementation may refuse any (or all) options, and this is required to be interoperable. I don't think that's at issue. The point here is that the RFCs 236[34] do not just suggest that these options be refused, but rather they *require* them to be refused. = The Magic Number LCP configuration option is RECOMMENDED, and the = Protocol Field Compression (PFC) option is NOT RECOMMENDED. An = implementation MUST NOT request any of the following options, and = MUST reject a request for such an option: That being said, although I think it's passing strange, I also think I don't much care. I doubt that my implementation will follow that requirement, but, since the other side is required by the same clause never to ask for this option in the first place, nobody will be able to tell. ;-} (I don't think the reason I mattered to me in the first place had to do specifically with passive translation, though that is the intent of the RFC 1662 behavior. I don't expect such translation to be done with an STS-48c signal. But it's very likely that in my system the same code will be used to negotiate both on that SONET link and on, say, a dial-up maintenance channel. Having oddities in the code for no particular reason seems to be a net loss. [Pun not really intended.]) -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Sep 5 19:57:05 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA09746; Sat, 5 Sep 1998 19:55:30 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 5 Sep 1998 19:55:00 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA09724 for ietf-ppp-outgoing; Sat, 5 Sep 1998 19:54:59 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA09719 for ; Sat, 5 Sep 1998 19:54:53 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA16167; Sat, 5 Sep 1998 16:54:22 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id RAA10347; Sat, 5 Sep 1998 17:04:27 -0700 (PDT) Message-Id: <199809060004.RAA10347@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: manchester@bell-labs.com cc: "ietf-ppp@merit.edu" Subject: Re: Updated Issues In-reply-to: Your message of "03 Sep 1998 20:48:11 GMT." <35EF008A.633A0FB8@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 05 Sep 1998 17:04:27 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu > Does anyone want to go over the bit ordering issues? I can do that, I think. There are three bit ordering issues, not handled consistently. - Octets are inserted in the frame payload such that the most significant bit (msb) of each octet is transmitted first. That is, the lsb of an octet and the msb of the next octet in the payload are adjacent in the transmitted bit stream. - If the 1+x^43 scrambler is in use, the payload is (de)scrambled in tranmission bit order, with the msb of each octet being processed through the (de)scrambler first and with the lsb of an octet being immediately followed by the msb of the next payload octet. - Both the 16 and 32 bit frame FCS are computed with the lsb of each octet being processed first, and with the msb of each octet being processed immediately before the lsb of the next frame octet. This matches the bit ordering implicit in the computation functions in Appendix C of RFC 1662. There are a couple of the issues I'm not sure about. > Issue#2: 16/32 Bit FCS > ----- > a. OC-3 implementations must support the 16 or 32 bit FCS. > 1. For OC-3 the 16 bit FCS is default. > 2. Changing to the 32 bit FCS for OC-3 should be done > statically. I'm not sure why 2. is here. While I can sympathize with arguments that FCS negotiation is bad, I'm not sure that I know any arguments which apply to OC-3 HDLC framing in particular but not HDLC framing in general. That is, if FCS negotiation is bad it is probably as bad for HDLC at DS-0 as it is for HDLC at OC-3c, and it hence seems kind of inconsistent to change the behaviour at just one speed while leaving it unchanged at other speeds where the same framing is used. This issue is independent of HDLC over SONET. I'd also note that this change will cause interoperability problems with any current implementation which insists that FCS changes be negotiated, as they must under the current rules. > Issue#3: Address and Control Field Compression and Protocol Filed > Compression > ---- > a. For OC-3/12/48 signals, Address and Control Field Compression and > Protocol Field Compression shall not be used. I don't see any particular benefit from this constraint. An implementation for which Address/Control and Protocol Field Compression is the tiniest bit inconvenient can always decline to negotiate these even now, so if one wishes to fix the L2 header size or gains some benefit from having the L3 header precisely 4 bytes into the packet one can always have this even now. In fact the current specification goes further and even recommends these not be negotiated, so an implementation that makes this choice has moral support from the standard even now. On the other hand, I also see no reason to attempt to ban implementations which don't find compression inconvenient from choosing to recover the three useless bytes of overhead per packet. In fact, because the above constraint has no interoperability consequences that aren't solved by current negotiation procedures, it would also have no effect at all on implementations which choose to continue to support the option of negotiating compression with consenting peers anyway. About the only thing it might do is convince test set vendors that they'll never see compressed L2 headers, and I'm not sure this is an entirely good thing. While the benefit of reducing packet overhead by a percent is small, it is still non-zero. Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Sat Sep 5 21:00:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id UAA10293; Sat, 5 Sep 1998 20:58:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sat, 5 Sep 1998 20:58:17 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA10267 for ietf-ppp-outgoing; Sat, 5 Sep 1998 20:58:16 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA10263 for ; Sat, 5 Sep 1998 20:58:11 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id RAA18031 for ; Sat, 5 Sep 1998 17:58:10 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Sat, 5 Sep 1998 17:58:10 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: Updated Issues In-Reply-To: <199809060004.RAA10347@skank.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Sat, 5 Sep 1998, Dennis Ferguson wrote: > > Does anyone want to go over the bit ordering issues? > > I can do that, I think. There are three bit ordering issues, not handled > consistently. > > - Octets are inserted in the frame payload such that the most significant > bit (msb) of each octet is transmitted first. That is, the lsb of an > octet and the msb of the next octet in the payload are adjacent in the > transmitted bit stream. > > - If the 1+x^43 scrambler is in use, the payload is (de)scrambled in > tranmission bit order, with the msb of each octet being processed > through the (de)scrambler first and with the lsb of an octet being > immediately followed by the msb of the next payload octet. > > - Both the 16 and 32 bit frame FCS are computed with the lsb of each > octet being processed first, and with the msb of each octet being > processed immediately before the lsb of the next frame octet. This > matches the bit ordering implicit in the computation functions in > Appendix C of RFC 1662. This is very good. Do you think that C code illustrating how to do the scrambling and descrambling a byte at a time would be useful as an informative annex? [I posted code for a descrambler already and can provide code for scrambler if it is wanted.] > There are a couple of the issues I'm not sure about. > > > Issue#2: 16/32 Bit FCS > > ----- > > a. OC-3 implementations must support the 16 or 32 bit FCS. > > 1. For OC-3 the 16 bit FCS is default. > > 2. Changing to the 32 bit FCS for OC-3 should be done > > statically. > > I'm not sure why 2. is here. While I can sympathize with arguments > that FCS negotiation is bad, I'm not sure that I know any arguments > which apply to OC-3 HDLC framing in particular but not HDLC framing > in general. That is, if FCS negotiation is bad it is probably as > bad for HDLC at DS-0 as it is for HDLC at OC-3c, and it hence seems > kind of inconsistent to change the behaviour at just one speed while > leaving it unchanged at other speeds where the same framing is used. > This issue is independent of HDLC over SONET. > > I'd also note that this change will cause interoperability problems > with any current implementation which insists that FCS changes be > negotiated, as they must under the current rules. I have understood "should be done statically" to mean that negotiation of a value other than the default is discouraged, but not prohibited. Apparently you read this differently. OK, how about the following: - For OC-3 the 16 bit FCS is the default. Implementations are encouraged to support the 32 bit FCS. - For rates higher than OC-3 the 32 bit FCS is the default. Use of the 16 bit FCS is discouraged. - By bilateral agreement, a different FCS that the default may be statically configured or may be negotiated dynamically. Of these two methods static configuration is preferred. - No implementation is required to support an FCS other than the default. I believe that this is consistent with RFC 1662 and with RFC 1570. Also, it drops the requirement for an OC-3 implementation to support the 32 bit FCS since requiring support for a value other than the default seems to be inconsistent with RFC 1661 (assuming that I correctly understand what I have read). > > > Issue#3: Address and Control Field Compression and Protocol Filed > > Compression > > ---- > > a. For OC-3/12/48 signals, Address and Control Field Compression and > > Protocol Field Compression shall not be used. > > I don't see any particular benefit from this constraint. I'm OK to leave these as "not recommended". > > Dennis Ferguson > Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 05:41:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id FAA03907; Tue, 8 Sep 1998 05:37:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 05:29:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA03841 for ietf-ppp-outgoing; Tue, 8 Sep 1998 05:29:20 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.8.7/8.8.5) with SMTP id FAA03837 for ; Tue, 8 Sep 1998 05:29:15 -0400 (EDT) Received: from amalis by alpo.casc.com (SMI-8.6/SM-980323-1632) id FAA05246; Tue, 8 Sep 1998 05:27:49 -0400 Message-Id: <199809080927.FAA05246@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Mon, 07 Sep 1998 12:10:46 -0400 To: "C. M. Heard/VVNET, Inc." From: Andrew Malis Subject: Re: Updated Issues Cc: ietf-ppp@merit.edu In-Reply-To: References: <199809060004.RAA10347@skank.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu At 05:58 PM 9/5/98 -0700, C. M. Heard/VVNET, Inc. wrote: >This is very good. Do you think that C code illustrating how to >do the scrambling and descrambling a byte at a time would be useful >as an informative annex? [I posted code for a descrambler already >and can provide code for scrambler if it is wanted.] James had some very useful figures in draft-manchester-pppext-transper-00.txt. >OK, how about the following: > > - For OC-3 the 16 bit FCS is the default. Implementations > are encouraged to support the 32 bit FCS. > - For rates higher than OC-3 the 32 bit FCS is the default. > Use of the 16 bit FCS is discouraged. > - By bilateral agreement, a different FCS that the default > may be statically configured or may be negotiated dynamically. > Of these two methods static configuration is preferred. > - No implementation is required to support an FCS other than > the default. > >I believe that this is consistent with RFC 1662 and with RFC 1570. >Also, it drops the requirement for an OC-3 implementation to support >the 32 bit FCS since requiring support for a value other than the >default seems to be inconsistent with RFC 1661 (assuming that I correctly >understand what I have read). I would prefer stronger language on the higher speeds: > - For rates higher than OC-3 the 32 bit FCS are required. > Use of the 16 bit FCS is not allowed. > - By bilateral agreement, at OC-3 only a different FCS that the default > may be statically configured or may be negotiated dynamically. > Of these two methods static configuration is preferred. I am not aware of any existing OC-12 or OC-48 implementations that only support the 16-bit FCS. The 32-bit FCS is really worth the extra two bytes to protect against the scrambler error multiplication, and removing the 16-bit FCS option can only simplify implementations. I believe we already have consensus that scrambling is required for OC-12 and OC-48. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 11:52:27 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA08181; Tue, 8 Sep 1998 11:50:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 11:49:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA08133 for ietf-ppp-outgoing; Tue, 8 Sep 1998 11:49:32 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA08126 for ; Tue, 8 Sep 1998 11:49:26 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id IAA13832 for ; Tue, 8 Sep 1998 08:49:22 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Tue, 8 Sep 1998 08:49:22 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: Updated Issues In-Reply-To: <199809080927.FAA05246@alpo.casc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Mon, 7 Sep 1998, Andrew Malis wrote: [ ... ] > I believe we already have consensus that scrambling is required for OC-12 > and OC-48. Scrambling is required at all rates. The unscrambled mapping specified in RFC 1619 should be deprecated and that RFC should go to historic/ not recommended status. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 13:46:35 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id NAA10413; Tue, 8 Sep 1998 13:44:57 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 13:44:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA10356 for ietf-ppp-outgoing; Tue, 8 Sep 1998 13:44:03 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA10352 for ; Tue, 8 Sep 1998 13:44:00 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id NAA26475 for ietf-ppp@merit.edu; Tue, 8 Sep 1998 13:44:00 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA27092 for ; Fri, 4 Sep 1998 17:10:41 -0400 (EDT) Received: from spice.cascade by alpo.casc.com (SMI-8.6/SM-980323-1632) id RAA02402; Fri, 4 Sep 1998 17:09:34 -0400 Received: from localhost (amalis@localhost) by spice.cascade (8.8.8+Sun/8.8.8) with ESMTP id RAA02880; Fri, 4 Sep 1998 17:09:32 -0400 (EDT) X-Authentication-Warning: spice.cascade: amalis owned process doing -bs Date: Fri, 4 Sep 1998 17:09:32 -0400 (EDT) From: "Andrew G. Malis" X-Sender: amalis@spice To: manchester@bell-labs.com cc: "ietf-ppp@merit.edu" Subject: Re: Updated Issues In-Reply-To: <35EF008A.633A0FB8@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu James, Good summary of the issues. > Issue#2: 16/32 Bit FCS > ----- > a. OC-3 implementations must support the 16 or 32 bit FCS. > 1. For OC-3 the 16 bit FCS is default. > 2. Changing to the 32 bit FCS for OC-3 should be done > statically. > b. OC-12 implementations must support the 32 bit FCS as a default > configuration. > c. OC-48 implementations must support the 32 bit FCS as a default > configuration. Does anyone see ANY reason for supporting the 16-bit FCS for OC-12 or OC-48? Only supporting the 32-bit FCS makes life much easier, and better guards against the scrambling error multiplication. Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 19:06:57 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA19019; Tue, 8 Sep 1998 19:06:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 19:05:44 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA18991 for ietf-ppp-outgoing; Tue, 8 Sep 1998 19:05:44 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA18983 for ; Tue, 8 Sep 1998 19:05:36 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA07675; Tue, 8 Sep 1998 16:05:05 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id QAA20873; Tue, 8 Sep 1998 16:15:12 -0700 (PDT) Message-Id: <199809082315.QAA20873@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: amalis@casc.com (Andrew G. Malis) cc: manchester@bell-labs.com, "ietf-ppp@merit.edu" Subject: Re: Updated Issues In-reply-to: Your message of "04 Sep 1998 21:09:32 GMT." Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 08 Sep 1998 16:15:12 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu > > b. OC-12 implementations must support the 32 bit FCS as a default > > configuration. > > c. OC-48 implementations must support the 32 bit FCS as a default > > configuration. > > Does anyone see ANY reason for supporting the 16-bit FCS for OC-12 or > OC-48? Only supporting the 32-bit FCS makes life much easier, and > better guards against the scrambling error multiplication. I think changing the default FCS to 32 bits is sufficient to allow 32-bit-FCS-only implementations to exist since changing the default ensures that every implementation will at least support the 32 bit FCS, and leaves implementations which only support the 32 bit FCS free to decline to do anything else. So I think I'd want to know what would be gained by attempting to further constrain the use of the alternative FCS if the implementations involved support that as well? I don't mind specifications making well-founded recommendations, but I don't see the point of adding hard (and unenforceable) constraints beyond those dictated by basic interoperability considerations. If the 16-bit FCS is available at both ends of the circuit I don't see a reason to embed the judgement of whether it should be used or not in a protocol specification; the user can make up his own mind. Dennis - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 19:31:36 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id TAA19478; Tue, 8 Sep 1998 19:31:34 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 19:31:21 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA19455 for ietf-ppp-outgoing; Tue, 8 Sep 1998 19:31:20 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA19451 for ; Tue, 8 Sep 1998 19:31:15 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id RAA06981 for ietf-ppp@merit.edu env-from ; Tue, 8 Sep 1998 17:31:13 -0600 (MDT) Date: Tue, 8 Sep 1998 17:31:13 -0600 (MDT) From: Vernon Schryver Message-Id: <199809082331.RAA06981@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Updated Issues Sender: owner-ietf-ppp@merit.edu > From: Dennis Ferguson > > > b. OC-12 implementations must support the 32 bit FCS as a default > > > configuration. > > > c. OC-48 implementations must support the 32 bit FCS as a default > > > configuration. > > > > Does anyone see ANY reason for supporting the 16-bit FCS for OC-12 or > > OC-48? Only supporting the 32-bit FCS makes life much easier, and > > better guards against the scrambling error multiplication. > > I think changing the default FCS to 32 bits is sufficient to allow > ... How will you handle the LCP Configure-Request/Reject/Nak hassles? Is the idea to define a new Conf-Request option that says "please send me 16-bit FCS? I guess that's plausible, although it seems different from all other PPP media. Isn't there a patent problem with the scheme that allows transparent use of either FCS? If you don't use the patented mechanism, how do you shift from 32 to 16? How do you successfully shift back to 32 when the peer has lost its mind or otherwise had reason to go to Establish Phase? If this were low speed stuff, I guess you could capture all packets with bad FCS and send them to your PPP process which would recompute the FCS in the other mode just in case a random, apparently bad packet happens to be a Configure-Request from the peer announcing the need to re-negotiate the FCS (and other PPP stuff). Are you sure that it wouldn't be better to simply say that at some speeds and with some scrambling, you always use the 32-bit FCS, and with other combinations you always use the 16-bit FCS? That might go against the standard standards committee dictum of trying to please everybody by including options for everything, but are there any technical reasons against it? Have I guessed right that it would be silly nonsense to try negotiate the scrambling with familiar in-band PPP frames? If so, why not permanently link the scrambling mode with the FCS size? Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 22:24:44 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA21745; Tue, 8 Sep 1998 22:24:35 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 22:23:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA21721 for ietf-ppp-outgoing; Tue, 8 Sep 1998 22:23:57 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA21715 for ; Tue, 8 Sep 1998 22:23:50 -0400 (EDT) Received: from skank.juniper.net (skank.juniper.net [208.197.169.216]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id TAA19128; Tue, 8 Sep 1998 19:23:19 -0700 (PDT) Received: from skank.juniper.net (localhost.juniper.net [127.0.0.1]) by skank.juniper.net (8.8.4/8.7.3) with ESMTP id TAA22977; Tue, 8 Sep 1998 19:33:26 -0700 (PDT) Message-Id: <199809090233.TAA22977@skank.juniper.net> X-Mailer: exmh version 1.6.9 8/22/96 To: vjs@calcite.rhyolite.com (Vernon Schryver) cc: ietf-ppp@merit.edu Subject: Re: Updated Issues In-reply-to: Your message of "08 Sep 1998 23:31:13 GMT." <199809082331.RAA06981@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 08 Sep 1998 19:33:26 -0700 From: Dennis Ferguson Sender: owner-ietf-ppp@merit.edu > > I think changing the default FCS to 32 bits is sufficient to allow > > ... > > How will you handle the LCP Configure-Request/Reject/Nak hassles? Is the > idea to define a new Conf-Request option that says "please send me 16-bit > FCS? I guess that's plausible, although it seems different from all other > PPP media. ?? It isn't new, it is in RFC 1570. And it isn't different, one has always been free to attempt to negotiate the FCS size for HDLC over any PPP media, just as one has always been free to only implement the default FCS. > Are you sure that it wouldn't be better to simply say that at some speeds > and with some scrambling, you always use the 32-bit FCS, and with other > combinations you always use the 16-bit FCS? That might go against the > standard standards committee dictum of trying to please everybody by > including options for everything, but are there any technical reasons > against it? The existing specification has already gone down the path of `pleasing everybody'. Moreover the existing interoperability default (essentially, CRC-16 for HDLC over any medium) was a bad choice for some configurations if you need to pick just one FCS size, yet support for the default was still required by the specification for interoperability, and in fact the occasional implementation chose to not `please everybody' by implementing only the default. So we have OC-3 HDLC implementations which only do CRC-16, or only do CRC-16 when the scrambler is on, to deal with. And for years we've had T3 DSU's which implemented scramblers which are just as harmful as the ATM scramber (sometimes it is the ATM scrambler) for the 16 bit FCS, running over media whose error rate can be expected to sometimes be significantly higher that all-glass SONET. It is not possible to change the current default without causing interoperability problems, but it also wouldn't be a particularly good choice to absolutely ban configuration of adequate error protection in situations where the historical default was not always a good choice. So we have situations where dual-FCS hardware is desireable (one size for interoperability, another size for prudence), and we have a protocol specified in RFC 1570 for changing the FCS. If you don't like the protocol in RFC 1570, or don't think it works, dumping that is fine with me. In my experience manual configuration of the FCS size is exceedingly reliable, and would work no matter what devine revelations are included in the encyclical on the One True FCS Size, it just won't work in the presence of other implementations which slavishly implement RFC 1570 as they have been required to up to now. > Have I guessed right that it would be silly nonsense to try negotiate the > scrambling with familiar in-band PPP frames? If so, why not permanently > link the scrambling mode with the FCS size? I don't think the second sentence is the only possibility one could conclude from a `yes' answer to the first. Scrambling is set by manual configuration, not necessarily in the same box that the PPP implementation lives in and hence not necessarily with the PPP implementation's knowledge. If manual configuration is good enough for scrambling, why wouldn't it be good enough for the FCS size independent of the scrambler setting? And instead of trying to fix RFC 1570 by banning FCS changes altogether, wouldn't it be better to fix RFC 1570 by fixing RFC 1570? Dennis Ferguson - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 8 23:08:02 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id XAA22174; Tue, 8 Sep 1998 23:07:58 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 8 Sep 1998 23:07:33 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA22152 for ietf-ppp-outgoing; Tue, 8 Sep 1998 23:07:33 -0400 (EDT) Received: from alpo.casc.com (alpo.casc.com [152.148.10.6]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA22148 for ; Tue, 8 Sep 1998 23:07:27 -0400 (EDT) Received: from amalis by alpo.casc.com (SMI-8.6/SM-980323-1632) id XAA17990; Tue, 8 Sep 1998 23:05:59 -0400 Message-Id: <199809090305.XAA17990@alpo.casc.com> X-Sender: amalis@alpo.casc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Tue, 08 Sep 1998 23:04:37 -0400 To: Dennis Ferguson From: Andrew Malis Subject: Re: Updated Issues Cc: amalis@casc.com (Andrew G. Malis), manchester@bell-labs.com, "ietf-ppp@merit.edu" In-Reply-To: <199809082315.QAA20873@skank.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Dennis, >So I think I'd want to know what would be gained by attempting to further >constrain the use of the alternative FCS if the implementations involved >support that as well? I don't mind specifications making well-founded >recommendations, but I don't see the point of adding hard (and unenforceable) >constraints beyond those dictated by basic interoperability considerations. >If the 16-bit FCS is available at both ends of the circuit I don't see a >reason to embed the judgement of whether it should be used or not in a >protocol specification; the user can make up his own mind. I agree that simply requiring the 32-bit FCS provides basic interoperability. However, proscribing the 16-bit FCS, given that it is of limited utility anyway for this application, makes life easier for vendors because they don't have to worry about having to do it anyway JUST IN CASE someone else out there decides to only implement the 16-bit FCS, and the customer wants you to interoperate with them (even when they're violating the spec). I've seen that too many times before ... Cheers, Andy ________________________________________________________________________ Andrew G. Malis malis@ascend.com phone:978 952-7414 fax:978 392-1484 Ascend Communications, Inc. 1 Robbins Road Westford, MA 01886 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 9 01:28:21 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id BAA23695; Wed, 9 Sep 1998 01:28:01 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Sep 1998 01:27:25 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA23669 for ietf-ppp-outgoing; Wed, 9 Sep 1998 01:27:24 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA23665 for ; Wed, 9 Sep 1998 01:27:19 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.8.5/calcite) id XAA07685 for ietf-ppp@merit.edu env-from ; Tue, 8 Sep 1998 23:27:13 -0600 (MDT) Date: Tue, 8 Sep 1998 23:27:13 -0600 (MDT) From: Vernon Schryver Message-Id: <199809090527.XAA07685@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: Updated Issues Sender: owner-ietf-ppp@merit.edu > From: Dennis Ferguson > ... > > How will you handle the LCP Configure-Request/Reject/Nak hassles? Is the > > idea to define a new Conf-Request option that says "please send me 16-bit > > FCS? I guess that's plausible, although it seems different from all other > > PPP media. > > ?? It isn't new, it is in RFC 1570. And it isn't different, one has always > been free to attempt to negotiate the FCS size for HDLC over any PPP media, > just as one has always been free to only implement the default FCS. Wouldn't it be rather different for the default to be the long FCS? Besides the ACCM, what other parameters whose default values depend on the nature of link? Recall the recent talk about what to do with the ACCM over SONET, what with sync-async converters and all. Yes, passive sync-async converters don't seem extremely relevant to SONET links. If you pick one FCS per new SONET speed, don't you automatically provide a bunch of simple answers to a raft of ACCM-like questions? You are right that I'm wrong about the difficulty of switching FCS's. The obvious idea in RFC 1570 of sending two Configure-Requests when there is any possibility that the peer is expecting the other FCS solves that problem. It does require that the hardware be able to switch without much turmoil. I still think a robust implementation might want to save as many small packets received with bad FCS as possible to be check with the other FCS. The idea is the same as found in more than one UNIX PPP implementation for dealing with the first PPP packets that can immediately follow ASCII login messages, banners, etc. > > Are you sure that it wouldn't be better to simply say that at some speeds > > and with some scrambling, you always use the 32-bit FCS, and with other > > combinations you always use the 16-bit FCS? That might go against the > > standard standards committee dictum of trying to please everybody by > > including options for everything, but are there any technical reasons > > against it? > > The existing specification has already gone down the path of `pleasing > everybody'. Yes, but why not stop before reaching the absolute dead end of the path? I profess no knowledge of SONET, but I have been reading what you guys have been writing. I had the distinct impression that no one wants to actually use CRC-16 on the media/speeds where you propose to make the default be CRC-32. > Moreover the existing interoperability default (essentially, > CRC-16 for HDLC over any medium) was a bad choice for some configurations > if you need to pick just one FCS size, yet support for the default was > still required by the specification for interoperability, and in fact the > occasional implementation chose to not `please everybody' by implementing > only the default. So we have OC-3 HDLC implementations which only do > CRC-16, or only do CRC-16 when the scrambler is on, to deal with. Why isn't a default of CRC-16 catastrophic for any interoperability with such old implementations? > And for > years we've had T3 DSU's which implemented scramblers which are just as > harmful as the ATM scramber (sometimes it is the ATM scrambler) for the > 16 bit FCS, running over media whose error rate can be expected to sometimes > be significantly higher that all-glass SONET. It is not possible to change > the current default without causing interoperability problems, but it also > wouldn't be a particularly good choice to absolutely ban configuration of > adequate error protection in situations where the historical default was > not always a good choice. I do not understand. I thought you and others favored making CRC-32 the default. > So we have situations where dual-FCS hardware is desireable (one size for > interoperability, another size for prudence), and we have a protocol > specified in RFC 1570 for changing the FCS. I don't understand the interoperability issue. Regardless of RFC 1570, 1662, or any other PPP chit-chat, how do those old OC-3 implementations talk to your new OC-96 implementations enough to notice PPP interoperability problems? Isn't the wee bit of a speed mismatch bothersome? > If you don't like the > protocol in RFC 1570, or don't think it works, dumping that is fine > with me. In my experience manual configuration of the FCS size is > exceedingly reliable, and would work no matter what devine revelations > are included in the encyclical on the One True FCS Size, it just won't > work in the presence of other implementations which slavishly implement > RFC 1570 as they have been required to up to now. How many PPP implementations over any media currently support FCS switching? (I think someone said recently, but I've forgotten the answer.) > > Have I guessed right that it would be silly nonsense to try negotiate the > > scrambling with familiar in-band PPP frames? If so, why not permanently > > link the scrambling mode with the FCS size? > > I don't think the second sentence is the only possibility one could > conclude from a `yes' answer to the first. Scrambling is set by manual > configuration, not necessarily in the same box that the PPP implementation > lives in and hence not necessarily with the PPP implementation's knowledge. Yes, along with plenty of other things that PPP doesn't understand. There's no Law of Nature that requires that absolutely everthing be crammed into PPP, although based on our actions over the years, that seems to be the goal of the working group. > If manual configuration is good enough for scrambling, why wouldn't it be > good enough for the FCS size independent of the scrambler setting? That sounds good to me. > And > instead of trying to fix RFC 1570 by banning FCS changes altogether, > wouldn't it be better to fix RFC 1570 by fixing RFC 1570? Note again that I'd forgotten about the double-packet hack in RFC 1570, and was thinking of the patented Digital universal FCS scheme. Still, why bother negotiating something just because you might make it work and otherwise there is an assymetry among the standards documents? I think you should negotiate only those parameters that you really want to vary. Parameters that everyone agrees will in practice never change should not be negotiated. The other things that must happen at high speeds when you switch PPP phases, such as gating the IP flow, are enough to worry about. It would be nice to not also need to worry about whether packets have the right flavor of FCS. Vernon Schryver vjs@rhyolite.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 9 10:52:58 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA29389; Wed, 9 Sep 1998 10:51:45 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Sep 1998 10:46:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA29287 for ietf-ppp-outgoing; Wed, 9 Sep 1998 10:46:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA29280 for ; Wed, 9 Sep 1998 10:45:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02192; Wed, 9 Sep 1998 10:45:24 -0400 (EDT) Message-Id: <199809091445.KAA02192@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-lcp-charset-03.txt Date: Wed, 09 Sep 1998 10:45:23 -0400 Sender: owner-ietf-ppp@merit.edu --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 LCP Internationalization Configuration Option Author(s) : G. Zorn Filename : draft-ietf-pppext-lcp-charset-03.txt Pages : 5 Date : 08-Sep-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-lcp-charset-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-lcp-charset-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lcp-charset-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@ietf.org" Content-Type: text/plain Content-ID: <19980908135535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lcp-charset-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lcp-charset-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980908135535.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 9 10:57:26 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA29569; Wed, 9 Sep 1998 10:57:24 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Sep 1998 10:57:04 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA29544 for ietf-ppp-outgoing; Wed, 9 Sep 1998 10:57:03 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA29540 for ; Wed, 9 Sep 1998 10:57:00 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA21651 for ietf-ppp@merit.edu; Wed, 9 Sep 1998 10:56:59 -0400 (EDT) Received: from SanFrancisco01.POP.InterNex.Net (sanfrancisco01.pop.internex.net [205.158.3.50]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA28560 for ; Wed, 9 Sep 1998 10:13:04 -0400 (EDT) Received: from senior ([205.158.231.115]) by SanFrancisco01.POP.InterNex.Net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with SMTP id AAA26057 for ; Wed, 9 Sep 1998 07:13:02 -0700 From: bob@larribeau.com (Bob Larribeau) To: Subject: L2TP & IPSEC Interoperability Workshop Date: Wed, 9 Sep 1998 07:11:00 -0700 Message-ID: <001701bddbfb$abd1f5a0$73e79ecd@senior.larribeau.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-ietf-ppp@merit.edu IBM has announced that the fee for the VPN Interoperability Workshop has been waived! The updated application is available at http://www.ciug.org Get your reservation in by September 25 to insure availability of hotel rooms. We have only received a handful of applications so far so don't wait too long. Bob Larribeau Chairman California ISDN Users' Group - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 9 11:38:18 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id LAA00661; Wed, 9 Sep 1998 11:38:16 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Sep 1998 11:38:02 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA00639 for ietf-ppp-outgoing; Wed, 9 Sep 1998 11:38:01 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA00635 for ; Wed, 9 Sep 1998 11:37:55 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id IAA01824 for ; Wed, 9 Sep 1998 08:37:54 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Wed, 9 Sep 1998 08:37:54 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: Updated Issues In-Reply-To: <199809090527.XAA07685@calcite.rhyolite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Vernon Schryver wrote: > > From: Dennis Ferguson > > > ... > > > How will you handle the LCP Configure-Request/Reject/Nak hassles? Is the > > > idea to define a new Conf-Request option that says "please send me 16-bit > > > FCS? I guess that's plausible, although it seems different from all other > > > PPP media. > > > > ?? It isn't new, it is in RFC 1570. And it isn't different, one has always > > been free to attempt to negotiate the FCS size for HDLC over any PPP media, > > just as one has always been free to only implement the default FCS. > > Wouldn't it be rather different for the default to be the long FCS? No, that is permitted by RFC 1570, Section 2.1: % Implementation Note: % % For most PPP HDLC framed links, the default FCS is the CCITT 16- % bit FCS. Some framing techniques and high speed links may use % another format as the default FCS. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 9 12:15:10 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id MAA01458; Wed, 9 Sep 1998 12:14:54 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 9 Sep 1998 12:14:06 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA01416 for ietf-ppp-outgoing; Wed, 9 Sep 1998 12:14:05 -0400 (EDT) Received: from shell16.ba.best.com (heard@shell16.ba.best.com [206.184.139.148]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA01412 for ; Wed, 9 Sep 1998 12:14:00 -0400 (EDT) Received: from localhost (heard@localhost) by shell16.ba.best.com (8.9.0/8.9.0/best.sh) with SMTP id JAA09103 for ; Wed, 9 Sep 1998 09:13:59 -0700 (PDT) X-Authentication-Warning: shell16.ba.best.com: heard owned process doing -bs Date: Wed, 9 Sep 1998 09:13:58 -0700 (PDT) From: "C. M. Heard/VVNET, Inc." X-Sender: heard@shell16.ba.best.com To: ietf-ppp@merit.edu Subject: Re: Updated Issues In-Reply-To: <199809090305.XAA17990@alpo.casc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu On Tue, 8 Sep 1998, Andrew Malis wrote: > [ ... ] proscribing the 16-bit FCS [at rates above OC-3], given that it > is of limited utility anyway for this application, makes life easier for > vendors because they don't have to worry about having to do it anyway > JUST IN CASE someone else out there decides to only implement the 16-bit > FCS, and the customer wants you to interoperate with them (even when > they're violating the spec). I've seen that too many times before ... I've seen it too, but allow me to point out that there is _nothing_ one can put in a standard that will prevent people from offering non-standard configuration options (particularly ones which are already implemented and deployed ... such as the 16-bit FCS for PPP over OC-12). I am inclined to think that it does not make much difference whether the spec bans the 16-bit FCS at OC-12 and above or merely recommends against its use. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 15 14:17:04 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA16516; Tue, 15 Sep 1998 14:13:47 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Sep 1998 14:08:38 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA16200 for ietf-ppp-outgoing; Tue, 15 Sep 1998 14:08:37 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA16183 for ; Tue, 15 Sep 1998 14:08:29 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id OAA09594 for ietf-ppp@merit.edu; Tue, 15 Sep 1998 14:08:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA08893 for ; Tue, 15 Sep 1998 07:46:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA16736; Tue, 15 Sep 1998 07:45:17 -0400 (EDT) Message-Id: <199809151145.HAA16736@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Document Action: Multi-link Multi-node PPP to Informational Date: Tue, 15 Sep 1998 07:45:17 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft Multi-link Multi-node PPP as a Informational RFC, but with the new title of Bay Network's Multi-link Multi-node PPP Bundle Discovery Protocol. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 15 14:17:09 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA16511; Tue, 15 Sep 1998 14:13:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Sep 1998 14:10:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA16295 for ietf-ppp-outgoing; Tue, 15 Sep 1998 14:10:04 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA16288 for ; Tue, 15 Sep 1998 14:10:00 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id OAA09736 for ietf-ppp@merit.edu; Tue, 15 Sep 1998 14:09:59 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA10550 for ; Tue, 15 Sep 1998 09:30:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19701; Tue, 15 Sep 1998 09:29:54 -0400 (EDT) Message-Id: <199809151329.JAA19701@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: The PPP Triple-DES Encryption Protocol (3DESE) to Proposed Standard Date: Tue, 15 Sep 1998 09:29:54 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft 'The PPP Triple-DES Encryption Protocol (3DESE)' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The PPP Encryption Control Protocol (ECP) provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the Triple-DES standard (3DES) for encrypting PPP encapsulated packets. The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. Triple-DES means that this algorithm is applied three times on the data to be encrypted before it is sent over the line. The variant used is the DES-EDE3-CBC, which is described in more detail in the text. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. Note to RFC Editor: Please replace the 3DES Configuration Option type listed on page 4 as "tbd" with the assigned value "2" - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 15 14:17:01 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA16509; Tue, 15 Sep 1998 14:13:43 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 15 Sep 1998 14:10:58 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA16362 for ietf-ppp-outgoing; Tue, 15 Sep 1998 14:10:57 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA16356 for ; Tue, 15 Sep 1998 14:10:51 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id OAA09889 for ietf-ppp@merit.edu; Tue, 15 Sep 1998 14:10:51 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA10850 for ; Tue, 15 Sep 1998 09:50:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20406; Tue, 15 Sep 1998 09:49:23 -0400 (EDT) Message-Id: <199809151349.JAA20406@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Protocol Action: The PPP DES Encryption Protocol, Version 2 (DESE-bis) to Proposed Standard Date: Tue, 15 Sep 1998 09:49:23 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft 'The PPP DES Encryption Protocol, Version 2 (DESE-bis)' as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The PPP Encryption Control Protocol (ECP) provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the DES standard for encrypting PPP encapsulated packets. The purpose of this draft is both to show how one specifies the necessary details of a "data" or "bearer" protocol given the context of the generic PPP Encryption Control Protocol, and also to provide at least one commonly-understood means of secure data transmission between PPP implementations. The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. The DES cipher was designed for efficient implementation in hardware, and consequently may be relatively expensive to implement in software. However, its pervasiveness makes it seem like a reasonable choice for a "model" encryption protocol. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten of the IESG. - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 16 10:47:04 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA06473; Wed, 16 Sep 1998 10:44:39 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Sep 1998 10:40:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA06156 for ietf-ppp-outgoing; Wed, 16 Sep 1998 10:40:41 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA06141 for ; Wed, 16 Sep 1998 10:40:32 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA00189 for ietf-ppp@merit.edu; Wed, 16 Sep 1998 10:40:31 -0400 (EDT) Received: from u-picasso.rd.francetelecom.com ([208.25.179.51]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA26385 for ; Tue, 15 Sep 1998 21:09:54 -0400 (EDT) Received: from u-dali.rd.francetelecom.com ([208.25.178.61]) by u-picasso.rd.francetelecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id SCVCTL6K; Tue, 15 Sep 1998 18:09:29 -0700 Received: by u-dali.rd.francetelecom.com with Internet Mail Service (5.5.2232.9) id ; Tue, 15 Sep 1998 18:09:07 -0700 Message-ID: From: CATANZARITI Sergio FTR&D/S&D To: ietf-ppp@merit.edu Cc: CATANZARITI Sergio FTR&D/S&D Date: Tue, 15 Sep 1998 18:09:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Hello, I have a question. MS has released an ATM API for Win 98. On the other hand, a number of ADSL modem vendors have designed ADSL PC cards integrating the IP/PPP/ATM stack. I would like to know if they intend to link the MS API to their ATM layer in their cards. Could, please, someone from MS or ADSL PC cards vendors community kindly answer to me and/or pointing me to some helpful reference materials, related information as well? Any help would be really appreciated it. Please, answer me in my personal e-mail address, not including the ppp exploder list. Thanks, Sergio > -------------------------------------------------------------------- > Sergio Catanzariti > Project Manager, Strategy and Development > France Telecom - Research and Development > 1000 Marina Boulevard Suite 300 > Brisbane CA 94005 > Tel. 650-875-1526 > Fax. 650-875-1505 > email:sergio.catanzariti@rd.francetelecom.com > -------------------------------------------------------------------------- > > - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 16 10:59:24 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA07203; Wed, 16 Sep 1998 10:57:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Sep 1998 10:56:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA07104 for ietf-ppp-outgoing; Wed, 16 Sep 1998 10:56:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA07083 for ; Wed, 16 Sep 1998 10:56:30 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21918; Wed, 16 Sep 1998 10:55:55 -0400 (EDT) Message-Id: <199809161455.KAA21918@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org cc: ietf-ppp@merit.edu, pppoe@ipsec.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-carrel-info-pppoe-01.txt Date: Wed, 16 Sep 1998 10:55:54 -0400 Sender: owner-ietf-ppp@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PPP Over Ethernet 'PPPOE' Author(s) : L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler Filename : draft-carrel-info-pppoe-01.txt Pages : 13 Date : 15-Sep-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-carrel-info-pppoe-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-carrel-info-pppoe-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-carrel-info-pppoe-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@ietf.org" Content-Type: text/plain Content-ID: <19980915135130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-carrel-info-pppoe-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-carrel-info-pppoe-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980915135130.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 16 10:59:08 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA07172; Wed, 16 Sep 1998 10:57:33 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 16 Sep 1998 10:56:03 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA07042 for ietf-ppp-outgoing; Wed, 16 Sep 1998 10:56:02 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA07028 for ; Wed, 16 Sep 1998 10:55:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA21797; Wed, 16 Sep 1998 10:54:55 -0400 (EDT) Message-Id: <199809161454.KAA21797@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-lcp-charset-04.txt Date: Wed, 16 Sep 1998 10:54:55 -0400 Sender: owner-ietf-ppp@merit.edu --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 LCP Internationalization Configuration Option Author(s) : G. Zorn Filename : draft-ietf-pppext-lcp-charset-04.txt Pages : 5 Date : 15-Sep-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-lcp-charset-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-lcp-charset-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-lcp-charset-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@ietf.org" Content-Type: text/plain Content-ID: <19980915110123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-lcp-charset-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-lcp-charset-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980915110123.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 23 10:49:41 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA24836; Wed, 23 Sep 1998 10:47:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Sep 1998 10:43:11 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA24748 for ietf-ppp-outgoing; Wed, 23 Sep 1998 10:43:10 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA24737 for ; Wed, 23 Sep 1998 10:43:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06598; Wed, 23 Sep 1998 10:42:29 -0400 (EDT) Message-Id: <199809231442.KAA06598@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mppe-02.txt Date: Wed, 23 Sep 1998 10:42:28 -0400 Sender: owner-ietf-ppp@merit.edu --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 : Microsoft Point-To-Point Encryption (MPPE) Protocol Author(s) : G. Pall, G. Zorn Filename : draft-ietf-pppext-mppe-02.txt Pages : 12 Date : 22-Sep-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to Point Encryp- tion (MPPE) to enhance the confidentiality of encrypted PPP-encapsulated packets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-mppe-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-mppe-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mppe-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@ietf.org" Content-Type: text/plain Content-ID: <19980922104528.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mppe-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mppe-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980922104528.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 23 10:49:43 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA24843; Wed, 23 Sep 1998 10:47:10 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 23 Sep 1998 10:43:05 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA24738 for ietf-ppp-outgoing; Wed, 23 Sep 1998 10:43:04 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA24733 for ; Wed, 23 Sep 1998 10:42:57 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06585; Wed, 23 Sep 1998 10:42:19 -0400 (EDT) Message-Id: <199809231442.KAA06585@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mschapv1-keys-00.txt Date: Wed, 23 Sep 1998 10:42:18 -0400 Sender: owner-ietf-ppp@merit.edu --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 : Deriving MPPE Keys From MS-CHAP V1 Credentials Author(s) : G. Zorn Filename : draft-ietf-pppext-mschapv1-keys-00.txt Pages : 7 Date : 22-Sep-98 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) [3] is a Microsoft-proprietary PPP authentication protocol, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks. Microsoft Point to Point Encryption (MPPE) [4] is a means of represent- ing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive the initial MPPE ses- sion keys from MS-CHAP credentials. The algorithm used to change ses- sion keys during a session is described in [4]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-mschapv1-keys-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-pppext-mschapv1-keys-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mschapv1-keys-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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@ietf.org" Content-Type: text/plain Content-ID: <19980922104108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mschapv1-keys-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mschapv1-keys-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980922104108.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 28 10:16:09 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA25601; Mon, 28 Sep 1998 10:14:36 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Sep 1998 10:05:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA24960 for ietf-ppp-outgoing; Mon, 28 Sep 1998 10:05:31 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA24953 for ; Mon, 28 Sep 1998 10:05:24 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA29347 for ietf-ppp@merit.edu; Mon, 28 Sep 1998 10:05:24 -0400 (EDT) Received: from SanFrancisco01.POP.InterNex.Net (sanfrancisco01.pop.internex.net [205.158.3.50]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA05635 for ; Sat, 26 Sep 1998 16:44:56 -0400 (EDT) Received: from junior ([205.158.231.114]) by SanFrancisco01.POP.InterNex.Net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-34792U7500L7500S0) with SMTP id AAA2983; Sat, 26 Sep 1998 13:44:53 -0700 Message-Id: <3.0.32.19980926133431.00e107e0@SanFrancisco01.pop.internex.net> X-Sender: larribeau-2@SanFrancisco01.pop.internex.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 26 Sep 1998 13:45:13 -0700 To: ietf-ppp@merit.edu, l2tp@zendo.com From: bob@larribeau.com (Bob Larribeau) Subject: VPN Inteoperability Workshop Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_906867913==_" Sender: owner-ietf-ppp@merit.edu --=====================_906867913==_ Content-Type: text/plain; charset="us-ascii" The VPN Interoperability Workshop is filling up rapidly. A list of the attendees is in the attached PDF file. If you have already sent us your applications, check the PDF file to be sure your application is included. In the aftermath of a crashed hard disk I think I lost about one dozen email on the afternoon of Friday, September 19. Send your application to me again if it does not appear on this list. If you have not sent your application in yet, do so right away. I expect we will fill up by the end of the week. You can find an application and more information about the workshop at http://www.ciug.org. Contact me if you have any questions. Bob Larribeau --=====================_906867913==_ Content-Type: application/octet-stream; name="PPP9contacts01R.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PPP9contacts01R.pdf" JVBERi0xLjIgDSXi48/TDQogDTEwIDAgb2JqDTw8DS9MZW5ndGggMTEgMCBSDS9GaWx0ZXIgL0xa V0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0YiAYQYQQUbjYXDAcCAbDmGRIQCAqG0GweNC4ajAZCA5 GcQA0XkaDjIYQ0YDmHxYzA0WykYSuKlQxwaGjIbDWancQCgrFAnCArm85Gs5mg3nAQEE6HQym4yG UynMUxY1A0iwOUjcajIczivWCxV+wyGRjcZC4ZDQQDcYjUXDaHjQbDe2Q8Yi4cx85GUQS+BQQcjQ XDEbRAajmG26LESMwiUx2/SKSSaE3uZjXHFSXzIa4mLTeDxafCgkkSrlSsi0YjEcQ2H6UqEQQTGG jcby2bT8hm82nAwm486usjEaYyvwjHziPDEbzWbigjGk5HM6E4wm0y8YGjfDDjZzXbbiPDYZ9Kfk ww9jtdzva/GQvmbXbzIaDOeaPfcDhOI7ytu+ta2ogtQXBouq7ryhK2JAwCXwPAqdr2HC3LsvAZL1 BC3L+wIGsGgqNISEAZBkuTEhsGiPosjERoOtDLoKGKZBg5Kas+lTdPUFApDeNA0jo7zwBc8TXvq2 0arhHgrDKOQ2jC+IYvmGzYSQ5wYLvHgZt+NrvBaGUphcGb0PS2kkskjiPJAy0lPS/gUBzL4YrbIo YSnK7zBqGc3t6FEuOA+Lko5Ez0tcuU6PIySERjJSwzgJQyjMM0hvCHEjzPLD6TgIw3juNknSlKkr UzJUWN7GrkJ6n9ADaEDfjkOAXS/E1LBmt1SzSyk2JHNz1No08VznMUNVJRU9T5Lcu0E5VCtu5Eit 5NER0bHVTumIo7OHSto0xRVTR4IYwjsqtRBchdjObGobNFPwgiGIdaTq8VbyvF81MrXsdT66b9WG xlivG5rzBves4XfeKsIJQavhlQy4sPU9p0ZNsdILOAhDCN9uSNEVv2tHgoDRbeFPlc8q4E+110fV CVOhVYUKKOQ2DJLqmicKd5VtXFv11Ndqpngtf5hPl/rzdL7YJg13ZxZlCYdZ9LZ7amK6CzrpiIoz i4VImO3tHWWOmJgyjSM1Q5LMV0ZTJMdavLFEtMn4gjmMaojJV7gDaOo3DSMYwjoNI3jcq2FTBMUy WTXKN13oAYaE/lgJ+GM53nO6w0y8wZhk6OD7pu2nYbh9EYlRcYarx2wp/SNJr/rbWO/S1vXVfceC ON43jIO40jdc21a/oPOZamaHZhuY0VAPIQPYOq/jcOgWBAJI3DHWfCzCxnETNqaccZ0/H1RonKPD y08plGnU/MHL9io0/jeR5Qw+YqMhZLhlnNdqV1UXxvvtJmAUg0h6DuyR17XVLsedm0E3h0wmhhDY GyBzvWUO/ccu00jLnih4fmRYMoYw0BuDeGwN4Zw0lVBeFIMIcH6OvTAvMHC9XFPcZ+95fh9TTo0a MwF8pjQYPrOmEGDTznQP3Yg3BlT+3vQLPWGkOaUWuOxgQypHUFifhXDSGwNbuw5uCgk0htjQYqKp ZgxkNjgA2lGMAFSDsH4QwjDfCVwkLFarRhg9sycM19NBhq5EFBcYcqXbWfchqeGMQOjNGiIbUH8L RjsrwjKOkeBTZGHd3kT1uxRi+45HkDQ2hyDfHE47aYJqlbar9lypzTsZeSE4ModA7lGKQzqOjPH9 OLjxI+PTQ24x9BlH+Lymm3G4YceKMYYZVytleUeUDC1myKiK6RF8jklNuj49IqaT0fwEKzAZ2UUp cuQZcn004U3dhnDQCAJrggzxOdeyZ30pGrSmJnEaVMxgQSsldLCZcLWdr2Z8vmXDjo9tEBtL6QM0 z1TCBnMSXcqp7zIn1Ilh7+YjtUjylmajMAihtSgxyA8FEdpwgaHJwElZ2yil/QicE85UG+DCGJUA dJPBuBAFMPJ2AyhtDmCALgKAiBOChLJektKKwyoAr5yDMD80Gh2+ROC4qYStpnRJZ7o5Gv8ioCgJ rfWRhlDZR6bsmYlI9bJA910oVR0HlLStO9LQUBDiYGMN9NablQp1UKF9RGJx3qO7SpMu0NVMcwfh Gy4a4sbfrM2icjJasUouptPwQw0JODzV+SzXp4OOYun6BoZIt0mrQyelNa3hVtZhXBulc6bU4ru9 aF0dbG18mlX58EuwaA1sEsewjbq32HqoodiNV3TqXkiGENSQawSYmAjwITIw5hrDCHKbRBKUVqnj Wyeh/Q5u7MAl1vTfG/OAcFPt66Y0yz+ltX2b9tX2E/Bu+JOyeLBkNc1D67V3LfrQoZUV01j3gnTC gdYNd0Lk0gt4FCBxwAwxZi7dZx1/0sE0l2ERv4YQQBGq9CIO4c3oPSeorRw954Y2yf5QOXdBXCp0 fHfK3Ugz8o8woHQMOGIHqemWcixVVbg2xtnes6YRy/hnwLZmkNkbolQDlg2kGEEa4SvaCgIrzg5B 1OxByD0IIRQkXK9bELiY7L4x7QKXWTwcXwBw+S+Z577ZQyllSFZx37TOopXvMNkDpwADGGvIbH2g upBQFMMruoH5KyJGGDEuwjYaChG95zeFYlGb+4G0BMI51DvRUbOuJsnuatywN9Nmzp6JU9ot3eb5 mNPdFju/mdaso+DEk7U03LlKOdqk4OSQcb3VpBoaebMAjUzcAk7K0bMsxwbxXi2F/MwYlzGacGbk 8UrEkBU1E2oCf6/cFsHJNidUNRsZqt/lvAp3RduHDPcCXHZrgaHQNDzNCZ8eInBIAZtJz8lnpfEk NEeA0Bhp2b28U/bz0njjbtwIjZ0f4tc3yoDuaT1lgZHgSg6ndbRWnXc8k7swCRoGmIdAQYIzzdEM myK9Ol2Xvqv+T0T7+kyuxHgSKg7cdDt6/fCHvVZsldFUEy+H6FR4EtvYepytnpPxbIm1jUBCCbyT fHJ7Hw1j7iiFjJoddHR4EnpV+arY8f5mvX5w89WXo/kTNeFHd7v3QV7jCR5d9YCbo4OGkLxb10rX npr3en7NcknLaLANp9WTh26/Oc3S6ZZC/EFtkio7n3+kup9kw3ZC4raLB3arsWbNP24EAUiqhluj B4EARA0h2iZpLpmI+nUBf7DYn5KOWKa6R4LmUROt7ge9woFAQUnnDDJYiAsUKQVj6+VDoXaPG+x6 za6fvqO8eq6gTr16SvkdL9nnLb/NrH5rzwGjxkmTdshggG4OrgNc9G3h45P3so5Wv5Kvf5tSE/Ob +ixbq/yZ25x1TwfwtWEeau1g+6U03Uk+DWU8SCD0+M+89iCGCmCC9Oy+/etoOmI69eT0LI8DAXAa +qsW5q/25uk2q4DCq9AASUzWUipmDSjPAQU0iUyaN48yecq87g7k9M+U3u+Ylu/gf8sA746m2kl+ cyByz8ekKgss/uxy4MmgiQset4wo9I5G7ErC9gXCDeDxBURquI8DBgZmd27C/W+XAfBxAiJ+Bove 76aOkCPMNgqzCGScDZC48G+vA6v8uZBODmggDtBGR0zWCWPbDvCsim7WZgCSCkCKpqg6fkpqhC/G 0kvI/Y7vDCx89YBQYc/nEiNREI601U+w9Uz84kDcBaq4Os98m2+AyJCEDoR/D/EiVSnEJ+CWCCCb EKCgk8DUg61M3s0tBuvUzE5ShuBpEqSyrHD4PhA05oWlDk9Uqyq2g9BDCLFIku4uTgCWhE/K8opA vsVS8xFcCYCeCm2GywhGjgw6enActi9TBzEkNfGAztFdGpEy/0mi3CR4O0uku2DaZG4dFK/O9whQ nMXGumnclG/O144yl2CYDqbq0ajUyujay1EbC/HNAhFWZgBiBnAoJkc0t5IPIS1M4I5mkXA5Hie8 t4CUR/HzGgyI3FFQSfGqnfIHEDINIQg3IW2JHCy3C9BtDBF29Wj4Bq2hB679B/IwQKThI2fnEyTI uFCWkiKgXJDyaC6QN+DEDFFUccrHGWk8i2DNFu7q2Sr3HPDET+37DM6qxaTuBwz9Kwk+DfK3DhJD CVGS/7BADlCe9/JRH25e7A4o6LGs7I7XG0BQnwCmDGL+KjG/IajgxAewxFJ08NF6J+twxScqxY08 kGL7HmlbMHMK4G/wx1HhLgSUqyisgeDSO3KedQ8OjK6ItDJc7SmolOZgnwmSDWKaDYg8pyrO0pEd F1McvYhuzLLI7/LMJXBYkGQtNiogKPNrNuDbNzI8iI8JJFKXMep8XGDTLrGesw/O6Qgas/KqyKgu eGZYNPNklgKaDmi2DHNKKgw4eiemerJxFzMa2ZOoVvIuJUJ2nkLjMBPLOUbnPTPXJuKyQEMGIWNk Le9qMgJKIOMYJmBoM6JecyBw4UPMSrPGJ+3GDoeYDImMeg0AhUpy1eDkRKBsegSmJYO8BoNgTGI+ zSORQoJkBwXaNOwQDOMAILLYRKQCIGICDWVuZHN0cmVhbQ1lbmRvYmoNMTEgMCBvYmoNMzE5Ng1l bmRvYmoNNCAwIG9iag08PA0vVHlwZSAvUGFnZQ0vUGFyZW50IDUgMCBSDS9SZXNvdXJjZXMgPDwN L0ZvbnQgPDwNL0YwIDYgMCBSIA0vRjEgOCAwIFIgDT4+DS9Qcm9jU2V0IDIgMCBSDT4+DS9Db250 ZW50cyAxMCAwIFINPj4NZW5kb2JqDTEzIDAgb2JqDTw8DS9MZW5ndGggMTQgMCBSDS9GaWx0ZXIg L0xaV0RlY29kZSANPj4Nc3RyZWFtDQqAEIqA0YjkaC4YjYQDcYDUXDOFCAqEQGjAQRYYC4ajAZCA 5GcQA0XkaLDEYi4YQ0aCCJGaKygaxEqGOLywqHcQCgkkQUxI1A0WyYcSgcTWJEQQC2MjAbjeixKa Cghm82nAwm48z0qT8YjQcxqOxajxeUDIYjebVEjGk5HM6E4wm0y1qfjeDjii2KJ0mljIbDO0zkmG G3XC5XSCQUXDeFXqkUqUDQZjXA1KqVasYgiwMbjIXDKVjcY0OijQbDfP0WTx05GUQS7O5+VjYc0O EiDTagZaoXDSV63Xg2BQSayUQDIZQ6FDa8Q+OxI2xXix6QSIjDEQDGljCvTaXdu7ZUpnU3GQwnLE XYXXiTUa9+DKVCclIwmrESav4zR+6kfDAu29qJJwFAnDKOg7jeOQ1okMo2DKOY8rcMo2jmxAWuQu 4cBmlbHOmjKNtY6rwMA+S9QG00LPw1L9w6yCUhqp6ZrIGCupXAScwLA8EwWKkGwfCI6QnCqfIIry wBkwCgwymz+umj6QvAtESptAYpjQMo0jYML0wy9sOyiyojDkq41wa+7FP0vMmRmpjnxlAgkimKkL Qw9cNQ5NaMLJEDqSglCmRJN4ZhxFLFN3Fk1xcGrdsqJ04znIiuq/RckKSGKHBjN0mz1J6XpTKU3i QMI3y5O0vTzP7RMqLA6zO/IbUQsbwJkqIoDqNg5rnIkLtBO0Nv5DyNI5PtPUAyrQUKr9DzUscXBo 7jK1tXFdK3ItJuRJNLoRTUPWI8DsPkFApDeNwyjdUr2OxL9U3BUIwjRc9IzRWFmPfdj/z/S8qPmI IiCOKogikIgWBAJg6DIF06V6vFfy+4thRDP1P0CmkTJyGYb2TFd6sevrJsqKV+3/gKeUjI1KWzTF uT0i1OzBcIpjGN46DpdAcVPWVUxiqIlwaNis3lV9Y3tid8JSGNAwGKQyjIIbWjLBapjaNryDSMYw joNNSV3OuGTxWWHz5l1U4o90T0JXcVWXYEXORUCo6XpunjW++T2xS0l7BTkRbJkA3jnIdqvVdNgP BG03ivK8fPRoLF3pwtUvjGUAXbpQ3jrII5Cu87XCSNwx4TrjFIgGbAYcjGIW9vspxuFAaRThcaBz tiloTyW4cvzI785utr0qoOVTzJ2+U/w6ovG1o5jRm2caIplaJyJYwjYNbySDV3HaG/tU+hAF9hRK w0jsMIQKmOQ4QTrGtXjateQzhvhdRsXiWN1ibpys2NbXFql2f25OXwvjd6kdbLeT3vDYkUx/4KEe hya24JLq6lUKfXaVEJq5FyLmewmlyCn03MVXy4dKoUwkPlKo1QNzVn1LkDmCAKa1CfvuV81+A78l htjaK/ZE7r20qGZuxxNgNnoPghJANlClngt6JrDhNplQqBpDa8yCTOVPxDCUuYNYaQ3OBK4vN7Sb Abv/co9+J5cgppBDhCZ876WsrkYU++Gim09w3foDdsrFgUHIf1D92hZQZNvJzGUMsZwyhwiM3dJS dn4xLjrAsIqDg3JbSI4Nm8U3nGdZAHkMIYg1wPi60KIB/kSr5crIEOQdS3BXR3C0KaQEhAgCEC4K zoX2tdTu4VsMdIEx2P+98s8e4voudtE6U8qZVyHd+tpTMi2Wx1iGEFBweIpQdiauEIgZQwsyfZJ9 7MoVUyABQFYMocg0hTDSGebZQJbPwiUh+XSxZeLhBmDmYEQG2qVXDOKck5p0TIgLIqdrqniniDqG 0NLNZJwRmoU4yoVgwxZDZBtx664PUNCgjmN8M5cQ2YjPBsrrgYz1j6dwGDOychWougaf0SFtzMoF NVN59DytAggqaSz26BrhCEgly4Zw0RcMTKChbxk2TLda5sOgYw0BHDqecMiDKlBuDeGwN4Zw0wwn UwuW7p450dRHL11pXqRP8JQQmkwKKkVKqZU6lciS8UuiZGEyoTAyrkrZQmm1C4FsxDQ7sOQdA9US i+rNoyNHvhYaYGl8j5n0JjjbOlC7oy/ummY6muMd3vgydgXd2VI3/KrsTJJapmzhGcBsUQhcSSJn WIsV8lJvjvFAKWoOD5fCUKwdm60KbWA6hyPMHlgkLw4JBDaGKcZxwbMEIKbUxANDRnOpGV22qLgc EyQGFAMIZzXEdDeGY45miBkBDWVuZHN0cmVhbQ1lbmRvYmoNMTQgMCBvYmoNMTU5MQ1lbmRvYmoN MTIgMCBvYmoNPDwNL1R5cGUgL1BhZ2UNL1BhcmVudCA1IDAgUg0vUmVzb3VyY2VzIDw8DS9Gb250 IDw8DS9GMCA2IDAgUiANL0YxIDggMCBSIA0+Pg0vUHJvY1NldCAyIDAgUg0+Pg0vQ29udGVudHMg MTMgMCBSDT4+DWVuZG9iag02IDAgb2JqDTw8DS9UeXBlIC9Gb250DS9TdWJ0eXBlIC9UcnVlVHlw ZQ0vTmFtZSAvRjANL0Jhc2VGb250IC9UaW1lc05ld1JvbWFuLEJvbGRJdGFsaWMNL0ZpcnN0Q2hh ciAzMg0vTGFzdENoYXIgMjU1DS9XaWR0aHMgWyAyNTEgMzcxIDU1MSA0OTEgNTAzIDgzOSA3Nzkg Mjc1IDMzNSAzMzUgNTAzIDU2MyAyNTEgMzM1IDI1MSAyNzUgDTUwMyA1MDMgNTAzIDUwMyA1MDMg NTAzIDUwMyA1MDMgNTAzIDUwMyAzMzUgMzM1IDU2MyA1NjMgNTYzIDUwMyANODI3IDY1OSA2NTkg NjU5IDcxOSA2NTkgNjU5IDcxOSA3NzkgMzgzIDUwMyA2NTkgNjExIDg4NyA3MTkgNzE5IA02MTEg NzE5IDY1OSA1NTEgNjExIDcxOSA2NTkgODg3IDY1OSA2MTEgNjExIDMzNSAyNzUgMzM1IDU2MyA1 MDMgDTMzNSA1MDMgNTAzIDQ0MyA1MDMgNDQzIDMzNSA1MDMgNTUxIDI3NSAyNzUgNTAzIDI3NSA3 OTEgNTUxIDUwMyANNTAzIDUwMyAzODMgMzgzIDI3NSA1NTEgNDQzIDY1OSA1MDMgNDQzIDM4MyAz NDcgMjE1IDM0NyA1NjMgNzc5IA03NzkgNzc5IDU2MyA1NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA1 NjMgNTYzIDU2MyA1NjMgNzc5IDc3OSA3NzkgDTc3OSA1NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA1 NjMgNTYzIDU2MyA1NjMgNTYzIDU2MyA3NzkgNzc5IDU2MyANMjUxIDM4MyA1MDMgNTAzIDQ5MSA1 MDMgMjE1IDUwMyAzMzUgNzU1IDI2MyA1MDMgNTk5IDMzNSA3MzEgNTAzIA0zOTUgNTUxIDI5OSAz MTEgMzM1IDU3NSA1MDMgMjUxIDMzNSAyOTkgMjk5IDUwMyA3NDMgNzQzIDc1NSA1MDMgDTY1OSA2 NTkgNjU5IDY1OSA2NTkgNjU5IDkzNSA2NTkgNjU5IDY1OSA2NTkgNjU5IDM4MyAzODMgMzgzIDM4 MyANNzE5IDcxOSA3MTkgNzE5IDcxOSA3MTkgNzE5IDU2MyA3MTkgNzE5IDcxOSA3MTkgNzE5IDYx MSA2MTEgNTAzIA01MDMgNTAzIDUwMyA1MDMgNTAzIDUwMyA3MTkgNDQzIDQ0MyA0NDMgNDQzIDQ0 MyAyNzUgMjc1IDI3NSAyNzUgDTUwMyA1NTEgNTAzIDUwMyA1MDMgNTAzIDUwMyA1NTEgNTAzIDU1 MSA1NTEgNTUxIDU1MSA0NDMgNTAzIDQ0MyANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0v Rm9udERlc2NyaXB0b3IgNyAwIFINPj4NZW5kb2JqDTcgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNj cmlwdG9yDS9Gb250TmFtZSAvVGltZXNOZXdSb21hbixCb2xkSXRhbGljDS9GbGFncyAxNjQ4Mg0v Rm9udEJCb3ggWyAtMjUwIC0yMTYgMTEyMyAxMDQwIF0NL01pc3NpbmdXaWR0aCAzMzYNL1N0ZW1W IDEzMQ0vU3RlbUggMTMxDS9JdGFsaWNBbmdsZSAtMTENL0NhcEhlaWdodCA4OTENL1hIZWlnaHQg NDQ2DS9Bc2NlbnQgODkxDS9EZXNjZW50IC0yMTYNL0xlYWRpbmcgMTQ5DS9NYXhXaWR0aCA5MzYN L0F2Z1dpZHRoIDQxMg0+Pg1lbmRvYmoNOCAwIG9iag08PA0vVHlwZSAvRm9udA0vU3VidHlwZSAv VHJ1ZVR5cGUNL05hbWUgL0YxDS9CYXNlRm9udCAvQXJpYWwNL0ZpcnN0Q2hhciAzMg0vTGFzdENo YXIgMjU1DS9XaWR0aHMgWyAyODcgMzM1IDM1OSA1NTEgNTUxIDg4NyA2NzEgMTkxIDMzNSAzMzUg MzgzIDU5OSAyODcgMzM1IDI4NyAyODcgDTU1MSA1NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA1NTEg NTUxIDU1MSAyODcgMjg3IDU5OSA1OTkgNTk5IDU1MSANMTAzMSA2NzEgNjcxIDcxOSA3MTkgNjcx IDYyMyA3OTEgNzE5IDI4NyA1MDMgNjcxIDU1MSA4MzkgNzE5IDc5MSANNjcxIDc5MSA3MTkgNjcx IDYyMyA3MTkgNjcxIDEwMDcgNjQ3IDY3MSA2MjMgMjg3IDI4NyAyODcgNDU1IDU1MSANMzM1IDU1 MSA1NTEgNTAzIDU1MSA1NTEgMzExIDU1MSA1NTEgMjM5IDIzOSA1MDMgMjM5IDg2MyA1NTEgNTUx IA01NTEgNTUxIDMzNSA0NzkgMjg3IDU1MSA1NTEgNjk1IDUyNyA1MDMgNTAzIDMzNSAyNjMgMzM1 IDU5OSA3NjcgDTc2NyA3NjcgNTk5IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5 IDU5OSA3NjcgNzY3IDc2NyANNzY3IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5IDU5OSA1OTkgNTk5 IDU5OSA1OTkgNTk5IDc2NyA3NjcgNTk5IA0yODcgMzM1IDU1MSA1NTEgNTUxIDU1MSAyNjMgNTUx IDMzNSA3NDMgMzgzIDU1MSA1OTkgMzM1IDc0MyA1NTEgDTQwNyA1NTEgMzM1IDMzNSAzMzUgNTc1 IDU1MSAyODcgMzM1IDMzNSAzNTkgNTUxIDgzOSA4MzkgODM5IDYyMyANNjcxIDY3MSA2NzEgNjcx IDY3MSA2NzEgMTAwNyA3MTkgNjcxIDY3MSA2NzEgNjcxIDI4NyAyODcgMjg3IDI4NyANNzE5IDcx OSA3OTEgNzkxIDc5MSA3OTEgNzkxIDU5OSA3OTEgNzE5IDcxOSA3MTkgNzE5IDY3MSA2NzEgNjIz IA01NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA4ODcgNTAzIDU1MSA1NTEgNTUxIDU1MSAyODcgMjg3 IDI4NyAyODcgDTU1MSA1NTEgNTUxIDU1MSA1NTEgNTUxIDU1MSA1NTEgNjIzIDU1MSA1NTEgNTUx IDU1MSA1MDMgNTUxIDUwMyANXQ0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0vRm9udERlc2Ny aXB0b3IgOSAwIFINPj4NZW5kb2JqDTkgMCBvYmoNPDwNL1R5cGUgL0ZvbnREZXNjcmlwdG9yDS9G b250TmFtZSAvQXJpYWwNL0ZsYWdzIDMyDS9Gb250QkJveCBbIC0yNTAgLTIxMiAxMjM3IDEwNTUg XQ0vTWlzc2luZ1dpZHRoIDI4OA0vU3RlbVYgODANL1N0ZW1IIDgwDS9JdGFsaWNBbmdsZSAwDS9D YXBIZWlnaHQgOTA1DS9YSGVpZ2h0IDQ1Mw0vQXNjZW50IDkwNQ0vRGVzY2VudCAtMjEyDS9MZWFk aW5nIDE1MA0vTWF4V2lkdGggMTAzMQ0vQXZnV2lkdGggNDQxDT4+DWVuZG9iag0yIDAgb2JqDVsg L1BERiAvVGV4dCAgXQ1lbmRvYmoNNSAwIG9iag08PA0vS2lkcyBbNCAwIFIgMTIgMCBSIF0NL0Nv dW50IDINL1R5cGUgL1BhZ2VzDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NPj4NZW5kb2JqDTEg MCBvYmoNPDwNL0NyZWF0b3IgKCkNL0NyZWF0aW9uRGF0ZSAoRDoxOTk4MDkyNjEzMjE0NykNL1Rp dGxlIChQUFA5KQ0vQXV0aG9yIChBZG1pbmlzdHJhdG9yKQ0vUHJvZHVjZXIgKEFjcm9iYXQgUERG V3JpdGVyIDMuMDIgZm9yIFdpbmRvd3MgTlQpDS9LZXl3b3JkcyAoKQ0vU3ViamVjdCAoKQ0+Pg1l bmRvYmoNMyAwIG9iag08PA0vUGFnZXMgNSAwIFINL1R5cGUgL0NhdGFsb2cNPj4NZW5kb2JqDXhy ZWYNMCAxNQ0wMDAwMDAwMDAwIDY1NTM1IGYgDTAwMDAwMDgwOTIgMDAwMDAgbiANMDAwMDAwNzk3 MCAwMDAwMCBuIA0wMDAwMDA4MjcxIDAwMDAwIG4gDTAwMDAwMDMzMTIgMDAwMDAgbiANMDAwMDAw ODAwMSAwMDAwMCBuIA0wMDAwMDA1MjYxIDAwMDAwIG4gDTAwMDAwMDYzNTggMDAwMDAgbiANMDAw MDAwNjYzNiAwMDAwMCBuIA0wMDAwMDA3NzE3IDAwMDAwIG4gDTAwMDAwMDAwMTkgMDAwMDAgbiAN MDAwMDAwMzI5MSAwMDAwMCBuIA0wMDAwMDA1MTMwIDAwMDAwIG4gDTAwMDAwMDM0NDIgMDAwMDAg biANMDAwMDAwNTEwOSAwMDAwMCBuIA10cmFpbGVyDTw8DS9TaXplIDE1DS9Sb290IDMgMCBSDS9J bmZvIDEgMCBSDS9JRCBbPGUwOTg1NzEwNGI5Njk3MmY0ODAyOGYzMjBjYjFlYjY5PjxlMDk4NTcx MDRiOTY5NzJmNDgwMjhmMzIwY2IxZWI2OT5dDT4+DXN0YXJ0eHJlZg04MzIwDSUlRU9GDQ== --=====================_906867913==_ Content-Type: text/plain; charset="us-ascii" ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco --=====================_906867913==_-- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Mon Sep 28 16:06:48 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id QAA03212; Mon, 28 Sep 1998 16:06:27 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Mon, 28 Sep 1998 16:04:19 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA03153 for ietf-ppp-outgoing; Mon, 28 Sep 1998 16:04:18 -0400 (EDT) Received: from adn.alcatel.com ([198.205.32.33]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA03137 for ; Mon, 28 Sep 1998 16:04:07 -0400 (EDT) Received: from hartford.adn.alcatel.com (hartford [198.205.43.63]) by adn.alcatel.com with SMTP (8.7.6/8.7.1) id PAA02006 for ; Mon, 28 Sep 1998 15:59:32 -0400 (EDT) Received: from localhost by hartford.adn.alcatel.com (4.1/SMI-4.0) id AA05073; Mon, 28 Sep 98 16:02:54 EDT Date: Mon, 28 Sep 1998 16:02:53 -0400 (EDT) From: Mukesh Bhatla X-Sender: mbhatla@hartford To: ietf-ppp@merit.edu Subject: PPP source code. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Hi, I need PPP source code. Could anyone tell me from where I can download the public domain source code for PPP. thanks, Mukesh. ----------------------------------------------------------------------- Mukesh Bhatla Phone: (703) 724-2623(Off.) Alcatel Data Networks (703) 724-2003(Fax.) email: mbhatla@adn.alcatel.com ----------------------------------------------------------------------- - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 29 07:55:09 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id HAA17970; Tue, 29 Sep 1998 07:52:29 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Sep 1998 07:47:15 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA17913 for ietf-ppp-outgoing; Tue, 29 Sep 1998 07:47:14 -0400 (EDT) Received: from ironbridgenetworks.com (helios.ironbridgenetworks.com [146.115.140.2]) by merit.edu (8.8.7/8.8.5) with SMTP id HAA17909 for ; Tue, 29 Sep 1998 07:47:08 -0400 (EDT) Received: by ironbridgenetworks.com (SMI-8.6/SMI-SVR4) id HAA11010; Tue, 29 Sep 1998 07:47:07 -0400 To: ietf-ppp@merit.edu Path: not-for-mail From: James Carlson Newsgroups: lists.ietf.ppp Subject: Re: PPP source code. Date: 29 Sep 1998 07:47:07 -0400 Organization: IronBridge Networks Lines: 18 Message-ID: <86ww6n87k4.fsf@helios.nis.ironbridgenetworks.com> References: NNTP-Posting-Host: helios.ibnets.com X-Newsreader: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu mbhatla@adn.alcatel.com (Mukesh Bhatla) writes: > I need PPP source code. Could anyone tell me from where I > can download the public domain source code for PPP. _The_ public domain source? I don't think any version is actually in the public domain, though there are quite a few that are freely available as source code. You can get one of the best versions here (assuming, of course, you're running Unix): ftp://cs.anu.edu.au/pub/software/ppp/ppp-2.3.5.tar.gz -- James Carlson, Consulting S/W Engineer IronBridge Networks / 55 Hayden Avenue 71.246W Vox: +1 781 372 8132 Lexington MA 02421-7996 / USA 42.423N Fax: +1 781 372 8190 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 29 10:43:31 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id KAA21026; Tue, 29 Sep 1998 10:41:07 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Sep 1998 10:38:46 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA20952 for ietf-ppp-outgoing; Tue, 29 Sep 1998 10:38:45 -0400 (EDT) Received: from home.merit.edu (home.merit.edu [198.108.60.42]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA20946 for ; Tue, 29 Sep 1998 10:38:41 -0400 (EDT) Received: (from ljb@localhost) by home.merit.edu (8.8.8/merit-2.0) id KAA13538 for ietf-ppp@merit.edu; Tue, 29 Sep 1998 10:38:40 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA18450 for ; Tue, 29 Sep 1998 08:29:44 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA07810; Tue, 29 Sep 1998 08:28:39 -0400 (EDT) Message-Id: <199809291228.IAA07810@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@merit.edu From: The IESG Subject: Document Action: Microsoft PPP CHAP Extensions to Informational Date: Tue, 29 Sep 1998 08:28:39 -0400 Sender: owner-ietf-ppp@merit.edu The IESG has approved the Internet-Draft Microsoft PPP CHAP Extensions as a Informational RFC. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Note to RFC Editor: Please add the following text as an IESG Note: The protocol described here has significant vulnerabilities. People planning on implementing or using this protocol should read section 12 "Security Considerations." - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Tue Sep 29 14:32:28 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id OAA26030; Tue, 29 Sep 1998 14:32:04 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Tue, 29 Sep 1998 14:29:28 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA25918 for ietf-ppp-outgoing; Tue, 29 Sep 1998 14:29:27 -0400 (EDT) Received: from volitans.MorningStar.Com (volitans.MorningStar.Com [137.175.2.11]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA25908 for ; Tue, 29 Sep 1998 14:29:21 -0400 (EDT) Received: from carp.morningstar.com (carp.MorningStar.Com [137.175.81.4]) by volitans.MorningStar.Com (8.9.0/8.9.0) with ESMTP id OAA09641 for ; Tue, 29 Sep 1998 14:29:18 -0400 (EDT) Received: by carp.morningstar.com (8.8.8/95031605) id OAA09017; Tue, 29 Sep 1998 14:29:17 -0400 (EDT) From: Karl Fox Reply-To: Karl Fox To: ietf-ppp@merit.edu Subject: PPP LCP Internationalization Configuration Option - Working Group Last Call Date: 29 Sep 1998 14:29:17 -0400 Message-ID: Lines: 7 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-ietf-ppp@merit.edu This is last call. I will advise the area directors that we want to take PPP LCP Internationalization Configuration Option (draft-ietf-pppext-lcp-charset-04.txt) to Proposed Standard on October 13 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 655 Metro Place South, Suite 370, Dublin, Ohio 43017 +1 614 760 4041 - - - - - - - - - - - - - - - - - From owner-ietf-ppp@merit.edu Wed Sep 30 02:46:33 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id CAA06594; Wed, 30 Sep 1998 02:46:09 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Wed, 30 Sep 1998 02:42:42 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA06537 for ietf-ppp-outgoing; Wed, 30 Sep 1998 02:42:42 -0400 (EDT) Received: from djwhome.demon.co.uk (root@djwhome.demon.co.uk [158.152.19.5]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA06533 for ; Wed, 30 Sep 1998 02:42:36 -0400 (EDT) Received: (from david@localhost) by djwhome.demon.co.uk (8.8.8/8.7.3) id HAA01900; Tue, 29 Sep 1998 07:56:43 +0100 From: David Woolley Message-Id: <199809290656.HAA01900@djwhome.demon.co.uk> Subject: Re: PPP source code. To: mbhatla@adn.alcatel.com (Mukesh Bhatla) Date: Tue, 29 Sep 1998 07:56:40 +0100 (BST) Cc: ietf-ppp@merit.edu In-Reply-To: from "Mukesh Bhatla" at Sep 28, 98 04:02:53 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu > I need PPP source code. Could anyone tell me from where I > can download the public domain source code for PPP. ??? I'm not aware of any public domain code. There is fairly free code available from any Linux archive (it is portable so it may well be in other places). It is by no means an authorative implementation. You will need to make your own judgements as to whether the licence conditions are acceptable, although I think it is Berkeley like, so reasonable commercial use may not be a problem. (Public domain code is actually a very rare thing, and for some countries cannot come into existence until a long time after the authors death.) - - - - - - - - - - - - - - - - -