On 7/5/2016 10:33 AM, Black, David wrote: > Joe, > >>> Implementations MUST NOT use option kind 69 unless and until it is >> replace 69 with TBD >> >>> assigned to TCP-ENO by IANA. In the meantime, implementations MUST >>> use experimental option 253 [RFC6994], to which IANA has assigned >>> ExID 0x454E (encoded by decimal bytes 69, 78 in Figure 1). >>> Conversely, after IANA assigns a dedicated option kind to TCP-ENO, >>> the use of option 253 is deprecated. >> The above is OK. >> > Is it also worthwhile to have this draft record the unauthorized use of > option kind 69 for a prior protocol that is superseded by TCP-ENO? This > would be only as a description of what's happened. If and when 69 is assigned - yes.
But not before and not if a different codepoint is assigned. It's sufficient to say that "all previous variants of this protocol are superceded by this", which applies both to content and codepoints. > I can argue this both ways - not blessing prior bad behavior vs. recording > what > happened. The latter provides IANA with a reference for the unauthorized > use and would enable this draft to at least discourage such use. OTOH, > having been in an analogous situation in the past, I'm not optimistic about > ever reclaiming that option kind value. > > Right now, it looks like the intent is not to ask for option kind 69 - if > that were > to be requested, this draft ought to have additional text on how a receiver > distinguishes TCP-ENO from past use of that option kind (and what happens > if the use of option kind 69 that shows up doesn't match what the receiver > expects). That seems like to would be a very appropriate punishment for the behavior. Or worse, being assigned a codepoint others are squatting on. Sauce for the goose, as it were. IMO, if you pee in the well, you'd better be ready to drink from it. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
