Universally Unique IDentifiers (UUID)
draft-ietf-uuidrev-rfc4122bis-14

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-uuidrev-rfc4122bis and RFC 9562, changed IESG state to RFC Published)

[Ballot discuss]
Hi,

Thanks for this document.  I'm particularly pleased to see that Brad has persevered with the IETF process after a somewhat negative initial reaction on the main IETF mailing list when he first raised the problem.

I've flagged one question for which I think that would may be useful for discussion, or perhaps this has already been discussed and dismissed by the WG.

(1) p 14, sec 5.1.  UUID Version 1

  UUID version 1 is a time-based UUID featuring a 60 bit timestamp
  represented by Coordinated Universal Time (UTC) as a count of 100-
  nanosecond intervals since 00:00:00.00, 15 October 1582 (the date of
  Gregorian reform to the Christian calendar).

Was there any discussion in the WG about potentially marking some of the older UUID versions as being deprecated?  Or more specifically, is it still reasonable for new implementations to choose to use some of these older UUIDs versions, or would it be better for them to default to choosing one of the newer versions?

[Ballot comment]
Minor level comments:

(2) p 14, sec 4.2.  Version Field

      Table 2: UUID variant 10x versions defined by this specification
  An example version/variant layout for UUIDv4 follows the table where
  M represents the version placement for the hexadecimal representation
  of 0x4 (0b0100) and the N represents the variant placement for one of
  the four possible hexadecimal representation of variant 10x: 0x8
  (0b1000), 0x9 (0b1001), 0xA (0b1010), 0xB (0b1011)

Table 1 only defines 3 bits and doesn't obviously mention a 4th bit, and yet the examples below are displaying 4 bits, where I assume that the 4th bit is effectively arbitrary data in the UUID definition.  Please consider whether it would be helpful to clarify this.


(3) p 16, sec 5.3.  UUID Version 3

  UUIDv3 values are created by computing an MD5 [RFC1321] hash over a
  given name space value concatenated with the desired name value after
  both have been converted to a canonical sequence of octets in network
  byte order.  This MD5 value is then used to populate all 128 bits of
  the UUID layout.  The UUID version and variant then replace the
  respective bits as defined by Section 4.2 and Section 4.1.

Presumably the MD5 is only actually used to populate 122 bits, since the other 6 are already spoken for with 'ver' and 'var'.


(4) p 29, sec 6.2.  Monotonicity and Counters

      For example, let's assume a system timestamp of 1 Jan 2023
      12:34:56.1234567.  Taking the precision greater than 1ms gives us
      a value of 0.4567, as a fraction of a millisecond.  If we wish to
      encode this as 12 bits, we can take the count of possible values
      that fit in those bits (4096, or 2 to the 12th power) and multiply
      it by our millisecond fraction value of 0.4567 and truncate the
      result to an integer, which gives an integer value of 1870.
      Expressed as hexadecimal it is 0x74E, or the binary bits
      0b011101001110.  One can then use those 12 bits as the most
      significant (left-most) portion of the random section of the UUID
      (e.g., the rand_a field in UUIDv7).  This works for any desired
      bit length that fits into a UUID, and applications can decide the
      appropriate length based on available clock precision, but for
      UUIDv7, it is limited to 12 bits at maximum to reserve sufficient
      space for random bits.

Would a valid alternative way of achieving this be to just directly write the 10 bits of the timestamp, giving 2 extra bits of randomness and a slightly cheaper calculation?

Regards,
Rob

[Ballot comment]
Thank you for the work on this document.

Many thanks to Marco Tiloca for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/wXCmWw9yLijUDNSHcZxLainEUb8/, and to the authors for addressing Marco's comments.

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.

[Ballot comment]
Thank you for the work on this document.

Many thanks to Marco Tiloca for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/wXCmWw9yLijUDNSHcZxLainEUb8/, and to the authors for addressing Marco's comments.

