Request IANA Registry

[kyzer-davis]

From Paul Wouters:

I am not sure that I agree that no IANA registry is required for hashspace
ID's. If another document adds new hashspace IDs, there won't be a single
document anymore that lists all of them, or massive duplication. This is
exactly what we use IANA registries for. Reconsider creating a new IANA registry.

IANA registration encompass;

1. UUID Variants
2. UUID "sub-versioning" (as linked to a variant)
   • See them all here: Discussion: Redefine variant bit (111) definition uuid6/uuid6-ietf-draft#26 (comment)
   • Nil/Max UUID
3. UUID Namespace IDs
4. UUID Hashspace IDs

[kyzer-davis]

Commenting for @ben221199 as per his vote for this under
#83 (comment)

[ben221199]

I'm definitely planning to have IANA considerations in the historical RFC that I want to make with @kyzer-davis after RFC4122bis is published. However, if we already can add some basic IANA considerations in RFC4122bis, I'm okay with that, but we should think this out very well. I don't want a shitty table which I regret making, because in that case I prefer having the IANA considerations only in the historical RFC.

[kyzer-davis]

From Francesca Palombini in IESG review:

I agree with Paul and was surprised to see no IANA registry is created (at least for var and ver), but the document does explicitly mention that "the authors and working group have concluded that IANA is not required to track UUIDs used for identifying items such as versions, variants, namespaces, or hashspaces.", so that makes me believe a discussion has happened around it and a conclusion reached. Without knowing much of the background behind it, I'll leave it to the responsible AD to make sure that has been the case.

[ben221199]

Do I have access to this conversation too?

[mcr]

Do I have access to this conversation too?

It's on the list archives.
I don't understand IANA considerations in a historical document.

[ben221199]

I see. I also received them by mail, but it was not directly clear from the mail subject.

---

I don't understand IANA considerations in a historical document.

Is there a problem with it? Or should we make the "historical" RFC informational?

[ben221199]

Proposition:

Note: I would suggest to discuss the policies in more detail. In this case I chose the policies I think suits best. For options, see Section 4 in RFC 8126.

UUID Variants

IANA is asked to create the registry "UUID Variants" under the "UUID Parameters" group. New registrations will be permitted through the IETF Review policy [BCP26]. Initial values for the UUID Variants registry are given below. Assignments consist of a variant name and its associated bitmap array indicating the variant.

Name	Bitmap	Definition
Apollo NCS	0xxxxxxx	[RFC4122bis]
OSF DCE	10xxxxxx	[RFC4122bis]
Microsoft DCOM	110xxxxx	[RFC4122bis]

Note: Maybe we should add another column for variant slugs.

UUID Subtypes

IANA is asked to create the registry "UUID Subtypes" under the "UUID Parameters" group. New registrations will be permitted through the IETF Review policy [BCP26]. Initial values for the UUID Subtypes registry are given below. Assignments consist of a subtype id, the binary version of the subtype id, subtype name, subtype kind and the variant it belongs to.

Name	ID	Hexadecimal	Kind	Variant	Definition
Unspecified	0	0x0	family	Apollo NCS	[RFC4122bis]
Internet (IPv4)	2	0x2	family	Apollo NCS	[RFC4122bis]
Time-based	1	0x1	version	OSF DCE	[RFC4122bis]
DCE Security-version	2	0x2	version	OSF DCE	[RFC4122bis]
Name-based using MD5	3	0x3	version	OSF DCE	[RFC4122bis]
Random	4	0x4	version	OSF DCE	[RFC4122bis]
Name-based using SHA-1	5	0x5	version	OSF DCE	[RFC4122bis]
Reordered time-based	6	0x6	version	OSF DCE	[RFC4122bis]
Unix epoch time-based	7	0x7	version	OSF DCE	[RFC4122bis]
Custom	8	0x8	version	OSF DCE	[RFC4122bis]

Note: Maybe we can do this a little bit better. Possibly using variant slugs.

UUID Special Forms

IANA is asked to create the registry "UUID Special Forms" under the "UUID Parameters" group. New registrations will be permitted through the IETF Review policy [BCP26]. Initial values for the UUID Subtypes registry are given below. Assignments consist of a name and its associated value.

Name	Value	Definition
Nil UUID	00000000-0000-0000-0000-000000000000	[RFC4122bis]
Max UUID	FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF	[RFC4122bis]

