-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 7/28/16 13:46, Joe Touch wrote: > > > On 7/28/2016 1:29 PM, Theodore V Faber wrote:
>> 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. That's a remarkable interpretation of the "In general," prefix that I simply disagree with. (And for the record, I agree that the principle applies when there's ambiguity; I also think it applies when there is none - it applies "In general".) Beyond the textual analysis, I think restricting that idea in the (IMHO narrow) context of resolving specification ambiguity sells it short. > >> ... >>>> 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. That sounds like we agree. :-D > >>> 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? I am not personally nor is the IETF collectively in a position to enforce good behavior from network devices. At the scale and complexity of the Internet, I don't think one could enforce even compliance with published IETF standards. I think trying to turn the IETF from a group of engineers who publish their consensus on interoperation issues (y'know mostly) to some kind of implementation evaluation and enforcement body is a waste of time at best and counterproductive at worst. I understand that we disagree on this, and I'm a little sad we won't get to do so over coffee. - -- Ted Faber <[email protected]> Engineering Specialist Computer Systems Research Department 310-336-7373 -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJXm221AAoJEFNjQnOBW8uO174P+gIRyGNpSbWo3iHNTCFb0hie bbtuJ3wBbMulC5T/PTglF3CWHpUKXUVAX4Bj4PllGYHHvEGsSjfsGLi0u1Cvtue7 ubGXiw+Gim+axcorl7D6bogkTQbH4MmgOIoPiymRQQ8lICqnVhBaSfi1aSdr0PBY e0TVHJZicd83IG2P4S0zM2HapPZV43UPHNMgbcuX6/1EPZ/UGZY81T4Ut7O4aIw7 t6VE52iW416mcNyfQXcOHTN6RuhKjLnu/4au5mpBeZlRqR5EeLSP3JtDGpoFF4Sl 61No/qcaYLpxH+g+0XMjF9DqAiAfTj0pSWIwYn00Y5GGizgE44M5q4/V8IZ/MwzM 5yuB+5Rk1DHHTnJ9Q7+kGzPf2M55faiqUcLwyjNR/Chu5oSUcqOQYXyDbbh3fbJx eDxmO8xpnQBELFqBYN8hEPmDukAyHBIuW9StyJ+jrU5BawXBMzR8x4FN2/gYiRMJ 8XjpVoMp8WU9nj/cmHZPcJf9aO/knLX9jwytdXUYEevxylch+bpkszQkb7IDGuc3 I5hIN1sHibONr1RwdmMbwYyJwXgORcpzC8zuHk5aGYBbE8Ufgw7mfRcDcqeaO7vr uPRhHUQ68KHGnTjGAEb/cfQ/JaIyxqPTjrnx3Jnor4ObRxkGTxymiZQM1BRVVEUG faq018lavMUE1SU8j+JF =u47i -----END PGP SIGNATURE-----
