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

["Murray S. Kucherawy" <[e-mail]>]

On Mon, Jul 10, 2023 at 7:56 AM Brad Peabody <[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