IANA Registry and Registration

[kyzer-davis]

No description provided.

[ben221199]

I made a quick scan through your proposed changes and made comments on the things I found important in my eyes. Not every comment is a request to change, but at least subject to some debate.

[danielmarschall]

Indeed it would be very interesting to learn about the origin of the Namespace IDs. I wonder, is it possible that 6ba7b813 does not exist because a bunch of UUIDs were generated, and the CPU just had a tiny delay between the third and the fourth UUID? So, maybe they were never numbered by hand?

6ba7b810-9dad-11d1-80b4-00c04fd430c8 = 1998-02-04 22:13:53'1511824 GMT
6ba7b811-9dad-11d1-80b4-00c04fd430c8 = 1998-02-04 22:13:53'1511825 GMT
6ba7b812-9dad-11d1-80b4-00c04fd430c8 = 1998-02-04 22:13:53'1511826 GMT
6ba7b814-9dad-11d1-80b4-00c04fd430c8 = 1998-02-04 22:13:53'1511828 GMT

---

I don't think it is a good idea to have this counting upwards numbering scheme. Why don't we simplify it and just allow all UUIDs as Namespace IDs?

Contra:

• It doesn't look aesthetically "nice" when the UUIDs are not numbered nicely.

Pro:

• The document would be much simpler if we just say that any UUID can be used as a Namespace ID (IANA can still register and publish them, of course! I do like the idea of a registry very much)
• People can already use an arbitrary Namespace ID even if it is not yet registered at IANA (or is in the registration process). If we have a strict numbering, then people need to wait until IANA has confirmed that they get the requested number, otherwise if they begin implementing and don't wait for the confirmation, then there is a risk that two people (waiting for the IANA registration procedure to finish) end up using the same number.
• Maybe today someone is already using an arbitrary namespace ID in a well-known application, and they later decide that they want (or should?) publish their namespace ID to IANA, but then IANA would reject it because it does not fit the numbering scheme. But the namespace is already in use, so what to do?
• UUIDv1 is not meant to be created or edited by hand. Machine ID "00c04fd430c8" was probably a DELL machine someone (Paul Leach?) used. I think you should not create a UUID with Node ID 00c04fd430c8 because you don't own the machine, and you should not write a number (e.g. 6ba7b8xx) that does not represent the timestamp of now. It feels like you are breaking your own standard by creating UUIDv1 with a (now) false EUI48 and a (now) false time.

What do you think?

[fabiolimace]

1998-02-04 22:13:53'1511824 GMT is the date of this document: https://datatracker.ietf.org/doc/html/draft-leach-uuids-guids-01

[kyzer-davis]

@danielmarschall, some good points. But I audited many UUID implementations and I did not see many namespace IDs other than what the original had. There was a discussion post here by me on adding some others for IOT/Database etc, but it didn't get much feedback either.

I don't think it needs to be overthought and a simple auto-increment can do the job.

As noted above, I did find one library using 6ba7b813 but I was unable to surmise it's description so I said "don't use this one" and start at a different number instead: https://github.com/gitpan/UUID-Object/blob/master/t/11_as.t#L53-L64
I figure 6ba7b815 is the safest and easiest choice based on what we know.

Edit: I also wanted to avoid what happened with Hashspace ID. Specifically the IESG comments about them being somewhat unrecognizable since they are random.

[danielmarschall]

@kyzer-davis
I am a bit confused about the sentence "New Namespace IDs MUST be documented as per {{IANA}} and {{iana3}}.".
Does this mean when I am using custom namespaces for UUIDv3 and UUIDv5, I am forced to register the namespace to IANA, otherwise the UUID would be "illegal" ?
I have a few use-cases where I do have a custom namespace ID (this was the hash of "invoice number" from an ERP system), but it is very vendor-specific, so it is nothing that should be submitted to IANA.
(Of course, nobody can prevent that I am using the namespace ID. However, I am trying to make my code as "correct" as possible by following standards)

[kyzer-davis]

@danielmarschall, yeah the logic was that these NS IDs should be well documented since everybody'd in a namespace generating v3/v5 should have an idea of the correct input for the namespace so that they can all generate the same output.
Assuming you want interoperability in that sense.

If its just a vendor/implementation specific thing, do it, but don't register it with IANA.
I can put a line around this last statement but I thought it was covered by the statement up in IANA section:

Vendor-specific, application-specific, and deployment-specific values are unable to be registered.

Maybe change the NS ID section to this so its all in one spot.

New Namespace IDs MUST be documented as per {{IANA}} and {{iana3}} if they are to be globally available. Implementations MAY continue to use vendor-specific, application-specific, and deployment-specific Namespace ID values but interoperability is not guaranteed.

[danielmarschall]

@kyzer-davis Thanks for clarification. I probably missed that detail.

Ok, so do I correctly understand that there are the "standardized" namespace IDs (which are numbered and registered at IANA) and the "custom/vendor-specific" namespace IDs? This makes sense and I think that's good. But then it would be very important that vendors MUST NOT use the numbering scheme from IANA, otherwise we end up having multiple "6ba7b815" namespaces. If vendors use UUID1/4/6/7 for their custom namespaces, there is no collission.
Do you think this should be mentioned?

[kyzer-davis]

@danielmarschall, yeah, it is worth mentioning that an implementation should avoid using that space and pick something else like UUIDv4 (or UUIDv8) for a custom, implementation specific namespace ID else they should register it using the auto-increment logic (and some spec defining its usage and whatnot).
Edit: Text added in 0555e96

[danielmarschall]

