Joe Touch <[email protected]> writes: > On 7/1/2016 11:20 PM, David Mazieres wrote: >> So from my limited experience, it seems like one is supposed to ask IANA >> for a specific number to which they reply yes or no, rather than asking >> them to choose the number. > You can (but aren't required to), but that isn't part of the doc. It's > typically part of the out-of-band info in the request to IANA. > >> I was hoping that since we say you MUST NOT >> implement 69, this would satisfy the objections to option kind >> squatting. > > So then what number might you ask for? You've effectively poisoned the > well for 69. IMO, you ought to either use that or some other number on > which others have squatted ;-) But that's not a decision to include > inside this doc (see above).
I don't think your comments make sense in light of the new draft. We are specifically trying NOT to poison the well any further by A) using 69 in the draft (already slightly poisoned), and B) saying people MUST NOT implement option 69 before IANA assignment. >> (Michael Scharf did at one point suggest he would be okay >> with the statement, "This protocol specification MUST NOT be implemented >> prior to assignment of a TCP option kind number.") > > That's a hollow statement if you are planning on testing this code while > you're writing the spec. The correct answer (IMO) is to use an ExID with > the experimental option in this doc until a value is assigned by IANA. > ExIDs are FCFS assigned with low hurdle. So then you are happy with draft 02 I take it? It reads: Implementations MUST NOT use option kind 69 unless and until it is 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. We are trying to follow the precedent of RFC7413 here. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
