Joe Touch <to...@isi.edu> writes: >> 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.
IANA claims 253/254 are already being "improperly used for shipping products", presumably in violation of RFC6994. http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1 Until we get an official option kind, this is just a lose-lose situation. But also, note that the WG documents are not actually using a squatted number. For now the number is symbolic in the actual document. So technically you can criticize our pre-RFC deployment, but the working group itself isn't necessarily guilty of anything. >> 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. It may not be clear why, but it happens (as evidenced by RFC7413, an experimental RFC, moving from option kind 254 to 34). Look, I don't have anything against RFC6994, which seems like a good idea. But all else equal, I'd rather not lose 2 more bytes of option space or risk colliding with whoever is squatting on 253/4 without a valid ExId. More importantly, I don't want to keep re-litigating this point. If you'd formed working group consensus around getting an ExID, we would have switched to RFC6994. At this point, we're on the home stretch for an RFC and have a bunch of deployed code out there, so our efforts are better spent finishing the existing document. The good news is that at least ENO is a bit like RFC6994 in allowing use by multiple protocols. So if we are going to consume another short option kind for an experimental RFC, assigning it to ENO will not be wasteful. David _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