@kyzer-davis Thanks for that change! But why do you limit it to UUIDv4 and UUIDv8 ? UUIDv1 (as long as node ID 00c04fd430c8 is not used), UUIDv6 and especially UUIDv7 are very important.
UUIDv8 on the other hand is rather not good for a namespace ID, since it can collide easily, e.g. if people use 00000000-0000-8000-8000-000000000000 as namespace.

[kyzer-davis]

@danielmarschall, I put RECOMMENDED which is just some steering verbiage.
One can do what you want if you don't care about interoperability with other libraries and the particular NS ID, this is just something to cover the "well then what else should I use" question vs leaving it blank/open-ended. I could add other options but sometimes too many choices is just as problematic as too few.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

I would argue that v8 is probably the best use case for some custom application NS ID value since "custom vendor-specific implementation use case" is exactly why v8 exists in the first place. So calling it out there made sense to me.

[danielmarschall]

@kyzer-davis
Sorry, but using UUIDv8 as Namespace ID in order to form a UUIDv3/5 is non-sense to me. :-) The payload-to-be-hashed is vendor-specific, and therefore the Namespace ID must be as unique as possible to avoid that the final UUIDv3/5 collides with other vendors's UUIDv3/5.

So, either use UUIDv8 directly (e.g. to include some custom numbers in it) and risk that there is a collission.

Or use UUIDv3/UUIDv5 with a unique namespace ID. But if you use a auto-inc-namespace like 00000000-0000-8000-8000-000000000000 then you are very likely to collide with other UUIDv3/UUIDv5 if the payload matches too.
If the namespace ID is unique, then the collission probability is guaranteed 1/2^122. If UUIDv8 is used as namespace, then the resulting UUIDv3/5 collission probability is much lower than 1/2^122.

---

Proposal for a different wording (it does not forbid UUIDv8 , because people can do what they want)

Proposal A (my personal preference):

These custom Namespace IDs MUST NOT use the logic above and instead use any other UUID version. If UUIDv1 is chosen, then the node id MUST NOT be "00c04fd430c8".

Proposal B (this makes advertisment for UUIDv7):

These custom Namespace IDs MUST NOT use the logic above and instead are RECOMMENDED to use UUIDv4 or UUIDv7 values as identifiers.

---

Edit: For both proposals, we need to be careful that we are talking about the Namespace IDs, not the final identifier. So these proposals would be clearer:

Proposal A (my personal preference):

These custom Namespace IDs MUST NOT use the logic above and instead use any other UUID version as Namespace ID. If UUIDv1 is chosen, then the node id MUST NOT be "00c04fd430c8".

Proposal B (this makes advertisment for UUIDv7):

These custom Namespace IDs MUST NOT use the logic above and instead are RECOMMENDED to use UUIDv4 or UUIDv7 values as Namespace identifiers.

[kyzer-davis]

@danielmarschall, the main point you are calling out is "custom, implementation specific namespace IDs". If you want maximum interoperability on a global scale I would of course suggest registering that NS ID globally so everybody is on the same page with their v3/v5 algos.
Else use whatever: v8, v4, v7. I don't think it really matters and I can change the text but the root of the argument is:
Your using a custom NS ID in your application, within your confined context. Interoperability and collision on a global scale does not sound like a need (See section 6.6 and 6.7)

A v8 NS ID fits that bill. A random UUIDv4 could work too. Sure, allocate a UUIDv7 for it. I can recommend all three. However, omitting the UUID version used for vendor-specific stuff seems weird to me when this is directly relevant to vendor-specific stuff.

I also saw your edit: Correct this is for the Namespace ID not the final name-based UUID.

[danielmarschall]

@kyzer-davis Indeed, I would be glad if you could edit the text.

I understand what you are saying.

I just want to clarify: I am not talking about my personal use-case. All I try to do is to help people reading the RFC to understand that it is crucial that Namespace IDs must be unique in any case. A unique Namespace ID prevents that UUIDv3/5 of different vendors collide. (In the case the UUIDs "meet" each other in some collection/domain/database/etc.)

The other topic you mention is interoperability. Yes, it is true that interoperability (i.e. two applications desire to output the same UUID for a given thing) is not guaranteed if people do not register the namespace ID and/or don't write a specification.

[kyzer-davis]

@danielmarschall got it, check the commit I just posted:
f92530b

[danielmarschall]

Looks good! Thank you.

[kyzer-davis]

I also posted a Question over to #161 if anybody wants to comment on that over there.

[mcr]

Daniel Marschall ***@***.***> wrote: Does this mean when I am using custom namespaces for UUIDv3 and UUIDv5, I am forced to register the namespace to IANA, otherwise the UUID would be "illegal" ? That is not the intention. Rather, if you are making a v8 namespace that you intend to use for interoperation with others, then you should consider registering a pointer to your stable document.

[kyzer-davis]

At the request of the chairs, I have posted draft-12 without the IANA changes in this PR.
Thus I have moved this proposed text to draft-13 and it is a topic for the interim meeting as there are still some discussion points and text formatting to iron out.

[danielmarschall]

I think you mean draft-13 prep, not draft-14 prep?

[kyzer-davis]

I think you mean draft-13 prep, not draft-14 prep?

Yeah, I have no idea how that got to 14.
I double-checked my command line history and everything... I cannot explain it.
I can amend the last commit message if needed but figured it wasn't that big a deal.

History for those curious, it had to have append when I did the --amend command...

  490  cd rfc4122bis/
  491  git branch -f iana-registratoin origin/iana-registration
  492  git checkout iana-registration
  493  git diff
  494  git add .
  495  git commit "draft-13 prep"
  496  git commit -m "draft-13 prep"
  497  git config --global user.name "Kyzer Davis"
  498  git config --global user.email [email protected]
  499  git commit --amend --reset-author
  500  git push origin iana-registration