**Session Date/Time:** 19 Jan 2023 19:00

# [UUIDREV](../wg/uuidrev.html)

## Summary

The UUIDREV Working Group held its first of two virtual interim meetings to discuss and address open Pull Requests (PRs) and issues against the draft. The primary goal for this meeting was to review and merge several PRs to prepare for the submission of `draft-ietf-uuidrev-rfc4122bis-01`. Key discussions included ABNF syntax, clarifications for UUID versions, and handling of legacy behavior. Several PRs were agreed upon for merge, contingent on minor fixes and conflict resolution. The group also discussed future work items, including a significant proposal to de-multiplex fields in the UUID structure and considerations for cryptographic hash functions.

## Key Discussion Points

*   **Meeting Logistics**:
    *   The Chairs noted this was the first of two virtual interims, with the second scheduled for February 16th. The hope is to be in Working Group Last Call by then, potentially avoiding a physical meeting at IETF 116 in Yokohama.
    *   The Note Well was reviewed, reminding participants of IPR and Code of Conduct policies.
    *   The agenda focused on reviewing open issues and pull requests, primarily for the `draft-ietf-uuidrev-rfc4122bis` document.

*   **Review of Pull Requests (PRs) and Issues**:
    *   **PR #18 (Spelling errors)**: A simple fix for mixed-case spelling errors. No objections.
    *   **PR #19 (Forward reference)**: Adds a reference to the unidentifiable section, allowing unique identifiers. No objections.
    *   **PR #20 (Move text on distributed applications)**: Relocates text about distributed applications to a more relevant section. The group agreed the text is still necessary. No objections to the move.
    *   **PR #25 (ABNF reference typo)**: Corrects an incorrect RFC number reference for ABNF. No objections.
    *   **PR #24 (ABNF Hex Formatting)**: Updates ABNF hex formatting to follow RFC 5234, specifically regarding the use of `*`. Carson raised concerns that `*` implies "zero or more", potentially leading to over-generation (e.g., 67 hex octets), suggesting that a fixed number (e.g., `4HEXOCTET`) or specific range (`4*4HEXOCTET`) might be more appropriate. Jim noted the ABNF definition is duplicated in the registration template and should be unified.
    *   **PR #27 (Change "should" to "must")**: Changes an instance of "should" to "must" where no valid exception for non-compliance was identified. No objections.
    *   **PR #29 (Remove "time-based" from V8 description)**: Removes "time-based" as a specific descriptor for UUID version 8, as V8 is now for any experimental/specific purpose, not just time-based. No objections.
    *   **PR #30 (V7 clarifications)**: Adds clarifications for UUID version 7, specifying millisecond precision and guidance for counters and randomness within the random bits. This aims to help implementers avoid common misunderstandings. No technical changes, just better upfront clarification. No objections.
    *   **PR #21 (Issue #21 - Clock Sequence and Node Clarification)**: This PR, submitted by Brad, addresses feedback regarding the generation of node and clock sequence values for UUID version 6. It clarifies that new V6 UUIDs should use a pseudo-random node and clock sequence for each generation but allows existing implementations to retain legacy behavior (e.g., fixed node, incrementing clock sequence) if they choose to do so. A sense of the room indicated this PR was ready.
    *   **PR #35 (Namespace Registration Template)**: Updates the namespace registration template, ensuring it points to correct RFCs. It was noted that the ABNF definition here duplicates the one elsewhere in the document.
    *   **PR #36 (MD5/SHA-1 Typo Fix)**: Corbin's PR to fix a typo where "MD5" was used in a SHA-1 context. Discussion ensued about potential further changes to use "SHA-1" consistently across the relevant section and whether a SHA-256 option should be considered (discussed later).
    *   **PR #37 (Jim's Grammatical Fixes)**: A PR containing a collection of grammatical and minor typo fixes. The group agreed this is a pragmatic way to handle such changes.

