**Session Date/Time:** 03 Nov 2025 19:30

# IANABIS Meeting Minutes

## Summary

The IANABIS session focused on advancing the `8126-bis` document towards Working Group Last Call, with `7120-bis` also in WGLC. Key discussions addressed the intricate use of Internet Drafts (IDs) for permanent registrations in "Specification Required" registries, the broader challenge of IANA guaranteeing document permanence, and the criteria for recognizing "Standards Organizations" for early allocations. Decisions were made to defer the document permanence issue to a separate, future effort, to adopt a flexible, existing model for "Standards Organization" approval, and to refine expert review procedures by retaining mailing lists for review/training while emphasizing individual accountability.

## Key Discussion Points

*   **Internet Drafts (IDs) for Permanent Registration (Section 4)**:
    *   Acknowledged that IETF stream IDs can receive early allocation, but permanent registration is typically not allowed unless explicitly permitted by the registry-creating working group or, in the case of a closed WG, by an Area Director (AD).
    *   Questions were raised about the necessity of standard text for working groups to permit ID-based registrations and whether to reference specific draft versions or entire "draft families."
    *   Concerns were voiced about the impermanence of IDs and the potential for their meaning to change across versions, which could lead to interoperability issues and registry inaccuracies.
    *   It was noted that current practice is to reference the specific draft version used for registration, with a proposal that registries should be updated if the meaning defined in the document changes in a later version.
    *   Discussion touched on whether IRTF Research Groups and ISE documents could also create registries allowing ID-based registrations.
    *   A strong individual opinion stated that IDs are generally unsuitable for permanent specifications and that working groups allowing their use must mandate registry updates if the document's meaning changes.
    *   The potential "hazards" of using IDs for non-early code point assignments (e.g., crypto policy) were highlighted, emphasizing that IDs are working documents, not archival.
    *   The current lack of a historical record of registrations within IANA registries was identified as a contributing factor to these problems.
    *   The TLS registry experience was cited as a case where allowing drafts increased interoperability, with the registry noting the specific draft version.
*   **IANA Guaranteeing Document Permanence**:
    *   The difficulty of IANA guaranteeing the permanence of referenced documents, even with archiving services or republication permissions, was discussed.
    *   It was suggested that this issue might be better handled as an internal IANA matter or, more significantly, as a separate IETF effort.
    *   The topic was recognized as broad, extending beyond IDs to obsolete RFCs, and potentially outside the current working group's charter.
    *   *Decision*: The working group decided to defer the issue of IANA guaranteeing document permanence to a separate, future IETF effort. The chairs will coordinate with Roman to determine the appropriate forum and timeline for this work.
*   **Criteria for Standards Organizations (SDOs) and Early Allocation**:
    *   RFC 68's practice of IESG determining SDO eligibility for media types without explicit criteria was discussed as potentially inconsistent and burdensome if applied broadly.
    *   The desire to allow early allocation for SDOs needing numbers before publication was balanced against the reluctance to create rigid SDO criteria.
    *   The existing media types registry model was highlighted: a one-time IESG approval for an "external organization" to register, without formally labeling them as a generic SDO. This model has proven effective.
    *   *Decision*: The working group adopted the existing media type approval model. The IESG will provide one-time approval for "external organizations" to register in specific registries, avoiding the need for a universal definition of an "SDO." IANA may establish a generalized registry to track such approvals.
*   **Expiration of Registrations**:
    *   A 5-year expiration date was proposed for registrations where no publication occurs, with numbers remaining reserved but eligible for deprecation/removal by experts or chairs.
    *   *Decision*: IANA will implement a process requiring notification of specification publication for early allocations and will send expiration warnings (e.g., 30 days before a 5-year expiration) for unconfirmed registrations.
