On 4/28/2016 4:35 PM, David Mazieres wrote: > "Scharf, Michael (Nokia - DE)" <michael.sch...@nokia.com> 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).
I'm fairly sure that both Michael and I are citing 6994 the other way around (that ENO would use 6994). Just like you almost do below... > > 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. Please read RFC6994. > > 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, Got an RFC for that? IANA recognizes that it happens but it's not endorsed and not typically considered in applications (e.g., see RFC6335 in the impact of squatting on port assignments). I cannot understand how a WG item is using a squatted number. This point was raised a LONG time ago. > 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. Given RFC6994, it's not clear why an experimental TCP option should ever be allocated a separate option kind number until it becomes standards-track. Joe _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
