Timestamp as reserve counter approach - Counter Rollover Handling

[LiosK]

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, Section 6.2. Monotonicity and Counters - Counter Rollover Handling

Current Text:

Counter rollovers SHOULD be handled by the application to avoid sorting issues. The general guidance is that applications that care about absolute monotonicity and sortability SHOULD freeze the counter and wait for the timestamp to advance which ensures monotonicity is not broken.

Proposed Text:

Counter rollovers SHOULD be handled by the application to avoid sorting issues. The general guidance is that applications that care about absolute monotonicity and sortability SHOULD freeze the counter and wait for the timestamp to advance which ensures monotonicity is not broken. Alternatively, implementations MAY increment the timestamp ahead of the actual time and reinitialize the counter if the applications can accept such timestamp alteration.

---

Other Supporting information below:

60

[LiosK]

https://github.com/uuid6/uuid6-ietf-draft/issues/60#issuecomment-1133868845

[Sofya2003]

The phrase "if the applications can accept such timestamp alteration" is superfluous.