On 7/28/2016 1:29 PM, Theodore V Faber wrote: > On 7/28/16 13:18, Joe Touch wrote: > > > > 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. > > No. The Postel Principle applies to networking in general. "Be > simple in your behavior and tolerant of others" does not include any > proviso about an IETF position.
"Be liberal in what you accept, and conservative in what you send." - RFC1122 RFC760 puts it into exactly the context I indiicated: The implementation of a protocol must be robust. Each implementation must expect to interoperate with others created by different individuals. While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior. I.e., applies when there is ambiguity. > ... > >> 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. > > "React?" Bah. > > How is my position unclear here? I advocate that the IETF do nothing. > > Perhaps in a just world, their competitors should pipe up and say > "Whoever's crappy product breaks stuff." The IETF has said its piece: > "there is no constraint on the order of TCP options." That's not strictly true. RFC5925 requires that TCP-AO come first, because it would be impossible to undo the effect of processing earlier options when the AO option might indicate the packet is not authentic. However, I'm only saying that the IETF should not be changing TCP specs solely to transit devices that violate this order independence. > > 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. > > We prefer different societal pressures, evidently. I like the one > where I can be lazier. It's fine to say "just don't deal with middlebox option order issues", but then we end up with broken behavior. Is that a viable way to leave things? Joe
