On 7/28/2016 1:11 PM, Theodore V Faber wrote: > On 7/28/16 13:04, Joe Touch wrote: > > > I.e., we should NEVER use these boxes to govern how we build TCP > > for the masses. > > To say that another way: vendors who produce such devices are failing > to follow the Postel principle.
The Postel Principle talks about what to do when the docs don't say otherwise. > Whether the IETF says anything > explicitly or not, Actually, they're quite directly contradicting explicit existing standards. > they're producing artifacts of less value to their > customers. Standards-compliant stacks will emit TCP options in ways > that such vendors evidently don't expect. Those vendors shouldn't be looking at TCP options or TCP at all. It's none of their business. Maybe we should just start using IPsec in BTNS mode (to avoid needing keys) as a tunnel to get through all such devices. > > The IETF standard reflects a consensus among designers and > implementers that there's no constraint on TCP option ordering. The > time to argue about it is past; live with it or produce crappy products. This issue cannot be fixed merely by reacting to what vendors deploy. The solution has been clear for a long time - *compliance verification*. I assure you that vendors that get sued for saying "Internet compatible" who are not would behave differently. Joe