[Ballot comment]
Thanks again for this document and for addressing my previous blocking DISCUSS point
(see https://mailarchive.ietf.org/arch/msg/iesg/1ZxBR8Ohbz7lL2mipYTNxTtBdqU/)

-éric

# COMMENTS

## Section 1

Two sentences appear to contradict each others:

- `A UUID is 128 bits long and requires no central registration process`
- `In addition, a global registration function is being provided by the Telecommunications Standardization Bureau of ITU-T`

## Section 2

Should there be an informative reference to `IEEE 802 node identifiers` ?

## Section 2.1

What is the impact of randomised MAC address (cfr MADINAS WG and IEEE work) on bullet 4. Should this randomised MAC address be mentioned in the text ?

## Section 5.1

Why only IEEE 802.3 LAN what about 802.11 or 802.15.4 ? Should the text be relaxed ?

## Section 8

Should privacy be added in `MAC addresses pose inherent security risks ` ?

# NITS

## Section 3.3

The usual wording is more like `Note to RFC Editor: This section needs to be removed before publication as RFC`.

## Sections C.1 & C.5

Please use a documentation MAC address per section 2.1.2 of RFC 7042. *IF* the node is assumed to be a MAC address.

[Ballot comment]
Firstly, I'd like to sincerely thank Geoff Huston and the authors for working so closely to address the comments in Geoff's excellent DnsDir review - https://datatracker.ietf.org/doc/review-ietf-uuidrev-rfc4122bis-10-dnsdir-telechat-huston-2023-08-26/ I believe that this has noticeably improved the document.

Other than my thanks for the above, and for a well written document, I'd like to support Eric's DISCUSS on the length of MAC addresses.

[Ballot comment]
Thanks for working on this specification.

This specification does not raise transport related issues in my evaluation. However, for clarity in description I think Eric's discuss need to be resolved. Supporting his discuss.

[Ballot discuss]
As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion.

Why are hashspace IDs chosen to look like random uuids? Eg why not encode
"SHA2_224" (hex 534841325F323234) as 53484132-5F32-3234-0000-000000000000
or 00000000-0000-0000-5348-41325F323234 (plus or minus variant/version bits)
so that it becomes far more clear this is not an ordinary random uuid?

Similarly, why not do the same for namespace IDs? I guess that answer is
"because RFC 4122 defined it that way".

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.

[Ballot comment]
        Padding:

                When timestamp padding is required, implementations
                MUST pad the most significant bits (left-most) bits
                with zeros. An example is padding the most significant,
                left-most bits of a Unix timestamp with zeroes to fill
                out the 48 bit timestamp in UUIDv7. An alternative is to
                pad the most significant, left-most bits with the number
                of 32 bit Unix timestamp roll-overs after 2038-01-19.

How can this MUST clause have an alternative? Should it be a SHOULD? If
so, when would one use the alternative specified here?


        sharing the hashspace ID proves useful for identifying the algorithm.

It is not clear what the term "hashspace ID" refers to.

        Implementations SHOULD utilize a cryptographically secure
        pseudo-random number generator (CSPRNG) to provide values that
        are both difficult to predict ("unguessable") and have a low
        likelihood of collision ("unique").

Couldn't Verifiable Random Functions (VRF) also be used instead of a CSPRNG?

        use a message digest such as MD5 [RFC1321] or SHA-1 [FIPS180-4],
        take an arbitrary 6 bytes from the hash value, and set the
        multicast bit as described above.

While it might not matter, use of a more modern message digest algorithm is
still recommended here. One reason is that the IETF is trying to phase out
these older digests, and prefers to not reference these in new RFCs. A second
reason is that sometimes, cryptographic libraries are prevented from using
these older type of digests (eg when running in FIPS mode)

        Implementations can also leverage MAC address randomization
        techniques (IEEE 802.11bh) as an alternative to the pseudo-random
        logic provided in this section.

I'm not sure why the Section didn't lead with this more obvious approach?

NITS:

for readability, change:

        The increment value MAY be one when the number of UUIDs generated
        in a particular period of time is ...

to

        The increment value MAY be 1 when the number of UUIDs generated
        in a particular period of time is ...



        However, it SHOULD NOT be used by implementations that favor
        unguessability, as the resulting values are easily guessable.

What does "it" refer to? Incrementing by 1? Write it out instead of using "it"

[Ballot comment]
Section 6.6
  High Impact:
      A duplicate key causes an airplane to receive the wrong course
      which puts people's lives at risk.  In this scenario there is no
      margin for error.  Collisions MUST be avoided and failure is
      unacceptable.  Applications dealing with this type of scenario
      MUST employ as much collision resistance as possible within the
      given application context.

Not to trivialize the seriousness of the described scenario, but normative language around airplane design and operation doesn’t seem appropriate or in scope for the WG.  Furthermore “as much collision resistance as possible” isn’t particularly precise.  Recommend s/MUST/must/

** Section 6.9
  A generic approach, however, is
  to accumulate as many sources as possible into a buffer, use a
  message digest such as MD5 [RFC1321] or SHA-1 [FIPS180-4], take an
  arbitrary 6 bytes from the hash value, and set the multicast bit as
  described above.

RFC4112 referenced MD5 and SHA-1, but didn’t tie the implementation to them, why can’t a modern hash algorithm (SHA-256) be recommended here instead?

** Section 6.11

  UUIDs SHOULD be treated as opaque values and implementations SHOULD
  NOT examine the bits in a UUID.  However, inspectors MAY refer to
  Section 4.1 and Section 4.2 when required to determine UUID version
  and variant.

  As general guidance, we recommend not parsing UUID values
  unnecessarily, and instead treating them as opaquely as possible.
  Although application-specific concerns could of course require some
  degree of introspection (e.g., to examine the variant, version or
  perhaps the timestamp of a UUID), the advice here is to avoid this or
  other parsing unless absolutely necessary.

Why are both of these paragraphs needed?  The first seems to say the same thing as the second except with normative language.

** Section 8
Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access).

