Re: [Uuidrev] Publication has been requested for draft-ietf-uuidrev-rfc4122bis-07

Thanks for this, Kyzer, the suggested edits GitHub are super helpful.  I’ll see if I can provide any more detailed feedback as needed.

Murray, just to answer a bit more on your question:
> For instance, the first one leaves the possibility of an implementation that doesn't use an increasing clock.  Why isn't this a MUST?  The various "Care SHOULD be taken ..." ones are also curious; why would we allow for this to be a choice? 

My feedback on this is that it’s important that we don’t over-specify things that do not affect interoperability.  From my perspective, what’s happened is that in RFC 4122 there is a whole bunch of detail about how to handle various edge cases, and these then become law and impose complexity on the target environment/implementation, whether it matters or not.  In the example above, most clocks just count forward most of the time, but edge cases exist such as adjustments from NTP or manual clock adjustments.  Some applications will require careful handling of this situation, but I suspect many will not care.  If we impose an exact solution that MUST be implemented for this edge case, the result will be every implementation will have to include the complexity for that edge case in order to be a “compliant” implementation, even though it literally may not matter at all for most implementations, and certainly doesn’t matter in terms of producing an output that is acceptable to another system that needs to receive a UUID.  Same thing on counters and like - I think we want to provide implementation suggestions, but not impose too many “you absolutely must do it this way or your implementation is broken” for things that do not affect interoperability. This line of thinking is also what drives suggestions about opacity and introspection. Implementations generally interoperate much better if they don’t unnecessarily inspect UUIDs, so we suggest people don’t, and instead to just use UUIDs just as opaque identifiers.  However, it’s unreasonable to assume that no implementation will ever parse a UUID and extract a timestamp or something else, and it's not like forbidding this behavior is even helpful because people would do it anyway since it’s technically possible.  That’s why there’s a lot of suggestions about how to generate UUIDs, but fewer strict requirements, because I believe that better models how implementations are done in the real world and what aides interoperability the most.

That’s my take on it, hopefully it at least provides context.

Best, Brad

> On Jul 10, 2023, at 7:34 AM, Kyzer Davis (kydavis) <kydavis=40cisco.com@dmarc.ietf.org> wrote:
> 
> Hello Murray, replies inline, thanks for the AD review!
> 
> Section 3.2 defines "MSB" but that term doesn't appear anywhere in the document.  Same goes for "SHA-224".
> We use MSB as a header item in tables 1 and 2. Should I change them to MSB 0, MSB 1, MSB 3, etc?
>  
> Why the "SHOULD" in Section 4?
> There are a number of other ways to encode 128 bits, “hex-and-dash” is one such way. Binary is another, URN is a third. 
> I guess it doesn’t require any SHOULD/MAY/MUST verbiage? Is that the point?
>  
> GIven the opening text of Section 5.6, should UUID v1 include a forward reference to here?  My thinking is that someone implementing UUID v1 might not read all the way to this section and thus miss the hints that this version is preferred for new applications.
> Makes sense, I can add a reference back to the UUIDv1 section.
> Added as todo under https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/116 <https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/116>
>  
> Same question about 5.7 and UUID versions 1 and 6.
> Agreed, better to be consistent. Also under #116
>  
> Several of the "SHOULD"s in Section 6.1 seem questionable to me.  For instance, the first one leaves the possibility of an implementation that doesn't use an increasing clock.  Why isn't this a MUST?  The various "Care SHOULD be taken ..." ones are also curious; why would we allow for this to be a choice?  Generally below that, the "SHOULD" instances left me wondering why we leave all of these as implementation choices.  Then, in "every UUID generation SHOULD be a random integer of any desired length larger than zero", this allows a length of zero; is that okay?  And lastly, I don't know what "Implementations SHOULD weigh the consequences" or "Care SHOULD be taken" mean from an interoperability perspective.
> Focusing on the SHOULDs as they are always the one where I see problems… Let me address them all.
> Note, I was typing this reply in email. I moved it to a github issue as I know how these MUST/SHOULD/MAY discussions go
> As Such see: https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/114 <https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/114>
>  
> Thanks,
>  
> From: Uuidrev <uuidrev-bounces@ietf.org> On Behalf Of Murray S. Kucherawy
> Sent: Sunday, July 9, 2023 10:56 PM
> To: mcr+ietf@sandelman.ca
> Cc: uuidrev-chairs@ietf.org; uuidrev@ietf.org
> Subject: Re: [Uuidrev] Publication has been requested for draft-ietf-uuidrev-rfc4122bis-07
>  
> On Sat, Jun 10, 2023 at 9:45 AM Michael Richardson via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
> Michael Richardson has requested publication of draft-ietf-uuidrev-rfc4122bis-07 as Proposed Standard on behalf of the UUIDREV working group.
> 
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/ <https://datatracker.ietf.org/doc/draft-ietf-uuidrev-rfc4122bis/>
>  
> A few things as my AD Review for this document.  It looks generally good, with just some issues with the use of BCP 14 stuff.
> 
> Section 3.2 defines "MSB" but that term doesn't appear anywhere in the document.  Same goes for "SHA-224".
>  
> Why the "SHOULD" in Section 4?
>  
> GIven the opening text of Section 5.6, should UUID v1 include a forward reference to here?  My thinking is that someone implementing UUID v1 might not read all the way to this section and thus miss the hints that this version is preferred for new applications.
>  
> Same question about 5.7 and UUID versions 1 and 6.
>  
> Several of the "SHOULD"s in Section 6.1 seem questionable to me.  For instance, the first one leaves the possibility of an implementation that doesn't use an increasing clock.  Why isn't this a MUST?  The various "Care SHOULD be taken ..." ones are also curious; why would we allow for this to be a choice?  Generally below that, the "SHOULD" instances left me wondering why we leave all of these as implementation choices.  Then, in "every UUID generation SHOULD be a random integer of any desired length larger than zero", this allows a length of zero; is that okay?  And lastly, I don't know what "Implementations SHOULD weigh the consequences" or "Care SHOULD be taken" mean from an interoperability perspective.
>  
> -MSK
> -- 
> Uuidrev mailing list
> Uuidrev@ietf.org
> https://www.ietf.org/mailman/listinfo/uuidrev