List of remarks of current draft 03

[ben221199]

I have read the whole specification from top to bottom and this are my remarks with the current version of the draft:

---

1. P. Leach
   Microsoft

   I tried to contact P. Leach to talk about UUID, but his mail [email protected] doesn't work anymore, as it seems. Is he involved in the project? Else, should he be removed from the header?

---

2. This specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifiers), also known as GUIDs (Globally Unique IDentifiers).

   I would write this in another way, because the RFC is in the first place a RFC about UUIDs, not about URNs, like RFC 4122. I would write something like this:

   This specification defines the UUIDs (Universally Unique IDentifiers) and it's a Uniform Resource Name namespace. UUIDs are also known as GUIDs (Globally Unique IDentifiers).

   Also:

   The information here is meant to be a concise guide for those wishing to implement services using UUIDs, as URNs [RFC8141], or otherwise.

   To:

   The information here is meant to be a concise guide for those wishing to implement services using UUIDs, eventually in combination with URNs [RFC8141] or other.

---

3. 3 . [Snowflake] by Twitter

   Maybe worth noting that Discord uses the same technique, but with a changed start date. Not 1970, but 2015.

---

4. Make a clear difference between wire formats and representation formats, like in Section 4. In wire format we have the families/variants and versions. In the representation format we have the old Apollo Computer format, but also the hex-and-dash format, the format without dashes and the hex-and dash format with { and }. Maybe, in the near future more representation formats will be designed, but those will not conflict with the wire format and vice versa. In case of URN, only hex-and-dash is allowed. I think it is important to list all representation formats I just called and which one (the hex-and-dash one), is a recommended. Don't talk about variants, families and versions in the section about representation formats.

---

5. As mentioned in (4), I would rename Section 4 to Representation Format and create a new Section 5 with Wire format. Sections like 4.1 will now be Section 5.1, etc.

---

6. I talked about the variant field in Draft 02: Describe Nil/Max UUID in variant table #16, because at the moment it is a mess of 3 bits. In case of versions we have a clear view of what we are talking about: just 4 bits with a range from 0 to 15, of which in RFC 4122 the versions 1 to 5 were used. However, for variants this is not the case. In my issue I stated to use 8 bits, while some others proposed 4 bits. Why 8 bits? Because the legacy UUID also used 8 bits. So, in that case implementing libraries for UUIDs will become more easy to build and to understand.

---

7. Make it loud and clear that versions are ONLY a invention for the 10x variant (see how ugly I have to name my variant at the moment). I have seen implementations of UUID libraries that messed up variants and versions, because they didn't understand RFC 4122.

---

8. As such the definition of these UUIDs are outside the scope of this specification.

   I would suggest trying to define as much as possible, including UUID version 2.

---

9. 5.10. Max UUID

   I still prefer Omni UUID. 😅

---

10. For compatibility with earlier specifications, note that this document uses the unicast/multicast bit, instead of the arguably more correct local/global bit.

    Because MAC addresses with the local/global bit set or not are both possible in a network. This is not the case with the unicast/multicast bit. One node cannot have a MAC address that multicasts to multiple nodes.

---

11. 7 . IANA Considerations

    What does this mean? I understand that listing UUIDs themselves is not useful, but listing variants/families and versions would be useful for preventing conflicting implementations. In my case, I would reconsider the decision.

---

12. Implementations SHOULD NOT assume that UUIDs are hard to guess. Foe example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access). Discovery of predictability in a random number source will result in a vulnerability.

    Typo.

---

13. Tell about the Apollo variant, found here: https://opensource.apple.com/source/CF/CF-299.35/Base.subproj/uuid.c.auto.html.

---

14. Tell about the Microsoft variant, if Paul Leach is still involved.

---

Thanks for reading. I'm curious about your findings.

[kyzer-davis]

1. We decided to keep the original authors as we are re-using some of their text.
2. Yeah, that is a good suggestion.
3. I wasn't aware of Discord when I did my research a few years ago. Not sure it is worth adding extra references to that since we currently have enough to drive the point home
4. Makes sense to add the UUID layout enclosed by curly brackets if that is in use out there in modern implementations. Do you have anything to cite other than the legacy UUID usage?
5. Not sure I agree.
6. See Below.
7. Can I change the table to "The variant mapped to the versions specified in this document."?
8. See Below.
9. :)
10. I am not sure I follow what should be changed?
11. I believe the main point is we don't need an IANA listing where this document can serve as the purpose. When there are many IETF documents on a given topic; I see more value in a centralized IANA registry summarizing the disperse documents.
12. "Foe example" thanks, many have missed that one!
13. Yeah, easy enough to cite it in some way perhaps in the variant table row 1.
14. See Below

---