-- Why isn’t this a “MUST NOT assume”?

** Section 8
  MAC addresses pose inherent security risks and SHOULD NOT be used within a UUID.

Is there any advisory language that can be provided that could explain when a MAC address should be used?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-uuidrev-rfc4122bis-10

Thank you for the work put into this document. A very useful piece of work and do not worry too much about the DISCUSS

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Michael Richardson for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Section 5.1

Not all MAC addresses are 48-bit value (IEEE 802.15.4 has 16 or 64-bit MAC addresses). So, please recommend what to do in this situation.

[Ballot comment]

# COMMENTS

## Section 1

Two sentences appear to contradict each others:

- `A UUID is 128 bits long and requires no central registration process`
- `In addition, a global registration function is being provided by the Telecommunications Standardization Bureau of ITU-T`

## Section 2

Should there be an informative reference to `IEEE 802 node identifiers` ?

## Section 2.1

What is the impact of randomised MAC address (cfr MADINAS WG and IEEE work) on bullet 4. Should this randomised MAC address be mentioned in the text ?

## Section 5.1

Why only IEEE 802.3 LAN what about 802.11 or 802.15.4 ? Should the text be relaxed ?

## Section 8

Should privacy be added in `MAC addresses pose inherent security risks ` ?

# NITS

## Section 3.3

The usual wording is more like `Note to RFC Editor: This section needs to be removed before publication as RFC`.

## Sections C.1 & C.5

Please use a documentation MAC address per section 2.1.2 of RFC 7042. *IF* the node is assumed to be a MAC address.

[Ballot comment]
# Internet AD comments for draft-ietf-uuidrev-rfc4122bis-10
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S6.2

* "which is sorts" -> "which is sorted"?

### S6.10

* "UUIDs formats" -> "UUID formats"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-uuidrev-rfc4122bis-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-08-08):

From: The IESG
To: IETF-Announce
CC: draft-ietf-uuidrev-rfc4122bis@ietf.org, mcr+ietf@sandelman.ca, superuser@gmail.com, uuidrev-chairs@ietf.org, uuidrev@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Universally Unique IDentifiers (UUID)) to Proposed Standard