Note: Seems okay to me, but maybe some columns can be added.

---

This is a proposition. If you have improvements on it, please let us know. Also, lets discuss if IANA Considerations should be added in RFC4122bis, or should be done in another (seperate) RFC.

[kyzer-davis]

@ben I was thinking of a hierarchy like below, which would more or less use the tables you described.

• Logic, main section has variants table.
• Next top level sections are split by the variant (4 total)
  • Each variant section has a "subtype" and "special/reserved" sub-section.
    • Each of these can have sub-sections

Visualized:

Edit 9-11-2023: Removed ascii/text visual
Sections would contain table with any required data.

What we could setup in rfc4122bis

Note: Special/Reserved only to slot in min/max to the correct area.

Long Term, Fully Fleshed Out and Visualized

---

Another thing to consider is that we need to include how to update this or add new values to this registry:
Personally I would like to state in each section, something like:

• uuid-variant-apollo-ncs and uuid-variant-microsoft special/reserved/subtype only requires email template request to the designated expert with supporting 3rd party document. (This could save us from needing historical doc @ben221199)
• For uuid-variant-osf-dce-ietf
  • For both uuid-hashspace-ids/uuid-namespace-ids just require email template with required items to the designated expert in order to update the table.
  • For uuid-subtype-version require full RFC detailing algorithm e.g a future UUIDv9 would need to be explicitly defined.
• For uuid-variant-undefined (everything) an RFC or some other formal specification (say from ITU, ISO, IEEE, ETC) would be required to flesh this out.

We should also state that we won't just reserve any random UUID as "special/reserved" outside of hashspace/namespace/min/max.
If somebody has a UUID value that should be explicitly reserved; it should be documented in an RFC (or equivalent doc type) detailing why this value specifically is special, how it is used, etc.

EDIT:
Should we include a top level table for "UUID Representations", updatable via email template?

Second item, should we include the Test Vector UUIDs and any UUID specified in our RFC as special/reserved? in uuid-variant-osf-dce-ietf
This includes All Appendix items and f81d4fae-7dec-11d0-a765-00a0c91e6bf6 from Section 4 (AND RFC4122)
Edit2: Vectors updatable via RFC or equivalent doc.

[sergeyprokhorenko]

Should we include a top level table for "UUID Representations"...?

It's a good idea for the future improvements of the RFC4122bis: uuid6/new-uuid-encoding-techniques-ietf-draft#3 (comment)

[ben221199]

Hi @kyzer-davis, maybe because it is late here, but your comment confuses me at the moment. I will give it a second look tomorrow, but my first impression is that it seems overcomplicated.

(This could save us from needing historical doc @ben221199)

Also, I think we cannot avoid writing a new (historical) RFC. AFAIK I thought we didn't want RFC 4122 to describe other variants than the OSF DCE one.

[danielmarschall]

A few notes:

• Above you are writing "Microsoft DCOM" for the Microsoft Legacy UUIDs. Shouldn't it be just COM? AFAIK, the Legacy UUIDs were already existing in COM, before DCOM was invented.

• For Apollo NCS, you are only listing Unspec (family 0) and IPv4 (family 2). Missing: DDS (family 13) which was also in use.

• For Apollo NCS: Shouldn't the other address families be listed too? (although they were never in use)

  | socket_$unspec (0x0)
  | socket_$unix (0x1)
  | socket_$internet (0x2)
  | socket_$implink (0x3)
  | socket_$pup (0x4)
  | socket_$chaos (0x5)
  | socket_$ns (0x6)
  | socket_$nbs (0x7)
  | socket_$ecma (0x8)
  | socket_$datakit (0x9)
  | socket_$ccitt (0xA)
  | socket_$sna (0xB)
  | socket_$unspec2 (0xC)
  | socket_$dds (0xD)

[kyzer-davis]

@ben221199,

I think we cannot avoid writing a new (historical) RFC. AFAIK I thought we didn't want RFC 4122 to describe other variants than the OSF DCE one.

I say "avoid" only if there is no other doc describing them. If that does not exist, or exist anymore; we can get them in the historical RFC those so they are down on paper and not lost to time. If there is some other doc (like UUIDv2 has) then we can just reference that vs duplicating work.

Also, as for complication, I am not opposed to "one big subtype table" I was just trying to bundle subtypes and special UUIDs within their own variant sections to make the variant+subtype really shine.

