Draft 03: Include random counter seeding pro/con

[kyzer-davis]

Change Proposal Template

Source (Select one.)

• IETF Published Draft
• 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)
• New Text for additional context
• Underlying XML Format Update
• ASCII diagram updates (artwork, code samples, etc.)

Draft Number, Full Section, Name

Draft 03, Section 5.2.  Monotonicity and Counters

Current Text:

Fixed-Length Dedicated Counter Seeding:
  Implementations utilizing fixed-length counter bits SHOULD initialize the counter at zero to ensure the full bit-space is utilized and help avoid counter rollovers.

Proposed Text:

Fixed-Length Dedicated Counter Seeding:
 Implementations utilizing either fixed-length counter method MAY randomly initialize the counter with each new timestamp tick. However, when the timestamp has not incremented; the counter SHOULD be frozen and incremented by one.
 When utilizing a randomly seeded counter alongside Method 1; the random MAY be regenerated with each counter increment without impacting storability. The downside is that Method 1 is prone to overflows if a counter of adequate length is not selected or the random data generated leaves little room for the required number of increments.
 A randomly seeded counter alongside Method 2 is more-or-less the same as Monotonic Random (Method 3).
 Implementations utilizing either fixed-length counter method MAY also choose to initialize the counter at zero to ensure the full bit-space is utilized and help avoid counter rollovers. This approach has less entropy and more guessibility but ensures the most of the counter bit space.

---

Other Supporting information below:

From #60