Draft 01: v6 clock_seq and node usage ambiguity

[LiosK]

Section 5.6 says "the 48 bit node SHOULD be set to a pseudo-random value". Which does it mean:

1. the node SHOULD be reset to a pseudo-random number every time a new UUIDv6 is generated; or,
2. the node SHOULD be initialized at a pseudo-random number only once at the system boot?

The old RFC 4122 doesn't seem clear enough, or it is rather so permissive as to accept many kinds of spatially unique identifiers. It's okay for v1 to be ambiguous; we must anyway keep it as ambiguous as it has been. Since v6 should be compatible with v1, everything should also be permitted under v6, but questions arise on which method v6 should recommend as default. We don't need to be ambiguous here.

If the first option is the way to go, the following text in Section 5.6:

The clock sequence bits remain unchanged from their usage and position in Section 5.1.

The 48 bit node SHOULD be set to a pseudo-random value however implementations MAY choose to retain the old MAC address behavior from Section 5.1 and Section 6.9. For more information on MAC address usage within UUIDs see the Section 9

can be reworded in a much simpler way as:

The clock sequence and node bits SHOULD be reset to a pseudo-random value for each new UUIDv6 generated; however, implementations MAY choose to retain the UUIDv1 behavior from Section 5.1.

because the clock sequence bits are reset to a random number when the node ID changes. Refreshing node to a random number every time is equivalent to resetting both clock_seq and node to random numbers every time. This point seems clear from Section 4.2.1 and Appendix A of the old RFC 4122.

If the latter option is recommended, the RFC should state that explicitly.

[kyzer-davis]

Good points and brings up a discussion we had on the interim meeting and during IETF 115 today on the topic of "when to initialize random" your two numbered bullets describe the two scenarios and I need to add some security considerations around usage of number 1 which can potentially exhaust random entropy sources.

I'll slate this for Draft 01 and see what verbiage I can come up with for the mailing list to sign off on.