It looks good, thanks for addressing my comments!
Best,
/Marco
On 2023-08-23 16:05, Kyzer Davis
(kydavis) wrote:
*Correcting URL: https://author-tools.ietf.org/iddiff?url2=draft-ietf-uuidrev-rfc4122bis-10 -----Original Message----- From: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> Sent: Wednesday, August 23, 2023 10:04 AM To: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx>; Marco Tiloca <marco.tiloca@xxxxx>; art@xxxxxxxx Cc: draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx; uuidrev@xxxxxxxx Subject: RE: Artart last call review of draft-ietf-uuidrev-rfc4122bis-09 Marco, I have merged all of these items in Draft-10 https://author-tools.ietf.org/iddiff?url2=draft-ietf-uuidrev-rfc4122bis-10 Thanks, -----Original Message----- From: Kyzer Davis (kydavis) <kydavis@xxxxxxxxx> Sent: Tuesday, August 8, 2023 9:13 AM To: Marco Tiloca <marco.tiloca@xxxxx>; art@xxxxxxxx Cc: draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx; uuidrev@xxxxxxxx Subject: RE: Artart last call review of draft-ietf-uuidrev-rfc4122bis-09 Thank you for your review Marco, I agree will all your points and confirm your assumptions to a few questions below. Let me work on these changes. -----Original Message----- From: Marco Tiloca via Datatracker <noreply@xxxxxxxx> Sent: Tuesday, August 8, 2023 5:21 AM To: art@xxxxxxxx Cc: draft-ietf-uuidrev-rfc4122bis.all@xxxxxxxx; last-call@xxxxxxxx; uuidrev@xxxxxxxx Subject: Artart last call review of draft-ietf-uuidrev-rfc4122bis-09 Reviewer: Marco Tiloca Review result: Ready with Nits 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
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
Attachment:
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
