Re: [Uuidrev] Last (hopefuly) comments on rfc4122bis

[[e-mail]]

Hello all,

I had the following comments when revieving the latest draft of UUIDRev:

  - Section 3.2: It seems really useless to me to list abbreviations 
about 9 times. I would suggest just "UUID" and "UUIDvX, where X is the 
UUID version (1 to 8)." or something similar.

  - Section 3.2: SHA-224, SHA-256 and SHA-512. Note the difference 
between SHA-XXX and SHA3-XXX. The first one is from the SHA2 family, and 
the last one from the SHA3 family. I would suggest to change the 
description "Secure Hash Algorithm with message digest size of 224 bits" 
to "Secure Hash Algorithm 2 with message digest size of 224 bits" (just 
adding a 2, so that it is clear it is SHA2).

  - Section 3.2: UTC is actually "Universal Time Coordinated", not 
"Coordinated Universal Time".

  - Section 4: In figure 3, the word "integer" is used. Do we talk about 
signed or unsigned here? What if the first bit of an UUID is set? Does 
it get a minus sign? If not, we should add "unsigned" to the 
description, else "signed".

  - Section 4.2: Remove unused/future UUIDs, see 
https://github.com/ietf-wg-uuidrev/rfc4122bis/pull/173.

  - Section 5.5: Suggest to change "These name-based UUIDs MUST NOT 
utilize UUIDv5 and MUST be within the UUIDv8 space defined by Section 
5.8." to "These name-based UUIDs MUST NOT utilize UUIDv5 and SHOULD be 
within the UUIDv8 space defined by Section 5.8." or use something with 
"RECOMMENDED".

- Section 5.10: At a note so that people will be remembered that 
Max/Omni UUID falls outside the specified variant. For example: "Note 
that the Max/Omni UUID falls in a range of a not yet defined variant."

- Section 6.6: Is there anything confirmed about the allocation of those 
namespace ID?

- Section 7: I see "UUID Subtypes" and "UUID Namespace ID". I don't see 
"UUID Variant" and "UUID Special Forms". Is this out of scope?

Ben

Kyzer Davis (kydavis) schreef op 2023-10-24 13:38:
> Murray,
> 
> The diff for these changes can be found below:
> 
> https://github.com/ietf-wg-uuidrev/rfc4122bis/pull/173/files?diff=split&w=1
> 
> Let me know if you see anything I should change before I reupload.
> 
> Thanks,
> 
> From: Uuidrev <[e-mail]> On Behalf Of Kyzer Davis
> (kydavis)
> Sent: Monday, October 23, 2023 1:44 PM
> To: Murray S. Kucherawy <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Uuidrev] Last (hopefuly) comments on rfc4122bis
> 
> Thanks Murray,
> 
> I have these 3 items on the tracker.
> I will iterate quickly and get this re-uploaded.
> 
> Thanks,
> 
> From: Murray S. Kucherawy <[e-mail]>
> Sent: Monday, October 23, 2023 12:33 PM
> To: Kyzer Davis (kydavis) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Uuidrev] Last (hopefuly) comments on rfc4122bis
> 
> On Mon, Oct 23, 2023 at 7:20 AM Kyzer Davis (kydavis)
> <[e-mail]> wrote:
> 
>> Thanks Murray,
>> 
>> Let me comment on a few of these I can sus out what changes are
>> needed (if any).
>> 
>>> What are the maxima for ID and Hex ID?  Are they always the same?
>> If so, do we need both?
>> 
>> I had originally included 0 through 15 (0x0 through 0xF) but I was
>> lead to remove the “Reserved for future definition” entries.
>> 
>> This table is a delta of Table 2 in this doc which does list the
>> full list of versions available.
>> 
>> As for having both: I can drop Hex column, it is a bit superfluous.
> 
> I think the registry creation needs to say explicitly that there's a
> range of valid values.  I wouldn't expect IANA to read and understand
> the entire document.
> 
>>> Are any subtypes other than "version" possible?
>> 
>>> Are any variants other than "OSF DCE / IETF" possible?
>> 
>> Yes, technically speaking there are two non-IETF variants each with
>> own subtyping mechanism (“Family” and whatever Microsoft may
>> have in use.)
>> There is a fourth, unused, variant that could at some point in the
>> future be claimed by some other standards body and feature a
>> subtyping mechanism independent of the other three.
>> 
>> I included the “subtype” > “Version” and “Variant Name”
>> columns as a method to promote some variant agnostic extendibility
>> of this registry. Thus, at some point the page could potentially be
>> updated to include “all UUID subtypes from other variants” one
>> place.
>> 
>> However, I recognize that for the purpose of this document I can
>> only register what we have defined in this spec so I scoped the
>> actual registration to only the OSF DCE / IETF variant and subtype.
>> 
>> If I need to provide some text around these last few paragraphs I
>> can do so.
> 
> If the column is free-form, it should say that.  If there's a specific
> set of valid values, they need to be enumerated and defined.
> 
>>> The bullets at the end of this section don't read clearly.  It
>> might be enough to say "On systems ..." for each of them.
>> 
>> Sure, that is an easy enough change. If I must modify anything for
>> the aforementioned topics, I can sneak this in else I am not sure a
>> whole draft-14 just for that small change is warranted.
> 
> I'd rather send this with that clarification, since these other things
> need adjustment anyway.
> 
> -MSK