*   **Expert Review Procedures and Mailing Lists**:
    *   The document's recommendation for "guidance for experts" was proposed to be strengthened from "strongly recommends" to "must."
    *   Discussion ensued about the operational challenges of expert review mailing lists (e.g., IANA forwarding requests, consistent use of ticket numbers).
    *   Concerns were raised about mailing lists creating confusion and diffusing accountability for decisions.
    *   A distinction was made between mailing lists used for collective decision-making (problematic) and those used for broader review, feedback, and training of new experts (highly valuable).
    *   *Decision*: Expert mailing lists will be retained for broader review, feedback, and training purposes. However, individual experts will remain accountable for shepherding requests and making final decisions. IANA will serve as the initial point of contact for requests, forwarding them to the relevant expert lists.
*   **Augmentation with Expert Review for IETF Stream Procedures**:
    *   A new procedure documented by Carsten and Marco for expert-augmented IETF stream procedures was presented.
    *   Consideration was given to creating a lightweight "first-come, first-serve with specification but no technical review" model for specific use cases (e.g., IDR capability code points), which would require a new, clearer name.
*   **Two-tiered Registry Concept**:
    *   A proposal for string-based registries to have different registration procedures (e.g., "IETF" approved vs. "simple") without needing prefixes was discussed. This would involve a new registry column (e.g., "regoth").
    *   *Decision*: The proposed two-tiered registry concept, as outlined in the document, was tentatively accepted as a way forward, with further detailed discussion encouraged on the mailing list.
*   **Deprecation, Obsolete, and Reserved Text**:
    *   The working group reaffirmed that "deprecation" and "obsolete" do not require further definition in the document, as they are considered plain English terms.
    *   No strong push for adding new "reserved" categories beyond private and experimental use was identified.
*   **Status Field in Registries**:
    *   It was acknowledged that a "status" field can be useful but that no single, agreed-upon set of entries exists across all registries.
    *   *Decision*: The document will note the usefulness of a "status" field and provide a few diverse examples of its application in existing registries (e.g., DNSSEC, TLS) to illustrate varying practices, rather than providing prescriptive definitions.
*   **AD Approval of Registry Notes**:
    *   The initial suggestion to require AD approval for all notes at the top of registries was challenged. It was noted that this creates additional work and that experts often post notes without AD approval.
    *   *Decision*: AD approval for notes displayed at the top of registries is not required unless specific problems arise, avoiding unnecessary overhead.

## Decisions and Action Items

*   **Decision 1 (Document Permanence)**: The issue of IANA guaranteeing document permanence will be handled as a separate, future IETF effort.
*   **Decision 2 (Standards Organization Approval)**: The approval mechanism for external organizations to register will follow the existing media type model (one-time IESG approval for specific registries).
*   **Decision 3 (Registry Expiration)**: IANA will require publication notification for early allocations and send expiration warnings (e.g., 30 days before a 5-year expiration).
*   **Decision 4 (Expert Review Mailing Lists)**: Mailing lists for broader review/feedback and expert training will be retained, with individual experts accountable for decisions. IANA will forward requests to experts.
*   **Decision 5 (Two-tiered Registry Concept)**: The proposed two-tiered registry concept for string-based registries (e.g., "IETF" vs. "simple" tiers) is tentatively accepted; further list discussion is encouraged.
*   **Decision 6 (Status Field in Registries)**: The document will acknowledge the utility of a "status" field and provide diverse examples of its use in existing registries, without prescriptive definitions.
*   **Decision 7 (AD Approval for Registry Notes)**: AD approval for notes at the top of registries is not a standing requirement unless a specific problem arises.
*   **Action Item 1**: Barry LIABer will produce new text providing guidance for experts and working groups on considering the purpose and stability requirements of their respective registries. The working group chairs will follow up.

## Next Steps

*   Barry LIABer to draft and submit the committed text for expert/working group guidance.
*   The `8126-bis` document will be revised to incorporate all decisions made during this meeting and subsequent discussions on the mailing list.
*   Further detailed discussion on the two-tiered registry concept (Decision 5) is encouraged on the mailing list.
*   The working group chairs will coordinate with Roman regarding the separate initiative on document permanence.
*   The goal is to move the `8126-bis` document into Working Group Last Call following these updates and discussions.
*   Remaining minor editorial and structural improvements to `8126-bis` will be addressed, including splitting sections for readability, clarifying URN subname space registrations, and providing boilerplate text on the IANA help page.