Edit:
The section groupings also let us enforce different update methods for each so we can get a bit more granular if need be.
I am open for whatever, I was just thinking about Ben's statement "we should think this out very well. I don't want a shitty table which I regret making" in this case maybe I thought on it too much...
Edit2: Updated the format a bit, removed some items to get to the main structure of the data vs the items in the table.

@danielmarschall, I didn't mean to omit them. I am just not an expert in those specific UUID areas. I would rely heavily on info like that from yourself and Ben to fill out those "subtypes". Thank you for helping to complete the list.. and even if they were not used I would like to list them and we can put something like "allocated but unused".

[ben221199]

@danielmarschall

Above you are writing "Microsoft DCOM" for the Microsoft Legacy UUIDs. Shouldn't it be just COM? AFAIK, the Legacy UUIDs were already existing in COM, before DCOM was invented.

Actually, I don't know which is right, but when I searched the internet, DCOM seemed the linked technology to UUID. However, I could be wrong and COM could then be linked to UUID, with DCOM only as extended COM. I think we should dive into Microsoft COM some more to find out what it is, how it works and what it has to do with UUID (and when).

For Apollo NCS, you are only listing Unspec (family 0) and IPv4 (family 2). Missing: DDS (family 13) which was also in use.

I know that number 13 was used too, but at the time of writing I could find the right address family name for 13. I only came across a different name which I knew wasn't correct, or at least not correct in the UUID world. So I decided to not include it in my proposition. Also, it is a proposition; I only wanted to give a good example of how a table would look like. If records are missing, I will definitely add them. Thanks for mentioning DDS; now I remember that one was the correct one.

For Apollo NCS: Shouldn't the other address families be listed too? (although they were never in use)

I want to say yes, but I think it is best to only include the used ones, so 0, 2 and 13. If we find out other ones are used too, we can include them. I think Paul Leach can tell us more about this one.

---

@kyzer-davis

I say "avoid" only if there is no other doc describing them. If that does not exist, or exist anymore; we can get them in the historical RFC those so they are down on paper and not lost to time. If there is some other doc (like UUIDv2 has) then we can just reference that vs duplicating work.

I have the feeling it is better if we RFC-ify ever type and subtype in the end. We can reference to the old source docs in that RFC, but the RFC would re-define them in some way. This wil result in UUID being fully RFC-defined, which also has some advantages. That is the reason I think we cannot "avoid" writing one.

Also, as for complication, I am not opposed to "one big subtype table" I was just trying to bundle subtypes and special UUIDs within their own variant sections to make the variant+subtype really shine.

Hmmm, okay. 🤔

Edit:
The section groupings also let us enforce different update methods for each so we can get a bit more granular if need be.
I am open for whatever, I was just thinking about Ben's statement "we should think this out very well. I don't want a shitty table which I regret making" in this case maybe I thought on it too much...
Edit2: Updated the format a bit, removed some items to get to the main structure of the data vs the items in the table.

Well, at least you are thinking about it. 😁

[ben221199]

So, if I understand correctly, #144 (comment) has "registries containing registries" and "registries containing records"? For 4 or 5 levels???

