search

ietf-wg-uuidrev / rfc4122bis

revision to RFC4122
Other
57 stars 11 forks source link

Request IANA Registry #144

Closed kyzer-davis closed 1 year ago

kyzer-davis commented 1 year ago

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)
  3. UUID Namespace IDs
  4. UUID Hashspace IDs
kyzer-davis commented 1 year ago

Commenting for @ben221199 as per his vote for this under https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/83#issuecomment-1548210298

ben221199 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Do I have access to this conversation too?

mcr commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Visualized:

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

What we could setup in rfc4122bis

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

Long Term, Fully Fleshed Out and Visualized

image

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:

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 commented 1 year ago

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

It's a good idea for the future improvements of the RFC4122bis: https://github.com/uuid6/new-uuid-encoding-techniques-ietf-draft/issues/3#issuecomment-1153430817

ben221199 commented 1 year ago

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 commented 1 year ago

A few notes:

  | 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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

So, if I understand correctly, https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/144#issuecomment-1711760839 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: image

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:

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 commented 1 year ago

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 commented 1 year ago
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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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?) :

ben221199 commented 1 year ago

https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/144#issuecomment-1712522204 Yes, I also found a AF_INET version.

mcr commented 1 year ago

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

kyzer-davis commented 1 year ago

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)

Ben's Proposal

image

Minimum required to meet IESG Proposal

image

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 commented 1 year ago

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 https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/144#issuecomment-1712463318. The solution could be one of the following:

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

danielmarschall commented 1 year ago

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 https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/143#issuecomment-1709117798 ) so I think it would be super helpful if there would be a registry similar to this:

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 https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/143#issuecomment-1711804042

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 commented 1 year ago

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

sergeyprokhorenko commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I have drafted text around this under https://github.com/ietf-wg-uuidrev/rfc4122bis/pull/162

ben221199 commented 1 year ago

I reviewed #162.