> 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.
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. 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. 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. Michael _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
