Re: [tcpm] On allocating reserved bits in the TCP header

["Rodney W. Grimes" <[e-mail]>]

Reviving this thread,

> Hi all,
> 
> Disclaimer: I write this note as individual contributor to TCPM. It is possible that I end up in the rough part of the TCPM consensus in this case. That would be unusual, but it is not impossible. If so, this e-mail documents my concerns (again). Reasonable people can reasonably disagree, and that does not prevent the working group from moving forward. I'd also like to announce that I would prefer not to serve as shepherd for a document if consensus has to be declared against me, in order to avoid any bias.
> 
> Given that we need to finish draft-ietf-tcpm-accurate-ecn, and given other recent TCPM discussions on reserved TCP header bits, I have thought about the IANA considerations of allocating a reserved header bit. This e-mail is not about the question of _whether_ to allocate a bit. It is about the _how_.
> 
> That question was discussed in the past for draft-ietf-tcpm-accurate-ecn already quite a bit, e.g. during IETF 99. During that discussion, I have raised concerns against allocating a bit in the main TCP to an experiment without backing by a standards track RFC. I may have been in the rough part of the consensus in the room when that discussion took place. But I have not changed my mind.
> 
> The statement in RFC 2780 is: "The reserved bits in the TCP header are assigned following a Standards Action process."
> 
> RFC 8126 explains: "For the Standards Action policy, values are assigned only through Standards Track or Best Current Practice RFCs in the IETF Stream."
> 
> And I think that requirement in RFC 2780 is correct. I probably don't have to expand on why IETF rules make sense to me. RFC 2780 and RFC 8126 don't leave much room for interpretation, as far as I understand them.
> 
> It is well-known that bit 7 requested by draft-ietf-tcpm-accurate-ecn has previously been allocated to an experimental RFC (RFC 3540). That happened before I have joined IETF mailing lists, and I am not familiar with the corresponding discussions, most notably regarding compliance with RFC 2780. In any case, given that RFC 3540 is now historic and the bit is has status "reserved", the current IANA registration of TCP header flags is apparently compliant to RFC 2780.
> 
> In my reading of RFC 2780 and RFC 8126, it would be a policy violation to allocate a bit in the main TCP header to an experiment without a proper standards track document allowing this experimentation. I am convinced that for bits in the main TCP header the IETF should just follow its own rules.
>  
> And actually I believe it would not be hard to do so. For instance, TCPM could publish a short standards track RFC that allocates e.g. bit 7 for experiments. That could solve the allocation needed by draft-ietf-tcpm-accurate-ecn. Similar to RFC 8311, a standards track document could precisely define what experimentation is allowed with that bit. It would be a short document that could be finished on fast track, possibly even in parallel to draft-ietf-tcpm-accurate-ecn, provided that there is consensus on allocating e.g. bit 7 to a well-defined area of experimentation. It has been pointed out in the past that such as standards track document would result in overhead. I believe that the overhead would be small and worth the effort.
> 
> In any case, I feel uncomfortable with creating a precedent for IETF process violation regarding any of the reserved bits in the TCP header.

I have reviewed the above, and am in full agreement.

As author of draft-grimes-tcpm-tcpsce, which is also requesting use of a TCP bit for experimental purpose, ask what the next steps are?

-- 
Rod Grimes                                                 [e-mail]