From pppext-bounces@ietf.org Thu Dec 08 04:06:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHjT-0005kO-87; Thu, 08 Dec 2005 04:06:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkHjR-0005kJ-Fj for pppext@megatron.ietf.org; Thu, 08 Dec 2005 04:06:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16320 for ; Thu, 8 Dec 2005 04:05:36 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkI5I-00087w-Sv for pppext@ietf.org; Thu, 08 Dec 2005 04:29:06 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 09901EB3473 for ; Thu, 8 Dec 2005 01:06:11 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24803-09 for ; Thu, 8 Dec 2005 01:06:10 -0800 (PST) Received: from PARBETM2XP (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 1CFE1EB346F for ; Thu, 8 Dec 2005 01:06:10 -0800 (PST) From: "Peter Arberg" To: Date: Thu, 8 Dec 2005 10:06:06 +0100 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX71p7R1VOWcIWMQq2Rb4MZziRqtQ== Message-Id: <20051208090610.1CFE1EB346F@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Pppext] draft-arberg-pppoe-mtu-gt1492-02 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi, I was wondering if there are more outstanding comments to the draft-arberg-pppoe-mtu-gt1492-02 ? Otherwise James, can I ask that this document goes through a "last call" ? thanks, Peter _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 06:41:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkK9J-0003P2-FV; Thu, 08 Dec 2005 06:41:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkK9I-0003Ox-4p for pppext@megatron.ietf.org; Thu, 08 Dec 2005 06:41:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03930 for ; Thu, 8 Dec 2005 06:40:24 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkKV5-0004kc-6g for pppext@ietf.org; Thu, 08 Dec 2005 07:03:55 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB8BfAD7005385 for ; Thu, 8 Dec 2005 04:41:10 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB8BfAH0014135 for ; Thu, 8 Dec 2005 06:41:10 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB8BfAY2025202; Thu, 8 Dec 2005 06:41:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB8BfAKP025199; Thu, 8 Dec 2005 06:41:10 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17304.7126.94190.79896@gargle.gargle.HOWL> Date: Thu, 8 Dec 2005 06:41:10 -0500 From: James Carlson To: parberg@redback.com In-Reply-To: Peter Arberg's message of 8 December 2005 10:06:06 References: <20051208090610.1CFE1EB346F@prattle.redback.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org Subject: [Pppext] last call for PPPoE MTU [was Re: draft-arberg-pppoe-mtu-gt1492-02] X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Peter Arberg writes: > I was wondering if there are more outstanding comments > to the draft-arberg-pppoe-mtu-gt1492-02 ? > > Otherwise James, can I ask that this document goes through > a "last call" ? Certainly. Consider this a last call for comments on this draft. Unless there's substantial disagreement by December 22nd, I'll ask that this document be advanced as Informational. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 10:27:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkNft-0005pn-Oq; Thu, 08 Dec 2005 10:27:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkNfs-0005pi-PR for pppext@megatron.ietf.org; Thu, 08 Dec 2005 10:27:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28103 for ; Thu, 8 Dec 2005 10:26:19 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkNfq-0004Nk-9G for pppext@ietf.org; Thu, 08 Dec 2005 10:27:13 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB8FR8D7013410 for ; Thu, 8 Dec 2005 08:27:08 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB8FR7H0028663 for ; Thu, 8 Dec 2005 10:27:07 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB8FR2mM007517 for ; Thu, 8 Dec 2005 10:27:05 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB8FR2CK007468; Thu, 8 Dec 2005 10:27:02 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17304.20672.728024.259626@gargle.gargle.HOWL> Date: Thu, 8 Dec 2005 10:26:56 -0500 From: James Carlson To: pppext@ietf.org X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Subject: [Pppext] warning suggestions for draft-bberry-pppoe-credit X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Our AD has asked for some suggested warning text that can be added to this draft, as the author has asked for it to be published as an Informational RFC. (Please -- no matter which side of this divide you're on -- direct your flames to /dev/null. Yes, I and the rest of the folks here know all of the arguments on both sides. We don't need to go over the issues again.) Here's my suggestion. Feel free to suggest better wording. "The PPP Extensions Working Group (pppext) has reservations about the desirability of the feature described in this document. In particular, it solves a general problem at an inappropriate layer and it may have unpredictable interactions with higher and lower level protocols. The consensus of the working group is that implementors would be better advised either to seek ways of making the underlying radio link suitable for general Ethernet-like use, or to abandon the incomplete emulation of Ethernet entirely." -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 10:57:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO8i-0005aO-PL; Thu, 08 Dec 2005 10:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkO8h-0005Zy-98 for pppext@megatron.ietf.org; Thu, 08 Dec 2005 10:56:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02384 for ; Thu, 8 Dec 2005 10:55:58 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkO8Y-0005gK-2p for pppext@ietf.org; Thu, 08 Dec 2005 10:56:52 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2005 10:56:40 -0500 X-IronPort-AV: i="3.99,231,1131339600"; d="scan'208"; a="77388599:sNHT31492288" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jB8Fu7Ut000639; Thu, 8 Dec 2005 10:56:38 -0500 (EST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 10:56:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Thu, 8 Dec 2005 10:56:17 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76401170791@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Pppext] warning suggestions for draft-bberry-pppoe-credit Thread-Index: AcX8DGE9xvK43q//Szy7SdVBwhyoTQAAsOLQ From: "Stan Ratliff \(sratliff\)" To: "James Carlson" , X-OriginalArrivalTime: 08 Dec 2005 15:56:18.0256 (UTC) FILETIME=[ED1A4D00:01C5FC0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James/All --=20 When viewed in the context of 802.11 radios, I would agree that the=20 applicability of this draft is suspect. However, when viewed in the=20 context of TDMA radios, that point-to-point characteristics, this=20 RFC does seem applicable.=20 It allows the radio vendors to do what they do best, and at the same time, allows router vendors to do the same. Propagation of the P2P=20 characteristics of TDMA links back into the router allows the router to allocate QoS queues on a radio link-by-radio link basis, giving=20 good granularity and control.=20 So, at the worst, I would like to see some text in the draft that=20 states the applicability to TDMA-like radios, as opposed to what=20 you have here.=20 Regards, Stan =20 >-----Original Message----- >From: pppext-bounces@ietf.org [mailto:pppext-bounces@ietf.org]=20 >On Behalf Of James Carlson >Sent: Thursday, December 08, 2005 10:27 AM >To: pppext@ietf.org >Subject: [Pppext] warning suggestions for draft-bberry-pppoe-credit > >Our AD has asked for some suggested warning text that can be added to >this draft, as the author has asked for it to be published as an >Informational RFC. (Please -- no matter which side of this divide >you're on -- direct your flames to /dev/null. Yes, I and the rest of >the folks here know all of the arguments on both sides. We don't need >to go over the issues again.) > >Here's my suggestion. Feel free to suggest better wording. > > "The PPP Extensions Working Group (pppext) has reservations about > the desirability of the feature described in this document. In > particular, it solves a general problem at an inappropriate layer > and it may have unpredictable interactions with higher and lower > level protocols. The consensus of the working group is that > implementors would be better advised either to seek ways of making > the underlying radio link suitable for general Ethernet-like use, or > to abandon the incomplete emulation of Ethernet entirely." > >--=20 >James Carlson, KISS Network =20 > >Sun Microsystems / 1 Network Drive 71.232W Vox +1=20 >781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1=20 >781 442 1677 > >_______________________________________________ >Pppext mailing list >Pppext@ietf.org >https://www1.ietf.org/mailman/listinfo/pppext > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 12:10:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPHn-0000d9-Fe; Thu, 08 Dec 2005 12:10:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPHl-0000Zs-P5 for pppext@megatron.ietf.org; Thu, 08 Dec 2005 12:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11960 for ; Thu, 8 Dec 2005 12:09:25 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkPHc-0000Fy-Iz for pppext@ietf.org; Thu, 08 Dec 2005 12:10:20 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jB8HAC4u019403 for ; Thu, 8 Dec 2005 09:10:12 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB8HABWc019936 for ; Thu, 8 Dec 2005 12:10:12 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB8HAAfb003234; Thu, 8 Dec 2005 12:10:10 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB8HA998003229; Thu, 8 Dec 2005 12:10:09 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17304.26862.243752.75473@gargle.gargle.HOWL> Date: Thu, 8 Dec 2005 12:10:06 -0500 From: James Carlson To: "Stan Ratliff (sratliff)" Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Stan Ratliff (sratliff)'s message of 8 December 2005 10:56:17 References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170791@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Stan Ratliff (sratliff) writes: > It allows the radio vendors to do what they do best, and at the same > time, allows router vendors to do the same. Propagation of the P2P > characteristics of TDMA links back into the router allows the router > to allocate QoS queues on a radio link-by-radio link basis, giving > good granularity and control. The point here is that Ethernet is Ethernet, and if this link requires the sort of explicit flow control described here, then it's most certainly _not_ Ethernet. The problem is not at this layer. Either the radio itself needs to be fixed to provide the service it's claiming to provide, or it needs to abandon the pretense. Providing a service that doesn't work as expected isn't helpful. Ethernet supports multiple protocols. What would you do if someone ran some protocol *other* than PPPoE over this pseudo-Ethernet? Wouldn't you be forced to fix the problem all over again? > So, at the worst, I would like to see some text in the draft that > states the applicability to TDMA-like radios, as opposed to what > you have here. Please suggest some text, and I'll see what I can do with it. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 12:40:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPkX-00059i-NE; Thu, 08 Dec 2005 12:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkPkW-00054Q-AP for pppext@megatron.ietf.org; Thu, 08 Dec 2005 12:40:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15421 for ; Thu, 8 Dec 2005 12:39:09 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkPkS-0001SO-2W for pppext@ietf.org; Thu, 08 Dec 2005 12:40:05 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Dec 2005 12:39:53 -0500 X-IronPort-AV: i="3.99,231,1131339600"; d="scan'208"; a="77396746:sNHT32995348" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB8HdS4r016263; Thu, 8 Dec 2005 12:39:50 -0500 (EST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 12:39:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Thu, 8 Dec 2005 12:39:49 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76401170826@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Pppext] warning suggestions for draft-bberry-pppoe-credit Thread-Index: AcX8GkpPGM3lPGDWQuC04v+vZJ9ZegAAr0iw From: "Stan Ratliff \(sratliff\)" To: "James Carlson" X-OriginalArrivalTime: 08 Dec 2005 17:39:50.0424 (UTC) FILETIME=[63D7E980:01C5FC1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org =20 >-----Original Message----- >From: James Carlson [mailto:james.d.carlson@sun.com]=20 >Sent: Thursday, December 08, 2005 12:10 PM >To: Stan Ratliff (sratliff) >Cc: pppext@ietf.org >Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit > >Stan Ratliff (sratliff) writes: >> It allows the radio vendors to do what they do best, and at the same >> time, allows router vendors to do the same. Propagation of the P2P=20 >> characteristics of TDMA links back into the router allows the router >> to allocate QoS queues on a radio link-by-radio link basis, giving=20 >> good granularity and control.=20 > >The point here is that Ethernet is Ethernet, and if this link requires >the sort of explicit flow control described here, then it's most >certainly _not_ Ethernet. The problem is not at this layer. > Agreed. The intent of the draft is to use Ethernet/PPPoE to=20 allow two devices, each having its own specialty, the ability to=20 communicate with each other over a ubiquitous medium (Ethernet),=20 and still preserve the characteristics of the RF transmission.=20 >Either the radio itself needs to be fixed to provide the service it's >claiming to provide, or it needs to abandon the pretense. Providing a >service that doesn't work as expected isn't helpful. > >Ethernet supports multiple protocols. What would you do if someone >ran some protocol *other* than PPPoE over this pseudo-Ethernet? >Wouldn't you be forced to fix the problem all over again? > I don't understand what you mean here. In our implementation, the=20 radio and router are connected via a real Ethernet, not a pseudo- Ethernet. There is no intersection I'm aware of with other devices=20 on the Ethernet communicating with each other via different protocols.=20 The intent isn't to create a pseudo-Ethernet with the extensions, rather,=20 the intent is to create a group of pseudo point-to-point links, representing the individual TDMA radio links, tunneling over the Ethernet connection=20 from radio to router.=20 >> So, at the worst, I would like to see some text in the draft that=20 >> states the applicability to TDMA-like radios, as opposed to what=20 >> you have here.=20 > >Please suggest some text, and I'll see what I can do with it. Ok, here's my shot at it:=20 "The techniques described in this document will not be applicable to all radio implementations. This document describes extensions=20 better applied to radios with point-to-point transmission=20 characteristics (e.g. TDMA). When used with multi-access, broadcast capable radios such as 802.11, these techniques may have unpredictable interactions with higher and lower layers." Regards, Stan > >--=20 >James Carlson, KISS Network =20 > >Sun Microsystems / 1 Network Drive 71.232W Vox +1=20 >781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1=20 >781 442 1677 > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 13:05:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQ9Q-0004E4-9M; Thu, 08 Dec 2005 13:05:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQ9O-00049S-BN for pppext@megatron.ietf.org; Thu, 08 Dec 2005 13:05:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18798 for ; Thu, 8 Dec 2005 13:04:42 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQ9B-0002Yp-18 for pppext@ietf.org; Thu, 08 Dec 2005 13:05:38 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB8I5WD7011496 for ; Thu, 8 Dec 2005 11:05:32 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB8I5VWc021041 for ; Thu, 8 Dec 2005 13:05:31 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB8I5VMO003534; Thu, 8 Dec 2005 13:05:31 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB8I5VMP003531; Thu, 8 Dec 2005 13:05:31 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17304.30187.563864.241152@gargle.gargle.HOWL> Date: Thu, 8 Dec 2005 13:05:31 -0500 From: James Carlson To: "Stan Ratliff (sratliff)" Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Stan Ratliff (sratliff)'s message of 8 December 2005 12:39:49 References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170826@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Stan Ratliff (sratliff) writes: > >Ethernet supports multiple protocols. What would you do if someone > >ran some protocol *other* than PPPoE over this pseudo-Ethernet? > >Wouldn't you be forced to fix the problem all over again? > > > > I don't understand what you mean here. In our implementation, the > radio and router are connected via a real Ethernet, not a pseudo- > Ethernet. There is no intersection I'm aware of with other devices > on the Ethernet communicating with each other via different protocols. > The intent isn't to create a pseudo-Ethernet with the extensions, > rather, > the intent is to create a group of pseudo point-to-point links, > representing > the individual TDMA radio links, tunneling over the Ethernet connection > from radio to router. It's Ethernet ... but with a kind of L2 backpressure mechanism that regular Ethernet itself doesn't quite have. My point is that if you had something *other than* PPP to transmit to those nodes over the radio, then you'd be sunk. You'd have to start over because PPPoE carries only PPP. Your assertion seems to rest on a particular deployment and combination of protocols: PPP (and nothing else) between radio and remote nodes, Ethernet (and nothing else) between radio and router, and no way to implement the patently obvious solution -- just terminating PPP in the radio and using regular L2 forwarding or IP routing outside of that context. No PPPoE required. Its narrowness makes it extremely suspicious. I agree that there may well be a problem here that needs to be solved. I'm deeply concerned that this doesn't actually address the problem in any lasting way and is instead a diversion for developers. > "The techniques described in this document will not be applicable > to all radio implementations. This document describes extensions > better applied to radios with point-to-point transmission > characteristics (e.g. TDMA). When used with multi-access, broadcast > capable radios such as 802.11, these techniques may have unpredictable > interactions with higher and lower layers." How about: The techniques described in this document are intended for use with a particular deployment technique that uses a PPP termination separated from a radio termination by an Ethernet, and that has radio-side flow control for a slower PPP-only link to remote nodes. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 13:08:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQCQ-0004wN-3K; Thu, 08 Dec 2005 13:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQCP-0004sZ-Hr for pppext@megatron.ietf.org; Thu, 08 Dec 2005 13:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19159 for ; Thu, 8 Dec 2005 13:07:53 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQCG-0002f2-5H for pppext@ietf.org; Thu, 08 Dec 2005 13:08:49 -0500 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id jB8I8TqQ019718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 8 Dec 2005 11:08:29 -0700 (MST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id jB8I8TI1019717 for pppext@ietf.org; Thu, 8 Dec 2005 11:08:29 -0700 (MST) Date: Thu, 8 Dec 2005 11:08:29 -0700 (MST) From: Vernon Schryver Message-Id: <200512081808.jB8I8TI1019717@calcite.rhyolite.com> To: pppext@ietf.org Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76401170826@xmb-rtp-208.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > "The techniques described in this document will not be applicable > to all radio implementations. This document describes extensions > better applied to radios with point-to-point transmission > characteristics (e.g. TDMA). When used with multi-access, broadcast > capable radios such as 802.11, these techniques may have unpredictable > interactions with higher and lower layers." That text has nothing to do with the intent of the other text. It tries to apply the impremature of the IETF to the proposal. It is also simply wrong on technial grounds. (e.g. "radios with point-to-point transmission characteristics" is bogus.) For comparison, here is the other text: The PPP Extensions Working Group (pppext) has reservations about the desirability of the feature described in this document. In particular, it solves a general problem at an inappropriate layer and it may have unpredictable interactions with higher and lower level protocols. The consensus of the working group is that implementors would be better advised either to seek ways of making the underlying radio link suitable for general Ethernet-like use, or to abandon the incomplete emulation of Ethernet entirely. Unless alternate text that says that the WG *does not* like the proposal and perhaps a little of why, the original text must be used. As James Carlson also wrote: ] (Please -- no matter which side of this divide ] you're on -- direct your flames to /dev/null. Yes, I and the rest of ] the folks here know all of the arguments on both sides. We don't need ] to go over the issues again.) Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Dec 08 13:20:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQNX-0000BI-QS; Thu, 08 Dec 2005 13:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkQNV-00008R-Oc for pppext@megatron.ietf.org; Thu, 08 Dec 2005 13:20:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20490 for ; Thu, 8 Dec 2005 13:19:26 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkQNR-00035D-Ni for pppext@ietf.org; Thu, 08 Dec 2005 13:20:23 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2005 10:20:10 -0800 X-IronPort-AV: i="3.99,231,1131350400"; d="scan'208"; a="238849843:sNHT33830804" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB8IK2Mi008049; Thu, 8 Dec 2005 10:20:07 -0800 (PST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 8 Dec 2005 13:20:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Thu, 8 Dec 2005 13:20:05 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Pppext] warning suggestions for draft-bberry-pppoe-credit Thread-Index: AcX8IgZdDMGryXXiTaqlkVGxKuI0RwAAeYbg From: "Stan Ratliff \(sratliff\)" To: "James Carlson" X-OriginalArrivalTime: 08 Dec 2005 18:20:06.0565 (UTC) FILETIME=[03F9C550:01C5FC24] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James,=20 > > The techniques described in this document are intended for use with > a particular deployment technique that uses a PPP termination > separated from a radio termination by an Ethernet, and that has > radio-side flow control for a slower PPP-only link to remote nodes. > I, for one, would be OK with this text.=20 Regards, Stan >-----Original Message----- >From: James Carlson [mailto:james.d.carlson@sun.com]=20 >Sent: Thursday, December 08, 2005 1:06 PM >To: Stan Ratliff (sratliff) >Cc: pppext@ietf.org >Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit > >Stan Ratliff (sratliff) writes: >> >Ethernet supports multiple protocols. What would you do if someone >> >ran some protocol *other* than PPPoE over this pseudo-Ethernet? >> >Wouldn't you be forced to fix the problem all over again? >> > >>=20 >> I don't understand what you mean here. In our implementation, the=20 >> radio and router are connected via a real Ethernet, not a pseudo- >> Ethernet. There is no intersection I'm aware of with other devices=20 >> on the Ethernet communicating with each other via different=20 >protocols.=20 >> The intent isn't to create a pseudo-Ethernet with the extensions, >> rather,=20 >> the intent is to create a group of pseudo point-to-point links, >> representing >> the individual TDMA radio links, tunneling over the Ethernet=20 >connection=20 >> from radio to router.=20 > >It's Ethernet ... but with a kind of L2 backpressure mechanism that >regular Ethernet itself doesn't quite have. > >My point is that if you had something *other than* PPP to transmit to >those nodes over the radio, then you'd be sunk. You'd have to start >over because PPPoE carries only PPP. > >Your assertion seems to rest on a particular deployment and >combination of protocols: PPP (and nothing else) between radio and >remote nodes, Ethernet (and nothing else) between radio and router, >and no way to implement the patently obvious solution -- just >terminating PPP in the radio and using regular L2 forwarding or IP >routing outside of that context. No PPPoE required. > >Its narrowness makes it extremely suspicious. I agree that there may >well be a problem here that needs to be solved. I'm deeply concerned >that this doesn't actually address the problem in any lasting way and >is instead a diversion for developers. > >> "The techniques described in this document will not be applicable >> to all radio implementations. This document describes extensions=20 >> better applied to radios with point-to-point transmission=20 >> characteristics (e.g. TDMA). When used with multi-access, broadcast >> capable radios such as 802.11, these techniques may have=20 >unpredictable >> interactions with higher and lower layers." > >How about: > > The techniques described in this document are intended for use with > a particular deployment technique that uses a PPP termination > separated from a radio termination by an Ethernet, and that has > radio-side flow control for a slower PPP-only link to remote nodes. > >--=20 >James Carlson, KISS Network =20 > >Sun Microsystems / 1 Network Drive 71.232W Vox +1=20 >781 442 2084 >MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1=20 >781 442 1677 > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 05:55:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekfur-0003Il-J1; Fri, 09 Dec 2005 05:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekfuq-0003II-6m for pppext@megatron.ietf.org; Fri, 09 Dec 2005 05:55:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16978 for ; Fri, 9 Dec 2005 05:54:48 -0500 (EST) Received: from mail.watervalley.net ([64.49.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekfup-0006jY-2C for pppext@ietf.org; Fri, 09 Dec 2005 05:55:53 -0500 Received: from [207.74.179.20] (pm916-10.dialip.mich.net [207.74.179.20]) by mail.watervalley.net (Postfix) with ESMTP id 380EF11DE16; Fri, 9 Dec 2005 04:54:58 -0600 (CST) Message-ID: <43996295.2020003@greendragon.com> Date: Fri, 09 Dec 2005 05:55:17 -0500 From: William Allen Simpson User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: pppext@ietf.org Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Stan Ratliff (sratliff) wrote: >> The techniques described in this document are intended for use with >> a particular deployment technique that uses a PPP termination >> separated from a radio termination by an Ethernet, and that has >> radio-side flow control for a slower PPP-only link to remote nodes. > > I, for one, would be OK with this text. > While I, for one, would not! Merely describing the protocol deployment environment is a part of the specification, not a WG warning about the poor design. Going back 20+ years, I have had considerable experience deploying protocols over radio links. The best design would be to put a router at every radio link. Goodness gracious, TAL did it commercially going on 15 years ago! Simple 2 port routers are cheap! Also, we have seen a long history here of problems with inter-layer interactions -- multimedia bridges, L2TP, PPPoE, etc, etc. Something close to the original warning is required: The PPP Extensions Working Group (pppext) has reservations about the desirability of the feature described in this document. In particular, it solves a general problem at an inappropriate layer and it may have unpredictable interactions with higher and lower level protocols. The consensus of the working group is that implementors would be better advised either to seek ways of making the underlying radio link suitable for general Ethernet-like use, or to abandon the incomplete emulation of Ethernet entirely. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 08:18:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eki8p-00005d-Hw; Fri, 09 Dec 2005 08:18:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eki8j-0008VV-4W for pppext@megatron.ietf.org; Fri, 09 Dec 2005 08:18:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02109 for ; Fri, 9 Dec 2005 08:17:08 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eki8a-00030H-6m for pppext@ietf.org; Fri, 09 Dec 2005 08:18:15 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jB9DHwdK025192 for ; Fri, 9 Dec 2005 05:17:58 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB9DHvWc006466 for ; Fri, 9 Dec 2005 08:17:57 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB9DHvEJ005937; Fri, 9 Dec 2005 08:17:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB9DHvJF005934; Fri, 9 Dec 2005 08:17:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.33797.545874.434026@gargle.gargle.HOWL> Date: Fri, 9 Dec 2005 08:17:57 -0500 From: James Carlson To: William Allen Simpson Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: William Allen Simpson's message of 9 December 2005 05:55:17 References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org William Allen Simpson writes: > While I, for one, would not! Merely describing the protocol deployment > environment is a part of the specification, not a WG warning about the > poor design. I had intended to integrate that text into the previous warning, not replace, and was just word-smithing the subset to get the commentary on the original usage case right. Something like this: "The PPP Extensions Working Group (pppext) has reservations about the desirability of the feature described in this document. In particular, it solves a general problem at an inappropriate layer and it may have unpredictable interactions with higher and lower level protocols. The techniques described in this document are intended for use with a particular deployment technique that uses a PPP termination separated from a radio termination by an Ethernet, and that has radio-side flow control for a slower PPP-only link to remote nodes. Implementors are better advised to avoid split termination and use traditional IP routing instead." -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 08:25:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiFh-0002Hd-HH; Fri, 09 Dec 2005 08:25:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiFg-0002C2-QD for pppext@megatron.ietf.org; Fri, 09 Dec 2005 08:25:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02957 for ; Fri, 9 Dec 2005 08:23:55 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkiF9-0003GE-Vp for pppext@ietf.org; Fri, 09 Dec 2005 08:25:00 -0500 Received: from [209.31.94.10] (account karl HELO [172.30.1.159]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1139219; Fri, 09 Dec 2005 08:24:44 -0500 In-Reply-To: <43996295.2020003@greendragon.com> References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <104B0E92-C0C3-4D99-A7D6-DBECC54FF53A@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Fri, 9 Dec 2005 08:24:34 -0500 To: William Allen Simpson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Welcome back, Bill! It's nice to have one of the voices of reason and wisdom back in our group. This group, and the IETF in general, tend to be divided into two camps: those who remember the IETF's original purpose and strongly advocate clean designs and proven interoperability, and those who strongly advocate a conclusion decided in advance by a vendor or a group of vendors. We are supposed to be protocol designers to the world, not a rubber stamp for companies who want an official-looking Band-Aid (tm) to fix their badly designed product. That's why PPPoE is not standards track, and that's why the latest "patch" (to undo a foolish choice made by the original gang of companies) is also not standards track. Let me cite an example from the dim, dark past: In 1997, Bill sent a message to this list describing a certain company that had sold inexpensive routers with a bug in the FCS calculation on PPP links. They originally wanted everyone to recognize them as a special case (sound familiar?), seeing as how they had already fielded a large number of units. But Bill and the group held firm, and they fixed their broken units. Broken. Yes, I said broken. PPPoE is broken. A PPP-over-Ethernet- over-radio design that needs new options to work properly is, by definition, also broken. Broken because the designers designed their product improperly. And now they want us to accept their broken design as OK by standardizing it. Design your products properly and you won't need all these broken options. Listen to experienced (and smart!) people like Bill Simpson, Vern Schryver and Jim Carlson and your products will work better without all the cruft. Karl P.S. My copy of "How to Win Friends and Influence People" lies on a shelf at home, gathering dust, never cracked. Sorry about that! On Dec 9, 2005, at 5:55 AM, William Allen Simpson wrote: > Stan Ratliff (sratliff) wrote: >>> The techniques described in this document are intended for use with >>> a particular deployment technique that uses a PPP termination >>> separated from a radio termination by an Ethernet, and that has >>> radio-side flow control for a slower PPP-only link to remote nodes. >> I, for one, would be OK with this text. > While I, for one, would not! Merely describing the protocol deployment > environment is a part of the specification, not a WG warning about the > poor design. > > Going back 20+ years, I have had considerable experience deploying > protocols over radio links. The best design would be to put a router > at every radio link. Goodness gracious, TAL did it commercially going > on 15 years ago! Simple 2 port routers are cheap! > > Also, we have seen a long history here of problems with inter-layer > interactions -- multimedia bridges, L2TP, PPPoE, etc, etc. > > Something close to the original warning is required: > > The PPP Extensions Working Group (pppext) has reservations about > the desirability of the feature described in this document. In > particular, it solves a general problem at an inappropriate layer > and it may have unpredictable interactions with higher and lower > level protocols. The consensus of the working group is that > implementors would be better advised either to seek ways of making > the underlying radio link suitable for general Ethernet-like use, or > to abandon the incomplete emulation of Ethernet entirely. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 08:33:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiN7-0004iz-Vn; Fri, 09 Dec 2005 08:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiN7-0004dj-8z for pppext@megatron.ietf.org; Fri, 09 Dec 2005 08:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03792 for ; Fri, 9 Dec 2005 08:31:40 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkiMf-0003WA-6W for pppext@ietf.org; Fri, 09 Dec 2005 08:32:45 -0500 Received: from [209.31.94.10] (account karl HELO [172.30.1.159]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1139224; Fri, 09 Dec 2005 08:32:32 -0500 In-Reply-To: <17305.33797.545874.434026@gargle.gargle.HOWL> References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> <17305.33797.545874.434026@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <918F3977-B268-4F13-BFB0-FD2FEEF2A876@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Fri, 9 Dec 2005 08:32:30 -0500 To: James Carlson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, William Allen Simpson X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Can't we work the work "broken" in there somehow? :-) Karl On Dec 9, 2005, at 8:17 AM, James Carlson wrote: > William Allen Simpson writes: >> While I, for one, would not! Merely describing the protocol >> deployment >> environment is a part of the specification, not a WG warning about >> the >> poor design. > > I had intended to integrate that text into the previous warning, not > replace, and was just word-smithing the subset to get the commentary > on the original usage case right. Something like this: > > "The PPP Extensions Working Group (pppext) has reservations about > the desirability of the feature described in this document. In > particular, it solves a general problem at an inappropriate layer > and it may have unpredictable interactions with higher and lower > level protocols. The techniques described in this document are > intended for use with a particular deployment technique that uses a > PPP termination separated from a radio termination by an Ethernet, > and that has radio-side flow control for a slower PPP-only link to > remote nodes. Implementors are better advised to avoid split > termination and use traditional IP routing instead." > > -- > James Carlson, KISS Network > > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 09:19:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekj5Y-0000y5-Df; Fri, 09 Dec 2005 09:19:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekj5W-0000xi-F4 for pppext@megatron.ietf.org; Fri, 09 Dec 2005 09:19:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09791 for ; Fri, 9 Dec 2005 09:18:12 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekj5g-00058k-Qh for pppext@ietf.org; Fri, 09 Dec 2005 09:19:18 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB9EJ23F013028 for ; Fri, 9 Dec 2005 07:19:02 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB9EJ1We024622 for ; Fri, 9 Dec 2005 09:19:02 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB9EJ1J6006134; Fri, 9 Dec 2005 09:19:01 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB9EJ1sf006131; Fri, 9 Dec 2005 09:19:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.37461.664962.331436@gargle.gargle.HOWL> Date: Fri, 9 Dec 2005 09:19:01 -0500 From: James Carlson To: Karl Fox Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Karl Fox's message of 9 December 2005 08:24:34 References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> <104B0E92-C0C3-4D99-A7D6-DBECC54FF53A@columbus.rr.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, William Allen Simpson X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Karl Fox writes: > Broken. Yes, I said broken. PPPoE is broken. A PPP-over-Ethernet- > over-radio design that needs new options to work properly is, by > definition, also broken. Broken because the designers designed their > product improperly. And now they want us to accept their broken > design as OK by standardizing it. Agreed; the whole thing is swilly. However, I disagree with that last bit. The only intent here is to publish as Informational (not Standards Track), and to make sure it's specified to be minimally harmful. In an ideal world, we would have been able to argue the authors away from this split-termination design. There wouldn't have been any issue here at all, and no draft to write. However, we haven't quite managed to do that, and they've asked the IESG to publish. In an ideal world, the IETF wouldn't have a vanity press feature such as Informational. Instead, we'd just tell people working on things that are tangential (or inimical) to our agreed-on technical direction to go find or form another standards body. However, the IETF does have this feature, and we've got some built-in limits to what we can stop. I agree it's not pretty, but I think we're getting the best of world that we can have. The authors were directed here to get input from folks who know these protocols, even though they were under little obligation to do so. They got the input and may be mostly disregarding it, but at least the resulting document will have an appropriate warning. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 10:50:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkWA-0007Os-Gi; Fri, 09 Dec 2005 10:50:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkkW9-0007FU-H5 for pppext@megatron.ietf.org; Fri, 09 Dec 2005 10:50:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21845 for ; Fri, 9 Dec 2005 10:49:40 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkkWE-0000El-6h for pppext@ietf.org; Fri, 09 Dec 2005 10:50:47 -0500 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id jB9FoIJV002231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Fri, 9 Dec 2005 08:50:18 -0700 (MST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id jB9FoIQc002230 for pppext@ietf.org; Fri, 9 Dec 2005 08:50:18 -0700 (MST) Date: Fri, 9 Dec 2005 08:50:18 -0700 (MST) From: Vernon Schryver Message-Id: <200512091550.jB9FoIQc002230@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: <17305.37461.664962.331436@gargle.gargle.HOWL> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: James Carlson > > Broken. Yes, I said broken. PPPoE is broken. A PPP-over-Ethernet- > > over-radio design that needs new options to work properly is, by > > definition, also broken. Broken because the designers designed their > > product improperly. And now they want us to accept their broken > > design as OK by standardizing it. > > Agreed; the whole thing is swilly. > > However, I disagree with that last bit. The only intent here is to > publish as Informational (not Standards Track), and to make sure it's > specified to be minimally harmful. Let's be honest with ourselves. If the difference between "Informational" and "Standards Track" were real, there would be no need to add the deprecating text to this proposal. The intent is for the IETF to OK or standardize the proposal exactly as much as PPPoE was OK'ed or standardized by the IETF. Some original advocates of PPPoE as well as some advocates of this notion have doubtless convinced themselves that there is a difference between the status as a standard of RFC 2516 or this proposal and RFC 793, but that difference is imperceptable to all implementors, buyers, installers, maintainers, and users. Let's also admit that, as the stronger title and words in RFC 1055 proved, the suggested deprecating words for this proposal will have very little and probably no effect on implementors, buyers, etc. These deprecating words can only salvage a little of the self-respect of all of use including advocates for the idea and warn off advocates of worse ideas such as the recent proposal concerning quantum mechanics. The words might at most affect the IETF itself, much as the deprecating words in RFC 1055 built momentum for PPP. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:13:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkksF-0006ep-G8; Fri, 09 Dec 2005 11:13:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkksD-0006e4-JS for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:13:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24859 for ; Fri, 9 Dec 2005 11:12:35 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkksP-0000zq-Sj for pppext@ietf.org; Fri, 09 Dec 2005 11:13:43 -0500 Received: from [209.31.94.10] (account karl HELO [172.30.1.159]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1139274; Fri, 09 Dec 2005 11:13:26 -0500 In-Reply-To: <200512091550.jB9FoIQc002230@calcite.rhyolite.com> References: <200512091550.jB9FoIQc002230@calcite.rhyolite.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Fri, 9 Dec 2005 11:13:25 -0500 To: Vernon Schryver X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Frankly, I agree with Vern. Why can't the WG simply tell the IESG that it's a bad idea because the need is based on a defective product design? Surely they'd understand that--they're protocol designers, too. Who knows, maybe they'd say no, too. Karl On Dec 9, 2005, at 10:50 AM, Vernon Schryver wrote: >> From: James Carlson > >>> Broken. Yes, I said broken. PPPoE is broken. A PPP-over-Ethernet- >>> over-radio design that needs new options to work properly is, by >>> definition, also broken. Broken because the designers designed >>> their >>> product improperly. And now they want us to accept their broken >>> design as OK by standardizing it. >> >> Agreed; the whole thing is swilly. >> >> However, I disagree with that last bit. The only intent here is to >> publish as Informational (not Standards Track), and to make sure it's >> specified to be minimally harmful. > > Let's be honest with ourselves. If the difference between > "Informational" > and "Standards Track" were real, there would be no need to add the > deprecating text to this proposal. The intent is for the IETF to OK > or standardize the proposal exactly as much as PPPoE was OK'ed or > standardized by the IETF. Some original advocates of PPPoE as well as > some advocates of this notion have doubtless convinced themselves that > there is a difference between the status as a standard of RFC 2516 or > this proposal and RFC 793, but that difference is imperceptable to all > implementors, buyers, installers, maintainers, and users. > > Let's also admit that, as the stronger title and words in RFC 1055 > proved, the suggested deprecating words for this proposal will have > very > little and probably no effect on implementors, buyers, etc. > These deprecating words can only salvage a little of the self-respect > of all of use including advocates for the idea and warn off advocates > of worse ideas such as the recent proposal concerning quantum > mechanics. > The words might at most affect the IETF itself, much as the > deprecating > words in RFC 1055 built momentum for PPP. > > > Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:15:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekkuc-00071y-CO; Fri, 09 Dec 2005 11:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekkub-0006z7-GF for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:15:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25047 for ; Fri, 9 Dec 2005 11:14:47 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkkuW-00013V-7I for pppext@ietf.org; Fri, 09 Dec 2005 11:15:53 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB9GFaD7026425 for ; Fri, 9 Dec 2005 09:15:37 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB9GFZWc008723 for ; Fri, 9 Dec 2005 11:15:36 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB9GFZ1O006592; Fri, 9 Dec 2005 11:15:35 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB9GFZbd006589; Fri, 9 Dec 2005 11:15:35 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.44455.749579.858657@gargle.gargle.HOWL> Date: Fri, 9 Dec 2005 11:15:35 -0500 From: James Carlson To: Vernon Schryver Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Vernon Schryver's message of 9 December 2005 08:50:18 References: <17305.37461.664962.331436@gargle.gargle.HOWL> <200512091550.jB9FoIQc002230@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 2.8 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Vernon Schryver writes: > Let's be honest with ourselves. If the difference between "Informational" > and "Standards Track" were real, there would be no need to add the > deprecating text to this proposal. The intent is for the IETF to OK Yes, I'm an implementor, and I have certainly noticed that many (though not exactly _all_; I think that's a bit of hyperbole) customers, users, and other implementors ignore the overly subtle distinction between Standards Track and the rest. I even agree that ditching Informational as a failed experiment would likely work out for the best. That doesn't imply that this is really the right forum to redesign the IETF/IESG process. As long as that process exists, we might as well respect it as best we can. I agree that many people will breeze right past the Informational warning as well as any text (no matter how clear) indicating that the document shouldn't be viewed by anyone ... ever.[1] Just the same, as long as publishing is going to happen no matter what we say here, I think we're in a better place with the text than without. Again, as an implementor, I like being able to say to a customer, "gee, did you notice the warning message? That's why I'm just not going to put a high priority on fixing your bug. Pony up some serious cash or just go away." ;-} [1] Apologies to Trey Parker for stealing^Wborrowing that phrase. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:28:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekl6N-0002dJ-OU; Fri, 09 Dec 2005 11:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekl6K-0002cR-3P for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:28:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26770 for ; Fri, 9 Dec 2005 11:27:02 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekl6N-0001W2-Bv for pppext@ietf.org; Fri, 09 Dec 2005 11:28:09 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 09 Dec 2005 08:27:44 -0800 X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="376171060:sNHT639288450" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9GRNA2005987; Fri, 9 Dec 2005 08:27:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 08:27:36 -0800 Received: from [10.81.246.133] ([10.81.246.133]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 9 Dec 2005 08:27:36 -0800 Message-ID: <4399B05B.6040503@cisco.com> Date: Fri, 09 Dec 2005 11:27:07 -0500 From: Bo Berry User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> <104B0E92-C0C3-4D99-A7D6-DBECC54FF53A@columbus.rr.com> <17305.37461.664962.331436@gargle.gargle.HOWL> In-Reply-To: <17305.37461.664962.331436@gargle.gargle.HOWL> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2005 16:27:36.0284 (UTC) FILETIME=[76E861C0:01C5FCDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, William Allen Simpson , Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Well, we do agree on one point, this is silly. Guess it would not be unexpected to say that we disagree with the text and addition of the disclaimer. It appears from these emails (and from emails of past as well), that there is a lot of disagreement on PPPoE. We're not trying to to correct PPPoE. We're not here to debate the process and value of IETF Informational specs. We have proposed and documented extenstions to the PPPoE spec, which are within the context of that spec. These are documented as optional. The draft went through the IETF process and has gone through the expert review period. At this point we can agree to disagree. Therefore we request that the draft be published as is, without any inserted (bias) text, and without any further delay. Sincerely -Bo Berry James Carlson wrote: > Karl Fox writes: > >>Broken. Yes, I said broken. PPPoE is broken. A PPP-over-Ethernet- >>over-radio design that needs new options to work properly is, by >>definition, also broken. Broken because the designers designed their >>product improperly. And now they want us to accept their broken >>design as OK by standardizing it. > > > Agreed; the whole thing is swilly. > > However, I disagree with that last bit. The only intent here is to > publish as Informational (not Standards Track), and to make sure it's > specified to be minimally harmful. > > In an ideal world, we would have been able to argue the authors away > from this split-termination design. There wouldn't have been any > issue here at all, and no draft to write. However, we haven't quite > managed to do that, and they've asked the IESG to publish. > > In an ideal world, the IETF wouldn't have a vanity press feature such > as Informational. Instead, we'd just tell people working on things > that are tangential (or inimical) to our agreed-on technical direction > to go find or form another standards body. However, the IETF does > have this feature, and we've got some built-in limits to what we can > stop. > > I agree it's not pretty, but I think we're getting the best of world > that we can have. The authors were directed here to get input from > folks who know these protocols, even though they were under little > obligation to do so. They got the input and may be mostly > disregarding it, but at least the resulting document will have an > appropriate warning. > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:28:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekl6r-0002t7-9c; Fri, 09 Dec 2005 11:28:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekl6p-0002gG-O4 for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:28:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26813 for ; Fri, 9 Dec 2005 11:27:37 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ekl6x-0001Xr-Ac for pppext@ietf.org; Fri, 09 Dec 2005 11:28:44 -0500 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id jB9GSJME039708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Fri, 9 Dec 2005 09:28:19 -0700 (MST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id jB9GSJWm039707 for pppext@ietf.org; Fri, 9 Dec 2005 09:28:19 -0700 (MST) Date: Fri, 9 Dec 2005 09:28:19 -0700 (MST) From: Vernon Schryver Message-Id: <200512091628.jB9GSJWm039707@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: Karl Fox > Frankly, I agree with Vern. Why can't the WG simply tell the IESG > that it's a bad idea because the need is based on a defective product > design? Surely they'd understand that--they're protocol designers, > too. Who knows, maybe they'd say no, too. I see reasons not to tell the IESG "No": - The IESG might refuse to go along, which would encourage more results like PPPoE itself. (I have no recollections of debate about PPPoE here. Am I wrong in thinking it bypassed this WG?) - If the IESG went along, the idea would be published in some "PPPoE Forum" as the best thing since sliced bread and without any caveats, and perhaps even without the improvements that have been made to it here. - We should save our very limited power to say "No" and mean it for worse things. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:42:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklK7-0007vH-Hr; Fri, 09 Dec 2005 11:42:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklK6-0007rS-OE for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:42:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28978 for ; Fri, 9 Dec 2005 11:41:08 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklK3-000257-H9 for pppext@ietf.org; Fri, 09 Dec 2005 11:42:16 -0500 Received: from [209.31.94.10] (account karl HELO [172.30.1.159]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1139287; Fri, 09 Dec 2005 11:41:57 -0500 In-Reply-To: <200512091628.jB9GSJWm039707@calcite.rhyolite.com> References: <200512091628.jB9GSJWm039707@calcite.rhyolite.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BEF683C-7341-4581-821D-C1FAD653311B@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Fri, 9 Dec 2005 11:41:56 -0500 To: Vernon Schryver X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Yes, it did do an end run around PPPEXT, but since then I've seen more hints that the IESG might be willing to listen to the WG as expert on the topic and act accordingly. I say we ask them to nix the whole thing, and come back to us for text mods if they disagree. Why can't the company just fix their design? Karl On Dec 9, 2005, at 11:28 AM, Vernon Schryver wrote: >> From: Karl Fox > >> Frankly, I agree with Vern. Why can't the WG simply tell the IESG >> that it's a bad idea because the need is based on a defective product >> design? Surely they'd understand that--they're protocol designers, >> too. Who knows, maybe they'd say no, too. > > I see reasons not to tell the IESG "No": > > - The IESG might refuse to go along, which would encourage more > results > like PPPoE itself. (I have no recollections of debate about PPPoE > here. Am I wrong in thinking it bypassed this WG?) > > - If the IESG went along, the idea would be published in some > "PPPoE Forum" as the best thing since sliced bread and without any > caveats, and perhaps even without the improvements that have been > made to it here. > > - We should save our very limited power to say "No" and mean it > for worse things. > > > Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:55:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklX5-0004AT-N7; Fri, 09 Dec 2005 11:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklX4-00049v-Be for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:55:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00428 for ; Fri, 9 Dec 2005 11:54:48 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklXG-0002Ts-9v for pppext@ietf.org; Fri, 09 Dec 2005 11:55:56 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jB9GtcD7002054 for ; Fri, 9 Dec 2005 09:55:38 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB9GtcWc021491 for ; Fri, 9 Dec 2005 11:55:38 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB9Gtc6P006893; Fri, 9 Dec 2005 11:55:38 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB9GtcTq006890; Fri, 9 Dec 2005 11:55:38 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.46858.13024.398857@gargle.gargle.HOWL> Date: Fri, 9 Dec 2005 11:55:38 -0500 From: James Carlson To: Vernon Schryver Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Vernon Schryver's message of 9 December 2005 09:28:19 References: <200512091628.jB9GSJWm039707@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Vernon Schryver writes: > - The IESG might refuse to go along, which would encourage more results > like PPPoE itself. (I have no recollections of debate about PPPoE > here. Am I wrong in thinking it bypassed this WG?) There've been on-and-off discussions for many years. Back in 1992, there was a discussion about doing just this. The first mention of PPP over Ethernet "as we know it" that I can find on this list was from Luca Fantolino back in July 1997. Uri Shabi (and many others) told him that L2F, PPTP, and L2TP were good ways to do this. It popped up again as a draft notice in August 1998, but there was no discussion about it at all until December 1998, and even then no substantive discussion of why it was all a mistake. I don't think it bypassed the WG. It was even on the agenda for the 44th IETF. I do think there just wasn't much in the way of discussion, and was just published as Informational. > - If the IESG went along, the idea would be published in some > "PPPoE Forum" as the best thing since sliced bread and without any > caveats, and perhaps even without the improvements that have been > made to it here. > > - We should save our very limited power to say "No" and mean it > for worse things. Indeed. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:57:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklYy-0005WC-8z; Fri, 09 Dec 2005 11:57:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklYx-0005VZ-02 for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:57:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00550 for ; Fri, 9 Dec 2005 11:56:37 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklZ2-0002Wy-Qf for pppext@ietf.org; Fri, 09 Dec 2005 11:57:45 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2005 08:57:21 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,235,1131350400"; d="scan'208"; a="16931721:sNHT22707784" Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jB9GvJ4X028855; Fri, 9 Dec 2005 11:57:20 -0500 (EST) Received: from cisco.com (lanzo-u10.cisco.com [64.102.48.21]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA28631; Fri, 9 Dec 2005 11:57:15 -0500 (EST) Message-Id: <200512091657.LAA28631@cisco.com> Date: Fri, 9 Dec 2005 11:57:12 -0500 (EST) From: Mark Lanzo Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit To: wsimpson@greendragon.com In-Reply-To: <43996295.2020003@greendragon.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org On 9 Dec, William Allen Simpson wrote: > Stan Ratliff (sratliff) wrote: >>> The techniques described in this document are intended for use with >>> a particular deployment technique that uses a PPP termination >>> separated from a radio termination by an Ethernet, and that has >>> radio-side flow control for a slower PPP-only link to remote nodes. >> >> I, for one, would be OK with this text. >> > While I, for one, would not! Merely describing the protocol deployment > environment is a part of the specification, not a WG warning about the > poor design. > > Going back 20+ years, I have had considerable experience deploying > protocols over radio links. The best design would be to put a router > at every radio link. Goodness gracious, TAL did it commercially going > on 15 years ago! Simple 2 port routers are cheap! Hmm ... but this does not address the problem; it is not the issue. The issue is that the routers have to _connect_ to the radios somehow. The radios aren't integral to the router; the radios and router aren't even made by the same company. Ignoring the proposed extensions here, the router is a perfectly ordinary router; it doesn't know anything about radios or radio links in particular. The desired goal is that the router be able to establish ordinary PPP sessions to remote peers, and be none the wiser about the media between itself and its peers. In this particular instance, the router has a plain old ethernet port on it. So do the radios in question. The radios aren't integral to the router, but the desire is make the radios look somewhat as if they were. So the ethernet is being used as the "backplace" for connecting radios to router. -Some- sort of protocol is needed, to allow both for exchange of ordinary data and out-of-band information such as congestion conditions on the radio. Some way to emulate a system where radios were plugged into the router's bus and could appear more like local serial ports. A whole new protocol could have been devised for the purpose; however, it was recognized that with relatively minor modifications, PPPoE (which the router in question already supports) could be adapted to be this "backplane" protocol. The interesting thing here is that there is not really any "PPP" in this at all - it is actually irrelevant that the payloads which will eventually be traded between radio and router for over-the-air transmission be PPP packets. It is the out-of-band signalling capabilities, not the in-band data, which is the aspect of interest here. The name "PPPoE" seems an unfortunate choice, both because PPP wasn't the real point and because PPPoE is already a sore subject with many folk. Meanwhile, I believe it was thought that not reinventing the wheel, and trying to have a published standard which radio manufacturers and router vendors could agree to use for interconnecting their equipment, would be a Good Thing. Is there some other protocol out there already, which is a better choice [especially one whose very mention won't automatically trigger a knee-jerk negative reflexive action]? Note please that I am writing merely as an interested party and am not part of the group submitting the proposal, nor am I trying to endorse the proposal in any particular way. I have talked to that group though, and I have read the dialogs on this list, and I think that there is a bit of a disconnect, and that the group in question is suffering from the unfortunate backlash that results from association with a protocol that historically is not well-received. Would it help if the proposal began with a clearer explanation that although it "extends" PPPoE, that the usage is not in fact for PPPoE as traditionally recognized, but instead is being used as a protocol for using an ethernet as a backplace for communicating with external serial-port "concentrators"? Is there a different RFC this group should be looking at, which already provides just this sort of thing? _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 11:57:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklZ4-0005XF-K8; Fri, 09 Dec 2005 11:57:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklZ3-0005Vu-PC for pppext@megatron.ietf.org; Fri, 09 Dec 2005 11:57:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00559 for ; Fri, 9 Dec 2005 11:56:41 -0500 (EST) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklZ0-0002XF-Iu for pppext@ietf.org; Fri, 09 Dec 2005 11:57:49 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id jB9GvPTV020285 for ; Fri, 9 Dec 2005 11:57:25 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 09 Dec 2005 11:57:32 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 09 Dec 2005 11:57:32 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 9 Dec 2005 11:57:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] warning suggestions for draft-bberry-pppoe-credit Date: Fri, 9 Dec 2005 11:56:51 -0500 Message-ID: <3CFB564E055A594B82C4FE89D215656006B716@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Pppext] warning suggestions for draft-bberry-pppoe-credit Thread-Index: AcX83olAnLVoMgKERlOsSksi9c6lZQAAeOhQ From: "Nelson, David" To: X-OriginalArrivalTime: 09 Dec 2005 16:57:32.0556 (UTC) FILETIME=[A591BCC0:01C5FCE1] X-pstn-version: pmps:sps_win32_1_1_1c0 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:42.9337 ) X-pstn-settings: 4 (0.2500:0.7500) p:14 m:14 C:14 r:14 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Having been through a similar exercise in another WG, I believe the best course of action is to negotiate an appropriate "disclaimer" note with the shepherding AD. The contents of the note will likely not fully satisfy the WG members who think the draft is entirely "broken", nor satisfy the authors who think it's an eminently reasonable extension. The whole issue of "questionable" extensions to IETF protocols is something of a murky depth. The "suitability disclaimer" is the best available method of dealing with these situations. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 12:02:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkldO-0006pn-Qa; Fri, 09 Dec 2005 12:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkldN-0006p9-C8 for pppext@megatron.ietf.org; Fri, 09 Dec 2005 12:02:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01156 for ; Fri, 9 Dec 2005 12:01:11 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkldR-0002fc-W3 for pppext@ietf.org; Fri, 09 Dec 2005 12:02:19 -0500 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id jB9H1krI064796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Fri, 9 Dec 2005 10:01:46 -0700 (MST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id jB9H1kHh064795 for pppext@ietf.org; Fri, 9 Dec 2005 10:01:46 -0700 (MST) Date: Fri, 9 Dec 2005 10:01:46 -0700 (MST) From: Vernon Schryver Message-Id: <200512091701.jB9H1kHh064795@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: <5BEF683C-7341-4581-821D-C1FAD653311B@columbus.rr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: Karl Fox > Yes, it did do an end run around PPPEXT, I think I'd rather have been told I was wrong about about that. > but since then I've seen > more hints that the IESG might be willing to listen to the WG as > expert on the topic and act accordingly. I say we ask them to nix > the whole thing, and come back to us for text mods if they disagree. Are you sure that the PPPoE end-run was not the result of a perception of PPPEXT as obstructionist? > Why can't the company just fix their design? because they won't fix their design. Even if you doubt the literal accuracy of the comments about umptygazillion units already installed, you must take them as indications of flexibility. The most and best the IETF can do is refuse to allow the draft to be withdrawn and insist that it be published with what have been called biased words. This is clearly not the place to debate fixing the IETF. If it were, I'd point out that the IETF was built on the publication of RFCs and that those Requests For Comments were just that. The last 20 years have demonstrated that the IETF is, like every bureaucracy or committee system, almost purely political and incapable of self-discipline. Therefore perhaps the best course for the IETF would be more willingness to publish good and bad ideas, but with evaluations. Or perhaps not. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 12:04:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklfT-0007GR-MY; Fri, 09 Dec 2005 12:04:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EklfR-0007Bc-Jd for pppext@megatron.ietf.org; Fri, 09 Dec 2005 12:04:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01427 for ; Fri, 9 Dec 2005 12:03:11 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EklfO-0002ke-G8 for pppext@ietf.org; Fri, 09 Dec 2005 12:04:19 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jB9H423F001008 for ; Fri, 9 Dec 2005 10:04:02 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB9H41Wg024906 for ; Fri, 9 Dec 2005 12:04:02 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB9H41l6006987; Fri, 9 Dec 2005 12:04:01 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB9H41k5006984; Fri, 9 Dec 2005 12:04:01 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.47361.253776.227043@gargle.gargle.HOWL> Date: Fri, 9 Dec 2005 12:04:01 -0500 From: James Carlson To: Bo Berry Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Bo Berry's message of 9 December 2005 11:27:07 References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> <104B0E92-C0C3-4D99-A7D6-DBECC54FF53A@columbus.rr.com> <17305.37461.664962.331436@gargle.gargle.HOWL> <4399B05B.6040503@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, William Allen Simpson , Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Bo Berry writes: > Guess it would not be unexpected to say that we disagree > with the text and addition of the disclaimer. It appears > from these emails (and from emails of past as well), that > there is a lot of disagreement on PPPoE. We're not Indeed, but that's not the point at all. PPPoE isn't actually needed to solve the problem here. > trying to to correct PPPoE. We're not here to debate the > process and value of IETF Informational specs. Nor are we. > We have proposed and documented extenstions to the PPPoE > spec, which are within the context of that spec. These > are documented as optional. "Optional" does not mean "without cost" or "quality is unimportant" or even "I get to publish without addressing issues from reviewers." > The draft went through the IETF process and has gone through > the expert review period. At this point we can agree to > disagree. Therefore we request that the draft be published > as is, without any inserted (bias) text, and without any > further delay. Sorry, but that's not the way it's going to happen. You don't own this particular vanity press. The IESG intends to publish the document with a suitable warning to summarize that there is no consensus that this protocol addition is a good idea. This could have happened without input from any of us; the process allows that (see section 4.2.3 of RFC 2026 if you're unfamiliar with the process). Our AD politely asked for input, and I suggested taking it to the list because I wasn't one of the principals involved in the original discussion, and I wanted to capture the problem accurately and succinctly. I believe we've managed to do that. If you want it published without "bias," then I suggest that you withdraw the request to publish and use your own press instead. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 09 12:20:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eklus-0003kC-4u; Fri, 09 Dec 2005 12:20:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekluq-0003hc-FM for pppext@megatron.ietf.org; Fri, 09 Dec 2005 12:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03037 for ; Fri, 9 Dec 2005 12:19:04 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eklum-0003Jq-8n for pppext@ietf.org; Fri, 09 Dec 2005 12:20:12 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jB9HJtdK027089 for ; Fri, 9 Dec 2005 09:19:56 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jB9HJrWe001694 for ; Fri, 9 Dec 2005 12:19:55 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jB9HJrIq007076; Fri, 9 Dec 2005 12:19:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jB9HJrW2007073; Fri, 9 Dec 2005 12:19:53 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17305.48313.646945.693794@gargle.gargle.HOWL> Date: Fri, 9 Dec 2005 12:19:53 -0500 From: James Carlson To: Mark Lanzo Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit In-Reply-To: Mark Lanzo's message of 9 December 2005 11:57:12 References: <43996295.2020003@greendragon.com> <200512091657.LAA28631@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, wsimpson@greendragon.com X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Mark Lanzo writes: > > Going back 20+ years, I have had considerable experience deploying > > protocols over radio links. The best design would be to put a router > > at every radio link. Goodness gracious, TAL did it commercially going > > on 15 years ago! Simple 2 port routers are cheap! > > Hmm ... but this does not address the problem; it is not the issue. Actually, it is exactly the issue. > The issue is that the routers have to _connect_ to the radios > somehow. The radios aren't integral to the router; the radios and > router aren't even made by the same company. This is the part that's completely broken. You're implicitly assuming that the device labeled "radio" is able to implement Ethernet and PPPoE, and be modified to accept this new PPPoE feature, and that you can modify the box labeled "router" accordingly, but that it is impossible to terminate PPP or route IP in the "radio," and that device couldn't possibly manage to do the work without having an external router as a crutch. Why is that? The answer likely revolves around some notion of what's "too hard" or "too expensive" to implement in a small embedded system. Assuming that's the case, it's easy to reject the proposal on the grounds that designing protocols based around today's hardware limitations is both short-sighted and without merit. ("Without merit" because by the time you actually get all this stuff deployed and widely interoperable, the original problem is long since forgotten.) > Meanwhile, I believe it was thought that not reinventing the wheel, and > trying to have a published standard which radio manufacturers and router > vendors could agree to use for interconnecting their equipment, would be > a Good Thing. Is there some other protocol out there already, which is a > better choice [especially one whose very mention won't automatically > trigger a knee-jerk negative reflexive action]? Yes. Terminate PPP in the device labeled "radio," and put plain old IP on the Ethernet. No new protocols required. > Would it help if the proposal began with a clearer explanation that > although it "extends" PPPoE, that the usage is not in fact for PPPoE > as traditionally recognized, but instead is being used as a protocol > for using an ethernet as a backplace for communicating with external > serial-port "concentrators"? Is there a different RFC this group > should be looking at, which already provides just this sort of thing? L2TP can do such a thing, but it's clearly, just like PPPoE, an unnecessarily complex solution. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun Dec 11 19:59:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elc2b-0007lP-6y; Sun, 11 Dec 2005 19:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elc2Z-0007lG-JT for pppext@megatron.ietf.org; Sun, 11 Dec 2005 19:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01498 for ; Sun, 11 Dec 2005 19:58:47 -0500 (EST) Received: from mail.watervalley.net ([64.49.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Elc3F-0003zv-RJ for pppext@ietf.org; Sun, 11 Dec 2005 20:00:27 -0500 Received: from [207.74.178.173] (pm914-19.dialip.mich.net [207.74.178.173]) by mail.watervalley.net (Postfix) with ESMTP id 47BAC11D5A5 for ; Sun, 11 Dec 2005 18:59:10 -0600 (CST) Message-ID: <439CCB65.1090202@greendragon.com> Date: Sun, 11 Dec 2005 19:59:17 -0500 From: William Allen Simpson User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: pppext@ietf.org Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit References: <7FB7EE0A621BA44B8B69E5F0A09DC76401170857@xmb-rtp-208.amer.cisco.com> <43996295.2020003@greendragon.com> <17305.33797.545874.434026@gargle.gargle.HOWL> In-Reply-To: <17305.33797.545874.434026@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James Carlson wrote: > William Allen Simpson writes: >> While I, for one, would not! Merely describing the protocol deployment >> environment is a part of the specification, not a WG warning about the >> poor design. > > I had intended to integrate that text into the previous warning, not > replace, and was just word-smithing the subset to get the commentary > on the original usage case right. Something like this: > > "The PPP Extensions Working Group (pppext) has reservations about > the desirability of the feature described in this document. In > particular, it solves a general problem at an inappropriate layer > and it may have unpredictable interactions with higher and lower > level protocols. The techniques described in this document are > intended for use with a particular deployment technique that uses a > PPP termination separated from a radio termination by an Ethernet, > and that has radio-side flow control for a slower PPP-only link to > remote nodes. Implementors are better advised to avoid split > termination and use traditional IP routing instead." > OK. I'd say "... split termination with inter-media protocol translation, and use standard Internet Protocol routing instead." Just so it's very clear that there's a box there doing work, probably involves software, monitoring, passing packets between two interfaces that require packet translation, and most other features of an INTER-net router, but not actually meeting the router requirements. After all, as the Cisco folks are saying, it's not "THE router" -- by which they mean their expensive router, as opposed to the other vendor's simpler box. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun Dec 11 20:36:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elcbt-0007Pv-KL; Sun, 11 Dec 2005 20:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elcbs-0007PU-P0 for pppext@megatron.ietf.org; Sun, 11 Dec 2005 20:36:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04864 for ; Sun, 11 Dec 2005 20:35:08 -0500 (EST) Received: from mail.watervalley.net ([64.49.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ElccS-000549-5h for pppext@ietf.org; Sun, 11 Dec 2005 20:36:48 -0500 Received: from [207.74.178.173] (pm914-19.dialip.mich.net [207.74.178.173]) by mail.watervalley.net (Postfix) with ESMTP id 4151811C7A8; Sun, 11 Dec 2005 19:35:51 -0600 (CST) Message-ID: <439CD402.5040905@greendragon.com> Date: Sun, 11 Dec 2005 20:36:02 -0500 From: William Allen Simpson User-Agent: Thunderbird 1.5 (Macintosh/20051025) MIME-Version: 1.0 To: pppext@ietf.org Subject: Re: [Pppext] warning suggestions for draft-bberry-pppoe-credit References: <200512091657.LAA28631@cisco.com> In-Reply-To: <200512091657.LAA28631@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Mark Lanzo wrote: > On 9 Dec, William Allen Simpson wrote: >> Going back 20+ years, I have had considerable experience deploying >> protocols over radio links. The best design would be to put a router >> at every radio link. Goodness gracious, TAL did it commercially going >> on 15 years ago! Simple 2 port routers are cheap! > > Would it help if the proposal began with a clearer explanation that > although it "extends" PPPoE, that the usage is not in fact for PPPoE > as traditionally recognized, but instead is being used as a protocol > for using an ethernet as a backplace for communicating with external > serial-port "concentrators"? Is there a different RFC this group > should be looking at, which already provides just this sort of thing? > Ah yes, I remember when it was thought that implementing PPP was too complex for a "serial port concentrator" until Telebit did it on a 286, and then many other firms. Took Cisco years to catch up. And I remember when it was thought PPP was too complex for end user terminal devices, until Vocal did it in a modem that could sit in the palm of your hand, and Qualcomm did it in a cell phone (IIRC, both were 186 embedded processors with something like 4K RAM). The Qualcomm phones could run *2* PPP sessions, one over the radio link, and another over the serial port to a laptop, _and_ emulate a fax/modem, _and_ run simultaneous voice. (Disclaimer: I helped design and implement all products mentioned above, so I'm probably biased.) You might look at EIA/TIA/CTIA IS-99, although it's probably not an Interim Standard anymore (having written the thing circa 1993). And that also would still require modification to the radio.... Really, just because there are "dumb" ethernet-radio bridges doesn't mean they're a good idea. Especially in these days of cheap memory. Caveat emptor. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 23 12:45:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epqz7-0006Md-Ji; Fri, 23 Dec 2005 12:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epqz5-0006MR-0Z for pppext@megatron.ietf.org; Fri, 23 Dec 2005 12:45:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12658 for ; Fri, 23 Dec 2005 12:44:32 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Epr26-0002HG-1Z for pppext@ietf.org; Fri, 23 Dec 2005 12:48:49 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jBNHjT4u007865 for ; Fri, 23 Dec 2005 09:45:29 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jBNHjTWa003548 for ; Fri, 23 Dec 2005 12:45:29 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jBNHj5MV005486 for ; Fri, 23 Dec 2005 12:45:05 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jBNHj5UP005483; Fri, 23 Dec 2005 12:45:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17324.14241.286426.919016@gargle.gargle.HOWL> Date: Fri, 23 Dec 2005 12:45:05 -0500 From: James Carlson To: pppext@ietf.org X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Pppext] last call done for PPPoE MTU (draft-arberg-pppoe-mtu-gt1492-02) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org I've not seen any more comments on this draft, so I'm closing the last call. I'll let the AD know that the working group recommends that this be published as Informational. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Dec 23 12:54:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epr7E-0000qK-JY; Fri, 23 Dec 2005 12:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epr7D-0000ox-2t for pppext@megatron.ietf.org; Fri, 23 Dec 2005 12:54:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13929 for ; Fri, 23 Dec 2005 12:52:56 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EprAF-0002ZZ-RF for pppext@ietf.org; Fri, 23 Dec 2005 12:57:13 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jBNHrvD7016660 for ; Fri, 23 Dec 2005 10:53:57 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jBNHrvWa006284 for ; Fri, 23 Dec 2005 12:53:57 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jBNHrvAn005548 for ; Fri, 23 Dec 2005 12:53:57 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jBNHrvqU005545; Fri, 23 Dec 2005 12:53:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17324.14773.254633.66890@gargle.gargle.HOWL> Date: Fri, 23 Dec 2005 12:53:57 -0500 From: James Carlson To: pppext@ietf.org X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Pppext] last call for draft-arberg-pppoe-iana-00 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a last call for comments on draft-arberg-pppoe-iana-00. It's been several weeks, and I haven't seen any comments on it. I believe this ought to be advanced as a Best Current Practice. It does not obligate this working group to review PPPoE extensions, which are Informational anyway, but it does provide a way for users to stay out of each other's hair, so I think it's for the common good. Because of the upcoming holiday, I'm setting the deadline for comments to January 13th, 2006. If you need more time, please say so. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext