"Scharf, Michael (Nokia - DE)" <[email protected]> writes:
>> First, I'm fine with not further discussing as you suggest. However, >> IANA does assign TCP option kinds to experimental RFCs (e.g., >> RFC6824, with option kind 30 for multipath TCP, and I hope one day >> TCP-ENO as well). So I hope it's not completely unreasonable to >> imagine future experimental RFCs that use TCP options to say >> something about tcpcrypt. > > In this context, I want to mention once again that in my point of view the > TCP-ENO specification should use RFC 6994 right now: > > https://www.ietf.org/mail-archive/web/tcpinc/current/msg00815.html > > https://www.ietf.org/mail-archive/web/tcpinc/current/msg00817.html > > I'd like to explicitly thank for ignoring my feedback. First, believe it or not RFC6994 is actually standards track, so not necessarily relevant in this context (namely the question of what RFCs can cite ENO). Second, I thank you for your feedback. We certainly did not ignore it, as evidenced by some of my replies to your messages. On the specific point of switching to option kind 253 or 254, there are good points on both sides. Squatting no doubt involves risk. However, RFC3692 also prohibits use of 253/254 in shipping products like tcpcrypt, so we're kind of in a catch-22. In the absence of working group consensus, we decided to maintain the status quo and keep squatting. Since IANA tacitly acknowledges and documents option squatting, it's reasonable to hope that no one else will concurrently squat on 69 (or any of the other 8 numbers with known unauthorized use) before we get an RFC. At any rate, I hope the point becomes moot when IANA allocates a dedicated option kind number to the TCP-ENO RFC. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
