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

[Brad Peabody <[e-mail]>]

MSK - thanks for the detailed reply and example, I’m 100% in agreement and that all makes sense.

> Hi, Kyzer are you okay with the AD review comments?
> Do we need to convene a design team meeting to deal with the comments?
> Let Jim and I know, we are here to help get this done.

I’ll let Kyzer answer on whether or not he thinks a meeting is necessary, but I suspect between this and the info collected here https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/114 <https://github.com/ietf-wg-uuidrev/rfc4122bis/issues/114> , we have what we need to make the appropriate edits.  I probably should have just provided my feedback on that GitHub issue as a Pull Request in the first place, let me see if I can just get that hammered out.

Best, Brad


> On Jul 13, 2023, at 6:03 PM, Murray S. Kucherawy <[e-mail]> wrote:
> 
> On Mon, Jul 10, 2023 at 7:56 AM Brad Peabody <[e-mail] <mailto:[e-mail]>> wrote:
> 
> My feedback on this is that it’s important that we don’t over-specify things that do not affect interoperability.
> 
> This sentence by itself means it should be MAY, or just don't use the key words at all.  The BCP 14 key words are all about interoperability; if you don't need them, don't use them.  In fact, Section 6 of RFC 2119 says in its entirety:
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    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.
> 
> Yes, it's very helpful.
> 
> Let me use this as an example:
> 
> "Implementations SHOULD use the current timestamp from a reliable source to provide values that are time-ordered and continually increasing. Care SHOULD be taken to ensure that timestamp changes from the environment or operating system are handled in a way that is consistent with implementation requirements. For example, if it is possible for the system clock to move backward due to either manual adjustment or corrections from a time synchronization protocol, implementations need to determine how to handle such cases. (See Altering, Fuzzing, or Smearing below.)"
> 
> The SHOULD here doesn't create a hard requirement.  I could flatly ignore this paragraph, arguing that I know what I'm doing, and still expect producers and consumers to interoperate most or all of the time and claim compliance with the specification.
> 
> I suggest:
> 
> Implementations MUST use the current timestamp from a reliable source to provide values that are time-ordered and continually increasing.  Care is to be taken to ensure that timestamp changes from the environment or operating system are handled in a way that is consistent with this requirement.  For example, if it is possible for the system clock to move backward due to either manual adjustment or corrections from a time synchronization protocol, implementations need to determine how to handle such cases. (See Altering, Fuzzing, or Smearing below.
> 
> Or you could even do:
> 
> Implementations acquire a current timestamp from a reliable source to provide values that are time-ordered and continually increasing.  Care is to be taken to ensure that timestamp changes from the environment or operating system are handled in a way that is consistent with this requirement.  For example, if it is possible for the system clock to move backward due to either manual adjustment or corrections from a time synchronization protocol, implementations need to determine how to handle such cases. (See Altering, Fuzzing, or Smearing below.
> 
> -MSK