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
