**Session Date/Time:** 06 Oct 2023 15:00

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

## Summary

This interim meeting of the UUIDREV Working Group primarily focused on addressing feedback from the IESG review, particularly concerning IANA considerations for UUID Namespace IDs and the proposed registration of UUID subtypes/versions. Discussions also touched upon the existing UUID Version 8 as an illustrative example and the implications for a potential UUID Version 9. Key decisions were made regarding establishing IANA registries for Namespace IDs and UUID Version Numbers, along with their respective registration policies.

## Key Discussion Points

*   **Meeting Logistics and IETF Note Well**: The chair reviewed meeting etiquette, the note-taking tool, and the IETF Note Well policy regarding intellectual property and anti-harassment.
*   **Document Status Update**:
    *   The Working Group document (`draft-ietf-uuidrev-rfc4122bis`) has completed IESG review, which provided significant feedback.
    *   Current draft 12 is expected to lead to draft 13 after addressing feedback.
    *   The typical process after IESG review involves addressing comments, asking reviewers to update their discuss votes, and then moving to the RFC editor queue. Significant changes would reset the IESG review process.
    *   The timeline for RFC editor queue was estimated at 4-10 weeks.
*   **IANA Considerations for Namespace IDs**:
    *   Initial IESG feedback from Paul Wouters questioned the need for a registry for hash-based IDs. While hash-based IDs were removed from the normative text (now covered by V8 custom UUIDs), the discussion extended to Namespace IDs, which share similar properties regarding discoverability and consistency.
    *   Namespace IDs (e.g., for DNS, URL, OID, X.500) are 128-bit UUIDs used as input alongside names for hashing algorithms (in UUID Versions 3 and 5, and custom V8). The purpose is to "salt" the hash, ensuring `example.com` in a DNS context produces a different UUID than `example.com` in a URL context.
    *   There was discussion on whether an IANA registry is needed for these. The existing four Namespace IDs are already in implementations and libraries.
    *   Arguments for a registry included ensuring future allocations are known and disseminated, and providing a central point for understanding these well-known values. Arguments against included the limited number of existing values and the historical context of UUIDs avoiding centralized registries.
    *   The group leaned towards establishing a registry to formalize the existing values and provide a clear process for future additions, even if infrequent.
    *   **Consensus**: The sense of the room was to establish an IANA registry for Namespace IDs.
        *   **Policy**: The registration policy "Specification Required" was favored, ensuring any new Namespace ID has an accompanying document describing its use and the type of name to be associated with it. This policy includes expert review.
        *   **Action**: Normalize terminology from "namespace value" to "namespace ID" consistently throughout the document.
        *   **Action**: Add a "Specification" column to the Namespace ID table in Appendix A to reference the defining document for each ID.
*   **IANA Considerations for UUID Subtypes/Versions**:
    *   A proposal was made to create an IANA registry for UUID version numbers (0-8) to provide a central, extensible list, acknowledging that other standards bodies (ITU, ISO) also define UUIDs. The intent was to ensure consistency and discoverability of all UUID types.
    *   Concerns were raised about the IETF overstepping its scope by attempting to register or formally list UUID variants or versions defined solely by other organizations.
    *   **Consensus**: The group agreed to establish an IANA registry specifically for the *IETF-defined* UUID version numbers (0-8) to ensure extensibility within the IETF's purview.
        *   **Policy**: The registration policy "Standards Action" (requiring an RFC) was favored for version numbers, given their limited supply and significance.
        *   **Decision**: The registry for versions should *not* include the Nil and Max UUIDs, as their usage is distinct from version numbers.
        *   **Decision**: The registry for versions should *not* include a separate mechanism for registering "variants" (e.g., ITU-specific variants) to maintain focus on IETF-defined versions and avoid scope creep.
*   **UUID Version 9 Proposal**:
    *   There was a proposal from Daniel to define a UUID Version 9.
    *   The group discussed that UUID Version 8, as defined in the current document, already provides a flexible mechanism for custom, hash-based UUIDs using modern algorithms (e.g., SHA-256), serving the use case that a specific Version 9 might address. Version 8 allows implementers to specify the hash algorithm and inputs.
    *   **Consensus**: The sense of the room was that there is no immediate need or plan to define a specific UUID Version 9 in the current document. The existing Version 8 addresses the need for modern hash-based UUIDs.
*   **ITU Liaison**: It was noted that prior discussions involved liaising with ITU regarding their UUID definitions (X.667) to ensure synchronization. However, recent attempts to engage ITU on this topic have not yielded a responsive entity. The group expects ITU to notice the published RFC and potentially respond later.

## Decisions and Action Items

*   **Decision**: Establish an IANA registry for Namespace IDs in the `uuidrev` document.
    *   **Registration Policy**: "Specification Required".
    *   **Action Item**: The document editor (Kaiser) will normalize terminology from "namespace value" to "namespace ID" and ensure a "Specification" column is added to the Namespace ID table in Appendix A.
*   **Decision**: Establish an IANA registry for UUID Version Numbers (0-8) in the `uuidrev` document.
    *   **Registration Policy**: "Standards Action" (requiring an RFC).
    *   **Decision**: Nil and Max UUIDs will not be included in this registry.
    *   **Decision**: A registry for "variants" (beyond IETF version numbers) will not be created to stay within the IETF's scope.
    *   **Action Item**: The document editor (Kaiser) will update the IANA considerations section accordingly.
*   **Decision**: No immediate plans to define a specific UUID Version 9. The existing UUID Version 8 provides a mechanism for custom hash-based UUIDs.
*   **Action Item**: The Chairs will post these meeting minutes to the UUIDREV mailing list and explicitly call for consensus on these decisions.
*   **Action Item**: The Chairs will ensure ongoing liaison efforts with ITU regarding UUID version definitions are maintained as appropriate, recognizing current communication challenges.

## Next Steps

*   The document editor will incorporate the agreed-upon changes regarding IANA registries, terminology, and table updates.
*   The Chairs will initiate a mailing list discussion to confirm working group consensus on the decisions made at this interim meeting.
*   Assuming consensus on the mailing list, these changes are expected to resolve the remaining IESG review comments without requiring a new Working Group Last Call or a full reset of the IESG review process. The document will then be prepared for the RFC Editor Queue.