IANABIS

Summary

The IANABIS working group met at IETF 126 in Vienna to discuss updates on guideline and procedural drafts for IANA considerations. The session was chaired by Murray Kucherawy and Ted Hardie. Key topics discussed included the introduction of three proposed sub-policies for "Specification Required" registration procedures to combat registry squatting and specify "permanent and readily available" requirements, and status updates on draft-ietf-ianabis-rfc7120bis and draft-ietf-ianabis-rfc8126bis.

Key Discussion Points

1. Chair Administration

Slides: Chair Slides
Murray Kucherawy and Ted Hardie opened the meeting, presented the Note Well, and called for volunteers to take minutes.

2. Specification Required Sub-Policies

Presenter: Mark Nottingham
Slides: Specification Required Sub-Policies
Mark Nottingham outlined the challenges under "Specification Required" where specifications must be "permanent and readily available" and detailed enough for interoperability. Present practices make it hard for experts to judge what counts as permanent or sufficient.
To address this, along with "squatting" on high-value human-readable names (e.g., in well-known URIs), Mark proposed three parenthetical sub-policies for Specification Required:
1. Standards: Requires publication by a recognized SDO (Standardization Development Organization).
2. Community: Evaluated against expert guidelines analyzing community buy-in and implementer interest (designed for open-source projects).
3. Permissive: "Open season" requiring only that a specification exists and is retrievable.

Discussion:

Definition of "Recognized" SDOs: In the chat, Murray Kucherawy noted there is no formal definition for what qualifies as "recognized," meaning it relies on varying IESG judgment. Harald Alvestrand and Eliot Lear pointed out that the IESG keeps an active SDO registry list. Jonathan Lennox commented that having this list be semi-vibes-based by the IESG avoids it being gameable.
Expert Burden and Community Evaluation: Paul Hoffman highlighted that the "Community" sub-policy is hard to evaluate because deployment and community adoption often do not start until after a code point is assigned. He suggested adding clear criteria for experts, such as verifying if there has been active discussion in a working group.
Reference Permanence: Harald Alvestrand emphasized that reference permanence is crucial so implementations can resolve incompatibilities by checking historical specifications. (In chat, Harald added that the squatting problem was why MIME media types originally had the "standards tree"). Carsten Bormann noted in chat that reference permanence is somewhat independent of the permanence of the SDO's recognition.
The Squatting Problem: Eliot Lear suggested that the squatting problem might require specific registry guidance to expert reviewers rather than a general sub-policy change. Martin Thomson argued that legacy registries with human-readable labels are severely impacted and suggested moving entirely away from human-readable labels to numbers or opaque strings.
Reviewing the SDO List: Mike StJohns cautioned that the existing SDO list from media types might need a thorough cleanup pass before being repurposed for general registries.
Registry Feeds & WG Consultation: Susan Hares mentioned that IDR has faced issues with draft permanence over BGP's multi-decade timeline. She advocated for integrating a mechanism into the sub-policies to allow experts to formally consult working groups.
Integration Decision: Ted Hardie noted a strong consensus in the room that this concept should be incorporated into the main draft-ietf-ianabis-rfc8126bis document as sub-policies rather than as a standalone document, which will be confirmed on the mailing list.

3. IANA Status Updates

Presenter: Amanda Baber
Slides: IANA IANABIS 126

draft-ietf-ianabis-rfc7120bis (Early IANA Code Point Allocation)

Amanda Baber summarized key updates:
- Extends the term of early allocations from one to two years.
- Adds descriptions of internal IANA practices (e.g., requesting expert approval when required by the registry).
- Moves permanent allocations for First Come First Served (FCFS) or Expert Review out to a separate section.
Discussion: Eliot Lear expressed concern regarding the validity of early allocations across draft iterations. When changes occur between draft versions, developers need clear guidance on whether the existing early allocation is still valid or if a new code point is required.

draft-ietf-ianabis-rfc8126bis (Guidelines for Writing an IANA Considerations Section in RFCs)

Amanda Baber summarized key updates to Version 3:
- Authors are now requested not to suggest or recommend specific numeric values in drafts until allocated. Instead, they should use "TBD1, TBD2" or suggest ranges.
- Added text requiring guidance for experts in "RFC with Expert Review" registries.
- Reorganized registry creation and update rules into Sections 2 and 3.
Discussion on Numeric vs. Textual Suggestions:
- Martin Thomson contested making the ban on suggesting values too absolute. He noted that many protocols see significant pre-RFC deployment where suggesting a code point is beneficial, provided there is a structural system to handle collisions (like in QUIC).
- Amanda Baber agreed that exceptions should be carved out for collision-resistant protocols, and noted that numeric and textual values behave differently.
- Jonathan Lennox agreed, pointing out that preventing authors from suggesting textual names (like HTTP header fields) would be highly impractical.
RFC 2119 Keywords in IANA Considerations:
- Amanda asked if RFC 2119 keywords should be forbidden in IANA Considerations sections. Murray Kucherawy and Carsten Bormann (in chat) strongly agreed, noting that these sections bind IANA and the registrant, not protocol implementers.
Obsolete vs. Deprecated Registries:
- Section 3.3 states that "obsolete" registries are closed to new registrations. Amanda asked if "deprecated" should be defined.
- Jonathan Lennox suggested that deprecation is a protocol-level status rather than an IANA-level tag; therefore, registries do not need an explicit deprecation tag.
- Ted Hardie clarified the distinction using SSL and TLS: SSL is obsoleted (the registry is completely closed), whereas TLS 1.2 is deprecated (the registry remains open, but the designated expert raises a very high barrier to entry for any new registrations).

Decisions and Action Items

Decisions

No RFC 2119 Keywords: Agreed that RFC 2119 keywords should not be used in IANA Considerations sections.
Value Suggestions in Drafts: Agreed that authors should not suggest specific numeric values in drafts to avoid collisions (except where a collision-resistant framework exists, such as in QUIC). Textual suggestions (e.g., HTTP header field names) remain acceptable.

Action Items

Sub-Policy Integration: Chairs to confirm on the mailing list that the "Specification Required Sub-Policies" work will be integrated directly into draft-ietf-ianabis-rfc8126bis.
Draft Updates (draft-ietf-ianabis-rfc8126bis): Amanda Baber to update the text to:
- Clarify the prohibition of suggesting numeric values while allowing textual suggestions and exceptions for collision-resistant systems.
- Explicitly discourage the use of RFC 2119 keywords in IANA Considerations sections.
- Refine definitions for "obsolete", "deprecated", and "closed" registries.
Draft Updates (draft-ietf-ianabis-rfc7120bis): Address Eliot Lear’s concerns regarding tracking the validity of early allocations across different draft versions on the list.

Next Steps

The chairs will follow up on the mailing list regarding the confirmed action items.
The chairs will assess list appetite for a virtual interim meeting to make progress on the drafts prior to IETF 121 in November.

Automatic IETF Minutes