The IESG has received a request from the Revise Universally Unique Identifier
Definitions WG (uuidrev) to consider the following document: - 'Universally
Unique IDentifiers (UUID)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-08-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines the UUIDs (Universally Unique IDentifiers)
  and the UUID Uniform Resource Name (URN) namespace.  UUIDs are also
  known as GUIDs (Globally Unique IDentifiers).  A UUID is 128 bits
  long and is intended to guarantee uniqueness across space and time.
  UUIDs were originally used in the Apollo Network Computing System and
  later in the Open Software Foundation's (OSF) Distributed Computing
  Environment (DCE), and then in Microsoft Windows platforms.

  This specification is derived from the DCE specification with the
  kind permission of the OSF (now known as The Open Group).
  Information from earlier versions of the DCE specification have been
  incorporated into this document.  This document obsoletes RFC4122.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

>Document History
>Does the working group (WG) consensus represent the strong concurrence of a
>few individuals, with others being silent, or did it reach broad agreement?

The document represents a strong concurrence of a many individuals, including
many from outside the IETF community who maintain running code.

>Was there controversy about particular points, or were there decisions where
>the consensus was particularly rough?

There were many small discussions, but not big ones and consensus was not rought.

>Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

>For protocol documents, are there existing implementations of the contents of
>the document? Have a significant number of potential implementers indicated
>plans to implement? Are any existing implementations reported somewhere,
>either in the document itself (as RFC 7942 recommends) or elsewhere
>(where)?

Yes there are a number of implementators involved, and many have implemented
the changes.

>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

The ITU-T and the ISO published documents similiar to RFC4122 at the time,
but they have not responded to this BIS process.

>Describe how the document meets any required formal expert review criteria,
>such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

>If the document contains a YANG module, has the final version of the module

No YANG module.

>Describe reviews and automated checks performed to validate sections of the
>final version of the document written in a formal language, such as XML code,
>BNF rules, MIB definitions, CBOR's CDDL, etc.

None required.

>Document Shepherd Checks
>Based on the shepherd's review of the document, is it their opinion that this
>document is needed, clearly written, complete, correctly designed, and ready
>to be handed off to the responsible Area Director?

yes.

>Several IETF Areas have assembled lists of common issues that their
>reviewers encounter. For which areas have such issues been identified
>and addressed? For which does this still need to happen in subsequent
>reviews?

None relevant.