6, 8, 14.
I do not believe the IETF wanted this document detail every UUID in every variant space outside of variant 10x.
If there are resources we can cite them like we do for Version 2, and the new NCS one posted above.
I will defer to the WG chairs @mcr and @jimfenton since this would add significant segments of text, push back the deadlines by a significant ammount and introduce fragmented sources of information on those UUID implementations outside of IETFs span of control. Further we risk something getting out of sync assuming one of those decide to update since the RFC isn't the authoritative source of those UUID variant implementations.

Edit: Just to re-iterate my opinion: I believe that the other legacy UUIDs outside of the 10x variant should be in a historical/informational type RFC separate from this update to 4122. That is, assuming IETF has interest in compiling and detailing reference specs for those.

[ben221199]

Hello Kyzer,

Thanks for your response. My response:

1. Ok
2. Ok
3. No problem if Discord isn't added/mentioned in text, but it is always considerable if it has any added value
4. I am aware of the following representation types:
   • 550e8400-e29b-41d4-a716-446655440000
   • {550e8400-e29b-41d4-a716-446655440000}
   • 550e8400e29b41d4a716446655440000
   • 34dc23469000.0d.00.00.7c.5f.00.00.00 (Legacy format: https://www.ibm.com/docs/en/aix/7.1?topic=u-uuid-gen-command-ncs)
   • 128-bit integer (both signed and unsigned)
   • Binary (just 0 and 1)
5. It doesn't need to be exactly as I proposed, but I think it should be very clear to people that do read the RFC can quickly see that there is a wire format and a representation format and that they aren't necessary dependent on each other. The best way I can imagine is having two top-sections called Wire format and Representation format (or it could be a first level sub-section).
6. See below.
7. Are you talking about table 2? The name has enough information, but maybe you can change it to: UUID versions (as subtype for UUID variant 10x) defined by this specification
8. See below.
9. I'm serious 😂
10. There is a sentence in the specification that tells that the local/global would be more logical. However, I explain why they chose the other bit: because multicast addresses cannot exist in a network.
11. I think I don't agree on that one. For example, in DNS we have record types. Every RFC that defines a new record type will also be listed by IANA, RFC mentioned in the 4th column: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4. So, after all, you have a list of all types and the RFC they are defined in. Because of this, you will have no conflicts of using the same number. I think the same is happening with UUIDs. We have RFC 4122 that defines version 1 to version 5. The new specification will redefine those too, but will also define 3 additional versions: version 6, version 7 and version 8. This will look like the following table:
12. No problem.
13. If it is somehow mentioned, I think that is at least something. I think it is better to tell about the format, instead of referring to some vague .c file.
14. See below.

---

6. v
7. v
8. In my opinion there should at least be some RFC that describes all the UUID variants, families, versions and representation formats. If that will be this specification or some other, I don't actually care. I only care about it happening one day. However, I have the feeling that, if make a new document and don't merge the history in the current draft, the historical draft should be released first, because that one tells the basis of UUID, where this draft then is based on. Defering things to IETF is good, so we will know their view on the issue. Keep in mind that if we do publish the historical RFC afterwards, we maybe have to release another RFC in the future that merges current specification and the historical one into one, eventually adding some more variants and versions. I am okay with that too, but maybe is also more work in the end.

[kyzer-davis]

@ben221199, majority of these made it into draft 04 around version variant sub-type being for this, some other formats of note, multicast-bit, modification of the abstract.

I still left out citing legacy/historical versions except for the IBM_NCS format which was a one liner.
I think together we can easily knock those out together as historical/info RFC w/IANA ask after we get this RFC across the finish line. I will whip something up and submit it to you for you to review when I am back from traveling.

Review what I submitted to IETF under draft 04 and create a new issue if I did not address items 2, 6, 7, 10 and 12 on your list appropriately.

[ben221199]

Hi @kyzer-davis,

Thanks for making these changes. I had a look and the changes seemed good to me. Of course I will recreate a new issue when I come across some more improvements.

I saw about the IBM NCS one. I think it is nicely done, so that people will understand that there are more representation formats. Maybe we have to tell te difference between UUID and GUID too. (Yes, there is a difference. Thanks Microsoft. sigh)

If you think making a historical RFC is better than merging it into this one, lets go for it. I already started something some months ago: https://github.com/yocto/draft-yocto-uuid.

Review:

1. Fine.
2. Perfect.
3. I have some ideas about this.
4. Perfect. Maybe add something about the difference between UUID and GUID.
5. Fine. Maybe a task for historical RFC.
6. Maybe a task for historical RFC.
7. Perfect.
8. Maybe a task for historical RFC.
9. NO. 😂
10. Perfect.
11. Maybe a task for historical RFC.
12. Perfect.
13. Maybe a task for historical RFC.
14. Maybe a task for historical RFC.

Most things are handled or will eventually be handled when having a historical RFC. I will create a new issue with the remaing points and maybe some new things.