On Wed, Oct 28, 2020 at 04:25:34PM +0100, Toerless Eckert wrote: > On Tue, Oct 27, 2020 at 02:52:01PM +0000, Salz, Rich wrote: > > > > > So... should the protcol spec have a requirement stating that implementations > > MUST ensure this can not happen, and - oh, go figure out how to do that, not a > > protocol issue ? > > > > I am not sure what you are trying to say. That it's hard to determine where the fault is sometimes? I don't think anyone disagrees with that. > > I have seen in the past and still a lot of resistance in standards track work to > go beyond a mathematical proveable change of packets on a physical long enough > wire. In discussions with past ADs, this has even gone as far as examples of "protocols" > between two (possibly different vendor sourced) software components within a single box as > being something not appropriately called standards protocol work for the IETF. Not > sure if you remember the history of not allowing standardization of APIs, and > only fairly recently having seen that changing. FWIW, any reluctance to standardize APIs is not universal -- RFC 1508 dates from 1993. -Ben
