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

[Ben <[e-mail]>]

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/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