You are correct on that point, Joel -- the size of the field matters.
For example, we are not going to let developers pick random 4 bit values
for the IP version number. On the other hand, that's something that WG
very often could fix. They could often make sure that new protocols or
new versions of an old protocol include large enough extension
identifiers, maybe by adding a level of indirection somewhere. That
seems better than relying on IANA to manage scarcity.
-- Christian Huitema
On 12/13/2024 8:58 PM, Joel Halpern wrote:
There are certainly contexts where that works. And so, for those,
define a suitable registry policy (if you even need one, long random
numbers don't seem likely to collide). On the other hand, for 8 or 16
bit fields, I don't think that works :-)
That's a part of why different registries have different polices.
Yours,
Joel
On 12/13/2024 11:27 PM, Christian Huitema wrote:
On Dec 9, 2024, at 12:24 PM, Phillip Hallam-Baker
<phill@xxxxxxxxxxxxxxx> wrote:
The big advantage of OIDs for algorithms is that anyone can define
them without IETF involvement and thus the issue of endorsement
simply doesn't come
That, or large random numbers, like the 62 bit integers used to
identify "transport parameters" in QUIC. As long as they are actually
picked at random.
I think that's actually key. Writing a draft in order to secure a
unique number seems backwards. Drafts ought to be written in order to
express an idea, maybe a protocol option. Extension mechanisms ought
to be designed to make such experimentation easy. Making the ID space
for extensions big enough solves that, allows the draft authors to
document the option ID and allow experimentation immediately.
RFC publication is then the time to go from long random numbers to
more efficient short and registered numbers.
-- Christian Huitema
