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

["Kyzer Davis (kydavis)" <[e-mail]>]

Ben,

On 5.5: 
I am fairly certain that a MUST in this document does not preclude a future document from making the change you specified as a doc that updates this one.

For the warning in 5.9 and 5.10:
I added a single disclaimer line to the end of both sections citing back to the variant table.
Commit: https://github.com/ietf-wg-uuidrev/rfc4122bis/commit/4a515cb3bf74953b5e3169f281a90004bbba6961

Thanks,

-----Original Message-----
From: Uuidrev <[e-mail]> On Behalf Of Ben
Sent: Thursday, October 26, 2023 2:00 PM
To: Kyzer Davis (kydavis) <kydavis=[e-mail]>
Cc: [e-mail]
Subject: Re: [Uuidrev] Last (hopefuly) comments on rfc4122bis

Hi Kyzer (and others),

Thanks for answering each comment and taking action on some. One of those answers had a new question. I will answer that one here and also want to say something about the SHULD/RECOMMENDED downgrade:

  - Section 5.5: The reason I added this point is because it isn't a MUST to use UUIDv8 if there are other UUID variants or versions that allow SHA-256. For example, some future UUIDv9 or UUIDv10. Those aren't there at this moment, so yes, now they MUST use UUIDv8 because there is no other way, but this should definitely be changed in some future RFC when
UUIDv8 isn't the only lucky one.

  - Section 5.10: I think it is important to be clear. It doesn't have to be a long text. Just some note "Take care", so that implementers know those UUIDs fall in a out-of-scope range and don't do anything stupid while making a (new) library. It isn't a big deal, just some small text.

I think if above comment is done, the RFC is able to get published. I'm only afraid for Section 6.6, so I actually hope that nobody registers any namespace ID, because I don't fully like the current idea and want to understand the history about it more, but I also don't want this issue to be stagnating the publication of the RFC. Lets do it this way, find out the history and try to change/restrict the registration policy in some next RFC. I assume "UUID Variant" and "UUID Special Forms" is a task for another RFC, seems okay to me. Let go publishing!!!

Ben

Kyzer Davis (kydavis) schreef op 2023-10-25 13:55:
> Ben, replies below lumped by section:
> 
> 3.2:
> - I was asked to add those "UUID Version #" repetitions as explicit 
> mappings. I am hesitant to change them.
> - Sure. adding a "2" is easy enough change. (Complete in PR #173 via 
> Issue #174)
> - Oddly enough the correct phrase is "Coordinated Universal Time" for 
> UTC abbreviation. (Source ITU-R TF.460-6). No change required.
> 
> 4:
> - It is unsigned, I can add this. (Complete in PR #173 via Issue #174)
> 
> 4.2:
> - I am going to leave them for this spec. The IANA registry will not 
> list them but for the spec doc I want to ensure the we list the full 
> set of versions in table.
> 
> 5.5:
> - A SHOULD/RECOMMENDED downgrade from MUST would indicate an 
> alternative which isn't specified; the assumed alternative is doing 
> what is described in the v5 space... which opens the can of worms for 
> the umpteenth time on this topic. I say we stick with a MUST here 
> based on all previous conversations on this topic.
> 
> 5.10:
> - Is this really required? I detailed this in the variant table as you 
> requested some time back. The same would go for 5.9 Nil. I don’t see 
> much benefit but if the item in Table 1 is not sufficient; I can add 
> one line to the end to state something if you really think this needs 
> a second clarification within the section.
> 
> 6.6:
> - No, we have what we have based on my analysis. Though it should be 
> sufficient; the finer details are not required.
> 
> 7:
> - Yes, it was determined in the last interim meeting to remove those 
> two you mentioned.
> 
> Thanks,
> 
> -----Original Message-----
> From: Uuidrev <[e-mail]> On Behalf Of 
> ben=[e-mail]
> Sent: Tuesday, October 24, 2023 6:10 PM
> To: [e-mail]
> Subject: Re: [Uuidrev] Last (hopefuly) comments on rfc4122bis
> 
> 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=spl
>> i
>> t&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
> 
> --
> Uuidrev mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uuidrev

--
Uuidrev mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/uuidrev