Re: warning suggestions for draft-bberry-pppoe-credit

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
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext