Omission of 16-bit value when dicussing reserving ranges

[LPardue]

Section 2.1 states

The specific size and distribution of the grease range needs to accommodate the protocol constraints. For instance, protocols that use 8-bit fields may find it too costly to dedicate many grease values, while 32-bit or 64-bit fields are likely to have no such limitations.

There will be folks that want to apply the guidance to 16-bit value and the omission sticks out a bit. Should they do a range or not? Being exhaustive in the lower bit count space seems helpful.

Perhaps we can tweak the text to something like "less than X bits may find it too costly, more than X bits are likely to be ok"?

[chrysn]

I'd treat that as a continuum, where 16-bit doesn't necessarily need to be called out. From the EDHOC case where this came up, I think the more valuable takeaway would be something along the lines of

The specific size and distribution of the grease range needs to accommodate the protocol constraints. For instance, protocols that use 8-bit fields may find it too costly to dedicate many grease values, while 32-bit or 64-bit fields are likely to have no such limitations. For fields with variable length encoding, it can be beneficial to have values that lead to the different encoding variants.