>What type of RFC publication is being requested on the IETF stream (Best
>Current Practice, Proposed Standard, Internet Standard,

Internet Standard.
This is an IETF revision of a Proposed Standard.
After the two year delay, it may be appropriate to mark it as Internet Standard.

>Have reasonable efforts been made to remind all authors of the intellectual
>property rights (IPR) disclosure obligations described in BCP 79? To
>the best of your knowledge, have all required disclosures been filed? If
>not, explain why. If yes, summarize any relevant discussion, including links
>to publicly-available messages when applicable.

yes.

>Has each author, editor, and contributor shown their willingness to be
>listed as such? If the total number of authors and editors on the front page
>is greater than five, please provide a justification.

Yes, although one previous author was unresponsive, and was removed as an author.

>Document any remaining I-D nits in this document. Simply running the idnits
>tool is not enough; please review the "Content Guidelines" on
>authors.ietf.org. (Also note that the current idnits tool generates
>some incorrect warnings; a rewrite is underway.)

Three potential downrefs have been identified.

>Should any informative references be normative or vice-versa? See the IESG
>Statement on Normative and Informative References.

Three references could be informative.

>List any normative references that are not freely available to anyone. Did
>the community have sufficient access to review any such normative
>references?

Although the IEC version of the document was not freely available, it was not used.

>Are there any normative downward references (see RFC 3967 and BCP
>97) that are not already listed in the DOWNREF registry? If so,
>list them.

None.

>Are there normative references to documents that are not ready to be
>submitted to the IESG for publication or are otherwise in an unclear state?
A>If so, what is the plan for their completion?

None.

>Will publication of this document change the status of any existing RFCs?

Just obsolete RFC4122.

>Describe the document shepherd's review of the IANA considerations section,
>especially with regard to its consistency with the body of the document.

No IANA Considerations.

Document Shepherd Write-Up for Group Documents
This version is dated 4 July 2022.

>Document History
>Does the working group (WG) consensus represent the strong concurrence of a
>few individuals, with others being silent, or did it reach broad agreement?

The document represents a strong concurrence of a many individuals, including
many from outside the IETF community who maintain running code.

>Was there controversy about particular points, or were there decisions where
>the consensus was particularly rough?

There were many small discussions, but not big ones and consensus was not rought.

>Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

>For protocol documents, are there existing implementations of the contents of
>the document? Have a significant number of potential implementers indicated
>plans to implement? Are any existing implementations reported somewhere,
>either in the document itself (as RFC 7942 recommends) or elsewhere
>(where)?

Yes there are a number of implementators involved, and many have implemented
the changes.

>Additional Reviews
>Do the contents of this document closely interact with technologies in other
>IETF working groups or external organizations, and would it therefore benefit
>from their review? Have those reviews occurred? If yes, describe which
>reviews took place.

The ITU-T and the ISO published documents similiar to RFC4122 at the time,
but they have not responded to this BIS process.

>Describe how the document meets any required formal expert review criteria,
>such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None.

>If the document contains a YANG module, has the final version of the module

No YANG module.

>Describe reviews and automated checks performed to validate sections of the
>final version of the document written in a formal language, such as XML code,
>BNF rules, MIB definitions, CBOR's CDDL, etc.

None required.

>Document Shepherd Checks
>Based on the shepherd's review of the document, is it their opinion that this
>document is needed, clearly written, complete, correctly designed, and ready
>to be handed off to the responsible Area Director?

yes.

>Several IETF Areas have assembled lists of common issues that their
>reviewers encounter. For which areas have such issues been identified
>and addressed? For which does this still need to happen in subsequent
>reviews?

None relevant.

>What type of RFC publication is being requested on the IETF stream (Best
>Current Practice, Proposed Standard, Internet Standard,

Internet Standard.
This is an IETF revision of a Proposed Standard.
After the two year delay, it may be appropriate to mark it as Internet Standard.

>Have reasonable efforts been made to remind all authors of the intellectual
>property rights (IPR) disclosure obligations described in BCP 79? To
>the best of your knowledge, have all required disclosures been filed? If
>not, explain why. If yes, summarize any relevant discussion, including links
>to publicly-available messages when applicable.

yes.

>Has each author, editor, and contributor shown their willingness to be
>listed as such? If the total number of authors and editors on the front page
>is greater than five, please provide a justification.

Yes, although one previous author was unresponsive, and was removed as an author.

>Document any remaining I-D nits in this document. Simply running the idnits
>tool is not enough; please review the "Content Guidelines" on
>authors.ietf.org. (Also note that the current idnits tool generates
>some incorrect warnings; a rewrite is underway.)

Three potential downrefs have been identified.

>Should any informative references be normative or vice-versa? See the IESG
>Statement on Normative and Informative References.

Three references could be informative.

>List any normative references that are not freely available to anyone. Did
>the community have sufficient access to review any such normative
>references?

Although the IEC version of the document was not freely available, it was not used.

>Are there any normative downward references (see RFC 3967 and BCP
>97) that are not already listed in the DOWNREF registry? If so,
>list them.

None.

>Are there normative references to documents that are not ready to be
>submitted to the IESG for publication or are otherwise in an unclear state?
A>If so, what is the plan for their completion?

None.

>Will publication of this document change the status of any existing RFCs?

Just obsolete RFC4122.

>Describe the document shepherd's review of the IANA considerations section,
>especially with regard to its consistency with the body of the document.

No IANA Considerations.