One of the recurring pathologies that I see in IETF is that there are really two very distinct set of problems with largely disjoint communities and that is OK until we get problems in one set being subject to the constraints of the other.
Short, compact identifiers make perfect sense at the narrow waist. That is a place where every byte counts and we want to discourage unnecessary variation.
I have been in meetings where people have been valgrinding over minimizing the size of framing data where the subject matter is streaming video. Heck, I have probably been the person doing it on occasion. Easy enough to do.
Apollo Computer proposed the standard for random identifiers, nown known as GUIDs and UUIDs. See RFC4122.
Reason I like OIDs is that every crypto algorithm is going to need one anyway.
The other point to consider is the difference between names and indexes. A name is a signifier that has a purely conventional relationship to the signified. 'Alice' is a name, there is no reason to expect any correspondence to Alice the person.
For most protocols, an index is preferable. So we could take the SHA-2-256 digest of the specification and turn it into Base32. Or we take the digest of a bunch of names, or whatever.
For a specification, a better approach would be to have a public signature key involved so the document can change and the author can still claim ownership.
So I would generate a unique nonce for the document and then make the identifier the digest of that nonce and the digest of the controller's signature key.
On Fri, Dec 13, 2024 at 11:59 PM Joel Halpern <jmh@xxxxxxxxxxxxxxx> 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
