Excepts for those who have (still) not yet read RFC6994 (and some corrections on misconceptions) below.
Joe On 4/29/2016 3:06 AM, Scharf, Michael (Nokia - DE) wrote: >> But more to the point, what is your concrete proposal? > 1. Get an ExId from IANA. I think filling out > http://www.iana.org/form/protocol-assignment can be done in 5min. This can be > done by anybody interested in experimenting with TCP options, because it is > clear that there is a need to experiment with TCP extensions prior to an > official TCP option kind assignment by IANA. RFC 6994 was written for that. "ExIDs are registered with IANA using "first come, first served" (FCFS) priority based on the first two bytes." There is no requirement for an RFC, a particular development track in the IETF, or anything else to request an ExID. > 2. Note down in the TCP-ENO document how TCP-ENO uses the ExID according to > RFC 6994. In the simplest case, this may only affect the IANA section. For > full interoperability between different TCP-ENO experiments, indeed, you > might have to specify in the ID whether to use 253 or 254 or both. IANA > allocates the ExID for both options. "ExIDs are registered for use with both of the TCP experimental option codepoints, i.e., with TCP options with values of 253 and 254." There's no requirement that they be used with both codepoints; that's up to the protocol designer. > 3. Assuming that the TCP-ENO spec will be move forward soon, assuming the > TCPINC WG will formally ask IESG for an exceptional assignment of a new TCP > option kind number, and assuming that IESG will finally approve this > exception, you could perhaps just reuse some wording from the IANA > considerations of RFC 7413 without changing the rest of the protocol spec. > > Under the mentioned assumptions I do not believe that this would create major > migration problems as the transient period might be short in the best case. > It is up to the TCPINC community to decide on whether to discuss potential > migration strategy for pre-standard protocols possibly using codepoints not > approved by IANA. Of course, it is up to the IESG to decide whether to indeed > assign a TCP option kind number to an experimental protocol. > > Alternatively, you could just decide to specify the use of codepoints 253 or > 254 without an ExID value for TCP-ENO prior to the IANA assignment. That > would have been the method prior to RFC 6994. That's counter to the recommendation in RFC6994: " >> All protocols using the TCP experimental option codepoints (253, 254), even those deployed in controlled environments, SHOULD use ExIDs as described in this document." > And I guess the document could stay as it is right now if this is only a > conceptual proposal and there is really no plan to implement the TCP-ENO > mechanism any time soon. That would be a bit strange but if the TCPINC > community concludes that there will be no implementation of the TCP-ENO prior > to an IANA option kind allocation, indeed, there may be no need to explain > how the protocol could be implemented. Formally this could perhaps be > achieved by a statement in the I-D such as "This protocol specification MUST > NOT be implemented prior to assignment of a TCP option kind number" or > something like that. IMO, that would be a good idea as well. Also, RFC6994 Section 5 discusses issues with transitioning to assigned option codepoints. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
