Change Proposal Template

Source (Select one.)

[ ] IETF Published Draft
[x] Work in Progress Draft

Change Reason (Select all that apply.)

[ ] Typos and grammatical issues
[ ] Bad Reference
[ ] IETF Verbiage modification (MAY, MUST, SHOULD, SHOULD NOT, etc)
[x] New Text for additional context
[ ] Underlying XML Format Update
[ ] ASCII diagram updates (artwork, code samples, etc.)

Draft Number, Full Section, Name

Draft 04, 6.2. Monotonicity and Counters

Current Text:

   Fixed-Length Dedicated Counter Bits (Method 1):
      This references the practice of allocating a specific number of
      bits in the UUID layout to the sole purpose of tallying the total
      number of UUIDs created during a given UUID timestamp tick.
      Positioning of a fixed bit-length counter SHOULD be immediatly
      after the embedded timestamp.  This promotes sortability and
      allows random data generation for each counter increment.  With
      this method rand_a section of UUIDv7 MAY be utilized as fixed-
      length dedicated counter bits.  In the event more counter bits are
      required the most significant, left-most, bits of rand_b MAY be
      leveraged as additional counter bits.

   Monotonic Random (Method 2):
      With this method the random data is extended to also double as a
      counter.  This monotonic random can be thought of as a "randomly
      seeded counter" which MUST be incremented in the least significant
      position for each UUID created on a given timestamp tick.
      UUIDv7's rand_b section SHOULD be utilized with this method to
      handle batch UUID generation during a single timestamp tick.

Proposed Text:

   Fixed-Length Dedicated Counter Bits (Method 1):   
      This references the practice of allocating a specific number of 
      bits in the UUID layout to the sole purpose of tallying the 
      total number of UUIDs created during a given UUID timestamp 
      tick. Positioning of a fixed bit-length counter SHOULD be 
      immediatly after the embedded timestamp. This promotes 
      sortability and allows random data generation for each counter 
      increment. With this method rand_a section of UUIDv7 SHOULD be 
      utilized as fixed-length dedicated counter bits that are 
      incremented by one for every UUID generation. The trailing 
      random bits generated for each new UUID in rand_b can help 
      produce unguessable UUIDs. In the event more counter bits are 
      required the most significant, left-most, bits of rand_b MAY be 
      leveraged as additional counter bits.

   Monotonic Random (Method 2):
      With this method the random data is extended to also double as 
      a counter. This monotonic random can be thought of as a 
      "randomly seeded counter" which MUST be incremented in the 
      least significant position for each UUID created on a given 
      timestamp tick. UUIDv7's rand_b section SHOULD be utilized with 
      this method to handle batch UUID generation during a single 
      timestamp tick.

      The increment value for every UUID generation SHOULD be a 
      random integer of any desired length larger than zero. It 
      ensures the UUIDs retain the required level of unguessability 
      characters provided by the underlying entropy.

      The increment value MAY be 1 when the amount of UUIDs 
      generated in a particular period of time is important and 
      guessability is not an issue. However, it SHOULD NOT be used
      by implementations that favor unguessiblity, as the resulting 
      values are easily guessable.

Other Supporting information below:

If the above changes are approved, the subtopics "Plus One Increment (Type A)" and "Random Increment (Type B)" are no longer needed. The change to the exact phrasing proposed here is optional, of course.

See this comment: https://github.com/uuid6/uuid6-ietf-draft/issues/60#issuecomment-1095337577

uuid6 / uuid6-ietf-draft

Draft 04: Remove the combination of Fixed-Length Method A and Random Increment Type B #102