Last Call Review of draft-ietf-uuidrev-rfc4122bis-09
review-ietf-uuidrev-rfc4122bis-09-artart-lc-tiloca-2023-08-08-00

I reviewed this document as part of the Applications and Real-Time (ART) Area
Review Team's ongoing effort to review all IETF documents being processed by
the IESG. These comments were written primarily for the benefit of the ART Area
Directors. Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

[Section 2.1]

* As expanded format for UUID version, point 4 uses "Version 1 UUIDs". Later in
the document, a different expanded format is used, i.e., "UUID Version 1" in
Section 5.1.

   It would be better to consistently use a single expanded format to indicate
   the UUID version throughout the document. The format "UUID Version 1" seems
   a better choice.

   A note about the equivalence of "UUIDvX" and "Version X UUIds" can be worth
   adding in Section 3.2 "Abbreviations".

* On points 5 and 6, please have RFC 4122 as an actual reference.

* "RFC4122 did not distinguish between the requirements for generation of a
UUID versus an application that simply stores one, which are often different."

   Suggested rephrasing:

   "RFC4122 did not distinguish between the requirements for generating a UUID
   and those for simply storing one, although they are often different."

[Section 4]

* s/is 16 octets (128 bits);/is 16 octets (128 bits) in size;

[Section 5.0]

* "within bit layout consisting four octets to a row"

   I think you mean "within a bit layout consisting of four octets per row"

[Section 6.1]

* "The length of a given timestamp directly impacts how long a given UUID will
be valid. ... UUID version 1 and 6 utilize a 60 bit timestamp valid until 5623
AD and UUIDv7 features a 48 bit timestamp valid until the year 10889 AD."

   I am not sure that "valid" is the best word here, as it makes (me) think
   more about security aspects such as time-based access control rules for
   accepting a timestamp that is otherwise possible to understand and process.

   Also, let's say that a UUIDv7 is released before 10889 AD. Does the passing
   of 10889 AD per se automatically make the UUID not *valid*? I think it just
   means that no more UUIDs Version 7 can be issued from then on, right?

   I believe you actually refer to the impact on the time span during which a
   UUID can be generated. Like mentioned in the second sentence of the
   paragraph, then it boils down to how many UUIDs one can generate before the
   maximum value for the timestamp field is reached.

   Perhaps it's just better to focus on the length of the time span that the
   timestamps cover (see above).

[Section 6.5]

* "An important note for secure hashing algorithms that produce variable rate
outputs, such as those found in SHAKE, ..."

   I guess you actually mean "produce outputs of arbitrary size", right?

[Nits]

* Section 2.1
- s/is as database keys/is database keys
- s/The negative performance effects of which/The resulting negative
performance effects - s/has lead/has led

* Section 4.0
- s/Binary Figure 2/Binary (Figure 2)
- s/Integer Figure 3/Integer (Figure 3)
- s/URN Figure 4/URN (Figure 4)
- s/of Table 1/of Table 1.

* Section 4.1
- s/document bits 64/document, bits 64

* Section 5.1
- s/The 14-bits/The 14 bits
- s/clock sequence associated/the clock sequence associated

* Section 5.2
- s/such the definition/such, the definition

* Section 5.3
- s/Where possible UUIDv5/Where, possible UUIDv5

* Section 5.5
- s/As such it/As such, it

* Section 5.6
- s/where there are existing v1 UUIDs/where UUIDv1 is used
- s/With UUIDv6 the steps/With UUIDv6, the steps

* Section 5.8
- s/bits are the version and variant/bits are those of the version and variant
fields

* Section 5.10
- s/The Max UUID is special form/The Max UUID is a special form

* Section 6
- s/and up to the implementer/and it is up to the implementer

* Section 6.1
- s/Take care to ensure/Care must be taken to ensure
- s/with zeros to fill/with zeroes to fill
- s/to counter rollover/to a counter rollover

* Section 6.2
- s/unguessablity/unguessability
- s/Take care to/Care must be taken to
- s/by ensuring the total/by ensuring that the total
- s/As such the/As such, the

* Section 6.4
- s/that although this ... completeness; implementations/that, although this
... completeness, implementations

* Section 6.5
- s/select of of the/select one of the
- s/Ensure the version and variant and variant bits/ Ensure that the version
and variant bits - s/to detail SHA-256 was used to create a given UUIDv8
name-based UUID an/to detail that SHA-256 was used to create a given UUIDv8
name-based UUID, an - s/this need not be/this needs not be

* Section 6.9
- s/node ID set to one to create/node ID to 1, in order to create

* Section 12
- s/and thus maybe simpler/, which thus may make it simpler