*   **Discussion on Jim's Email Review Points**:
    *   **`time_high_and_version` field**: Jim highlighted that multiplexing the `time_high` and `version` into a single field (as done in RFC 4122) is confusing. There was broad agreement that separating these fields into distinct descriptions, possibly with a note for continuity with prior versions, would improve clarity. This would involve some rippling changes throughout the document.
    *   **`nil` and `max` UUIDs**: Questioned if `nil` and `max` UUIDs are still relevant and if their specification location is appropriate. It was clarified that `nil` (from RFC 4122) is still important for special use cases. The addition of `max` was for completeness. The group leaned towards adding a one-liner in the variant section to clarify their special use-case nature.
    *   **SHA-256 UUIDs**: Discussion on adding SHA-256 as an alternative to SHA-1 for name-based UUIDs (Versions 3 and 5), given the deprecation status of SHA-1 in cryptographic contexts. Robert explained that namespace UUIDs (V3/V5) are a minimal use case (approx. 1%) and that the current use of SHA-1 is not for its cryptographic pre-image resistance but for its distribution properties as a non-cryptographic hash. He suggested that if someone needs SHA-256 or other hashes for application-specific UUIDs, Version 8 (experimental/vendor-specific) is the appropriate mechanism, as it doesn't overload existing version semantics or force the spec to constantly update for new hash algorithms. A sense of the room indicated that steering users toward Version 8 for such custom hash requirements was a pragmatic approach.
    *   **Acknowledgments Section**: The group discussed whether to retain all the detailed acknowledgments from RFC 4122 or simplify them. A suggestion was made to keep the names of contributors (e.g., Ted, Professor Larmouth) but remove the detailed context, as it may no longer be relevant to the updated document. Lyos K confirmed his preferred name for acknowledgments.

*   **Community Contribution Request**:
    *   Robert requested a technical review of UUID versions 3 and 5, particularly their generation descriptions, as these sections were significantly expanded and clarified in the new draft compared to RFC 4122.
    *   A check for all Errata fixes was also requested.

## Decisions and Action Items

*   **Decision**: Pull Request #21 (Node and Clock Sequence Clarification) is approved and will be merged.
*   **Decision**: Pull Request #35 (Namespace Registration Template) will be merged after Kaiser unifies the ABNF definition by referencing a single definition elsewhere in the document.
*   **Decision**: Pull Request #36 (MD5/SHA-1 Typo Fix) will be merged after Corbin updates the text to consistently reference SHA-1 where applicable.
*   **Decision**: Pull Request #37 (Jim's Grammatical Fixes) will be merged, with Kaiser resolving any merge conflicts.
*   **Action Item (Kaiser)**: Address ABNF syntax feedback from Carson for PR #24, ensuring correct ABNF grammar and avoiding over-generation. Unify ABNF definitions by referencing a single source.
*   **Action Item (Kaiser)**: Submit `draft-ietf-uuidrev-rfc4122bis-01` by the end of the week (Friday), or Monday at the latest, incorporating the merged PRs and other agreed-upon fixes.
*   **Action Item (Kaiser)**: Create separate issue trackers for the discussion points from Jim's email review (e.g., `time_high_and_version` field separation, `nil`/`max` UUID clarification, SHA-256 steering to V8).
*   **Action Item (Kaiser)**: Update the description of `time_high_and_version` to separate the time and version fields, possibly adding a note for continuity with RFC 4122.
*   **Action Item (Kaiser)**: Add a clarifying one-liner about `nil` and `max` UUIDs in the variant section.
*   **Action Item (Kaiser)**: Add verbiage to the document steering users towards Version 8 for custom hash UUIDs (e.g., using SHA-256 instead of SHA-1 for name-based UUIDs).
*   **Action Item (Kaiser)**: Refine the acknowledgments section, retaining names of previous contributors (e.g., from RFC 4122) but removing overly detailed or outdated context.
*   **Action Item (Robert and Community)**: Perform a technical review of the generation descriptions for UUID versions 3 and 5 in the new draft, particularly looking for accuracy in the net-new text.
*   **Action Item (Community)**: Review the document for any outstanding Errata fixes.

## Next Steps

*   Kaiser will prepare and submit `draft-ietf-uuidrev-rfc4122bis-01` in the coming days, incorporating the agreed-upon changes and merged PRs.
*   The Working Group will hold its second virtual interim meeting on **Thursday, February 16th, at 16:00 UTC**. A new MeetEcho URL will be provided, and an agenda posted to the mailing list.
*   The goal is to have a stable document ready for Working Group Last Call by the end of February.
*   The Chairs will gauge interest in having a meeting at IETF 116 in Yokohama, noting that many participants might attend remotely.
*   Community members are encouraged to read the new draft, review the data tracker, and provide feedback via the mailing list, especially regarding the technical accuracy of UUID v3 and v5 generation descriptions and Errata fixes.