As far as I have seen when I looked at the IANA files (also backuped here: https://github.com/larseggert/iana-assignments), I saw only 3 levels: Registry -> Subregistry -> Record.

In case of the general DNS Parameters (https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml), there is a registry with multiple subregistries with multiple records.

In case of EPP Parameters (https://www.iana.org/assignments/epp-repository-ids/epp-repository-ids.xhtml), there is a registry with a single subregistry with multiple records. However, EPP has multiple top-registries:

In your example, I see 4 or 5 levels. I don't even know if IANA even accepts that.

This what I have in mind:

• 📁 UUID Parameters (top-registry)
  • 📁 UUID Variants (sub-registry)
    • 📄 Apollo NCS
    • 📄 Microsoft DCOM
    • 📄 OSF DCE
  • 📁 UUID Subtypes (sub-registry)
    • 📄 ...
  • 📁 UUID Special forms (sub-registry)
    • 📄 ...
  • 📁 UUID Namespace IDs (sub-registry) [used in UUIDv3 and UUIDv5]
    • 📄 DNS
    • 📄 URL
    • 📄 ISO OID
    • 📄 X.500
  • 📁 UUID Hashspace IDs (sub-registry) [used in UUIDv8]
    • 📄 ...

Here, 📁 are registries and 📄 are records. I only used 3 levels. @kyzer-davis, maybe if you can make something similar with these emoji's, I can understand what your idea is. At the moment I think you have a 4 or 5 level hierarchical tree and I think IANA only supports 3.

[ben221199]

I have to say that I don't see the use of hashspaces if they are only used in UUIDv8. UUIDv8 is custom and vendor specific, so it seems to me that defining hashspaces is also up to the vendor.

[ben221199]

According to some code that seems to be Apollo NCS code, the following families are used:

Name	Description	Information
Unspecified	Also contains the Nill UUID	dec: 0, hex: 0x0, socket_$unspec, AF_UNSPEC
IP	Internet Protocol	dec: 2, hex: 0x2, socket_$internet, AF_INET
Apollo DDS	Domain Distributed Services	dec: 13, hex: 0xD, socket_$dds, AF_DDS

I have proof for 0 and 13. I didn't come across a 2.

[ben221199]

Unspecified (0):

000000000000.00.00.00.00.00.00.00.00    *

(Source: https://github.com/mit-athena/lpr/blob/master/quota/ncs/nck/uuidname.txt)

IP (2):

[
	uuid(48c2314d4009.02.12.48.00.63.00.00.00),
	version(1),
	port(ip:[3702])
]

[
	uuid(49c3f7aa8d7d.02.12.48.00.68.00.00.00),
	version(2),
	port(ip:[3703])
]

DDS (13):

[
	uuid(333b33c30000.0d.00.00.87.84.00.00.00),
	port( dds:[12] , ip:[135] ),
	version(4)
] 

[uuid(333a22760000.0d.00.00.80.9c.00.00.00), version(3)] 

[danielmarschall]

@ben221199

I have proof for 0 and 13. I didn't come across a 2.

An AF_INET UUID can be found here:
https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-command-ncs

%pascal
[
uuid (458487b55160.02.c0.64.02.03.00.00.00),
version (1)
]
interface INTERFACENAME;
 
end;

Hex "c0.64.02.03" is Dec "192.100.2.3".

[danielmarschall]

I have to say that I don't see the use of hashspaces if they are only used in UUIDv8. UUIDv8 is custom and vendor specific, so it seems to me that defining hashspaces is also up to the vendor.

I guess it is too late to make big changes, but I think it would have been better if there would be the following ( @kyzer-davis or is there a tiny chance?) :

• UUIDv8 - 100% custom UUID. 100% vendor specific.
• UUIDv9 - Hash based UUID (using hash spaces), as alternative to UUIDv3 and UUIDv5

[ben221199]

#144 (comment) Yes, I also found a AF_INET version.

[mcr]

This is way over the top.
All we need is one registry for well known namespace UUIDs.

[kyzer-davis]

Checking the "Registries and sub-registries" I see that the CSS can go as far as 6 levels deep.
My original example was actually only 3 but it can be scaled it back to 2. (Edit: revised my original comment with visual vs txt)

• https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml
• https://www.iana.org/assignments/_support/iana-registry.css

div.level2, div.level3, div.level4, div.level5, div.level6 {
    border-left: 1px dotted gray;
}

Ben's Proposal

Minimum required to meet IESG Proposal

---

I am fine with Ben's proposal of 5 sub-registries.
I am also fine with what was requested by IESG: just namespace/hashspace. (Though I think if we are doing it we might as well get var/ver along with special min/max "special" allocations"

But I do agree with @mcr, I just wanted to get the page hierarchy down in a nice way so adding things later is easy; with this I would be requesting the IANA page and filling out what we have control over in this doc.

If we need add "Families" later in the historical RFC it is easy to slot into the sub-registry somewhere or update a table but we don't need to dive deep into those nitty gritty details here.

[ben221199]

I'm also fine with the minimal version, if that causes us to get somewhere already. In that case, we only register UUID Namespace IDs and UUID Hashspace IDs for now. However, the only objection I have for hashspaces is that it is linked to UUIDv8, as I told in #144 (comment). The solution could be one of the following:

• Introduce a UUIDv9 that will take the time-based and name-based formats of UUIDv8 and leave UUIDv8 with only the vendor-specific custom format.
• Remove the time-based and name-based formats from UUIDv8 and specify UUIDv9 in another RFC.
• Leave out UUIDv8 entirely.

I don't think it will work out well if we use UUIDv8 for 3 different formats.

[danielmarschall]

I just had an idea in re hash space ID registry.

Since hash space ID and OID are connected, maybe it would be good having a registry for hash algorithms in general, instead?
I had a very hard time finding the OIDs of the most common hash algorithms (the result: see #143 (comment) ) so I think it would be super helpful if there would be a registry similar to this:

• Algorithm name (prefer the NIST naming, but maybe IANA want to introduce a different naming scheme? In any case, the algorithm name becomes more standardized and less ambigous)
• OID(s), optional
• Hash Space ID (optional)

There might be cases where the algorithm name is known, but neither an OID nor a custom hash space is known. In this case, the fields could be left empty. Or maybe IANA could automatically generate a random Hash Space ID when adding the algorithm to the registry.

**Edit: It turns out that this idea is already by kyzer-davis here #143 (comment)

---

In re UUIDv8 and UUIDv9

I'm also fine with the minimal version, if that causes us to get somewhere already. In that case, we only register UUID Namespace IDs and UUID Hashspace IDs for now. However, the only objection I have for hashspaces is that it is linked to UUIDv8, as I told in #144 (comment). The solution could be one of the following:

• Introduce a UUIDv9 that will take the time-based and name-based formats of UUIDv8 and leave UUIDv8 with only the vendor-specific custom format.
• Remove the time-based and name-based formats from UUIDv8 and specify UUIDv9 in another RFC.
• Leave out UUIDv8 entirely.

I don't think it will work out well if we use UUIDv8 for 3 different formats.

I don't think UUIDv9 should be in a new RFC, and UUIDv8 should stay, because I think it is a very good idea and important. It would mean that we have to do all the formal stuff again and it would be a lot of work. I don't think that it would be catastrophic if UUIDv8 has two use-cases (custom time-based and fully custom).
I have a proposal for UUIDv9, which I have put in a new issue (#147), so that this issue can continue focussing on the IANA registration part.

[mcr]

https://mailarchive.ietf.org/arch/msg/uuidrev/dhxgO66xkpNBrOtSy0AY8nV9bAE/ @sergeyprokhorenko @danielmarschall @ben221199 @LiosK @chorman0773 If this matters, then please participate.

[sergeyprokhorenko]

@danielmarschall, Please clarify your proposal taking into account the discussion that took place.

It would be terrible if we had to re-do the entire approval process of this long-awaited RFC because of frankly completely useless details regarding almost unused hash UUIDs.

@mcr, I completely agree with @LiosK's point of view and give him my vote

[sergeyprokhorenko]

I suggest to freeze the draft RFC and stop making any changes to it because it's too late and improvements could go on forever. There was a lot of time to make the discussed amendments in the previous stages of RFC development. Stakeholders will be able to propose changes to an already approved RFC

[bradleypeabody]

For what it's worth, unless there is some specific and real-world problem these hashed UUID solve (not just "what if maybe in the future" stuff), I say skip it and move on. If nobody has a use case, after all the time and effort that's been put into the drafts, doesn't seem worth fussing over.

And from a logical perspective, just to mention it as part of this: One of the reasons I tend to not put too much stock in the argument that MD5 and SHA-1 are out of date and so we should have a way to replace them - is that one of the factors that makes SHA-256 and others strong hashes is because they are longer (whereas UUIDs are fixed at 128 bits). Obviously there's more to it than that, but taking a SHA-256 value and truncating it to some smaller size and saying that it's an improvement or more collision resistant or anything because it's based on SHA-256 and not SHA-1... seems like at the very least not thoroughly researched, and at worst just flat out incorrect. Does anyone actually know the math on collisions for just the first N bits of a SHA-256 hash? Is it actually worse in terms of collision resistance than MD5 or the current SHA-1 implementation? - based on the math? (Not just the "well everyone knows MD5 is broken" - like exactly how many collisions are we talking about...)

And that conundrum is another reason I (and I think a lot of other people on this thread would agree) just go back to: Is there any practical these hash UUIDs would solve? (What specifically, with some examples showing how the work done so far on this RFC doesn't cover it...) If so, great, let's discuss that specifically in more detail. If there's no good answer to that question, then I don't see any reason we can't ignore it, and I vote let's move on and get this RFC approved.

[kyzer-davis]

I have drafted text around this under #162

[ben221199]

I reviewed #162.