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

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

Ack,

I merged draft-14 down and will resubmit on Nov 4th when the ID submissions re-open.

> The last submission time for the I-D submission was 2023-10-23 23:59 UTC.
> The I-D submission tool will be reopened after 2023-11-04 23:59 CET (IETF-meeting local time).

Thanks,

-----Original Message-----
From: Ben <ben=[e-mail]> 
Sent: Friday, October 27, 2023 3:54 PM
To: Kyzer Davis (kydavis) <[e-mail]>
Cc: Kyzer Davis (kydavis) <[e-mail]>; [e-mail]
Subject: Re: [Uuidrev] Last (hopefuly) comments on rfc4122bis

Hi Kyzer,

On 5.5: I agree, so in this RFC it will be a MUST.

On 5.9 and 5.10: Perfect.

In my opinion the RFC is now done.

Ben

Kyzer Davis (kydavis) schreef op 2023-10-27 14:49:
> 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/4a515cb3bf74953b5
> e3169f281a90004bbba6961
> 
> 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=sp
>>> l
>>> 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