IANAbis IETF 122

Thursday, March 20, 2025, Session IV

Administrivia

• Murray Kuchewary and Ted Hardie introduced themselves as chairs

Charter Review

• Objectives in the charter are largely derived from items IANA has identified for improvement.
• Murray said one question that has come up is whether 7120bis in scope for the group? Seems to be covered by the charter's discussion of early allocations.
• Paul Hoffman noted the charter suggests the output of the working group to a single document. Is it OK to produce additional documents? Roman Danyliw responded that we're updating BCP 26, but it could be comprised of multiple documents. Were a little too precise in specifying the solution space in the charter. Open to having a conversation on what makes sense, up to including a recharter.
• Harald Alvestrand: Should maintenance of registrations on behalf of parties that have long since disappeared be in scope? Murray indicated that it could be since the examples are not exhaustive.
• Barry Lieba: All of those types of issues were in scope last time when RFC 8126 was written.

Changes in 8126bis

• Amanda Baber summarized draft-iana-ianabis-rfc8126bis-00.

• Some of the suggestions relate to clarifying terminology on registries, and how to handle registrations in bis documents.
• Added registry design best practices, authors aren't always aware of what's possible as they don't see the full gamut of registries
• Adding change controller field for more registries
• Questions from the group include what is an acceptable document type for "Specification Required" level? Do I-Ds count? Would levels/tiers of specifications be valuable? Should IANA snapshot specifications incase it becomes unavailable later? Are pay-to-access specifications OK?
• New registration procedures, such as FCFS with URL, multiple-tier systems
• Should there be a status field with defined states, like deprecated and obsolete with common meanings

• Amanda also summarized draft-iana-ianabis-7120bis-00:

• Extend early allocations from 1 to 2 years
• Filling in missing process information to better reflect IANA's current operating practices
• Forthcoming: Early registry creation - currently WGs track registries informally (e.g. on wikis) where assignments are needed before a registry exists, but this would provide formal support from IANA

• Susan Hares: One of the problems with "Specification Required" is if you put an accessible document, it goes to /dev/null after a while, particularly those hosted by companies. BGP registries have seen this problem. WG wants a place where there is a long term place for the document. Should IANA store? It would help.
• Susan Hares: Support 2 year early allocations, IDR often needs early allocations for 2+ years to support interoperability efforts. Is there any upper limit?

• Amanda responded some early allocations exist since 2017, no upper limit on renewals

• Susan Hares: Early registry creation - supports the concept.
• Murray: Should the working group adopt?

• No objections from the room.

Presentation of additional drafts

• John Klensin presented discussion of several issues:

• On the different roles of IANA over time, whether it is a "skilled organizer and curator" or "clerical".
• Second issue: What do we mean by "designated expert" role, 8126 talks about them as an evaluator of registration requests. But requests about registry organization etc may require different expertise and different people involved. When the IESG appoints a designated experts does it cover an expansive definition or just assessing registration requests?
• Two drafts have been proposed: draft-bormann-gendispatch-with-expert-review and draft-klensin-iana-consid-hybrid. Later derived from 5321bis experience, tension on registration procedures. Want community consensus. Want registrations that alert people to the fact that a name/number is in use to avoid conflicts, that calls for minimum registration threshold as possible; in conflict with significant reviews. Believe registries should be given a choice between FCFS or something else (high level of community input and approval).

• Barry Leiba: When an AD, saw IANA receives a lot of variability in how documents were written up. Many documents date back from a different era with different writing styles. Some include details like SLAs. We should let IANA do the things that they are good at, and lean more toward "skilled organizer and curator".

• John Klensin: Don't have a strong preference so long as we are clear about it

• Barry: There is a tension... often see Designated Expert set up with IETF Consensus documents. Have seen experts override consensus as a result. Think we should try to address this here. May want to say Standards Track document, designated expert has a say in consensus but does not control entry into the registry. IESG should pay attention to experts, but ultimately consensus has to win.
• Eric Rescorla: Less enthusiastic about the first slide. Helpful to have templates, that's fine, but strong opinions are fine too.

• John Klensin: Have worked examples where the author has given IANA a lot of discretion, and IANA has pushed back asking for more clarification.
• EKR: Then there is a question whether IANA has to apply the discretion or push back.
• Ted Hardie: A designated expert shouldn't change the structure of the registry, if the working group set the structure. It will be different for different registries. Possibly add a field on whether Designated Expert is empowered to change the structure of a registry?

• Paul Hoffman: Agree with John Klensin, but it may be problematic - it changes the way the IESG works on existing and future registries. Have seen experts overextending themselves in ways the working group didn't intend. The IESG should be able to step in, short of replacing the expert. Wary about using an IANA document to change IESG behaviour.

• Klensin: Changing IESG powers wasn't the intent
• Barry Leiba: RFC's intention was to provide guidance, not to be absolute rules that can't be varied. Bottom line is get it right, and if it is a little different then that's fine.

• Lars Eggert: Was on the IESG when the Experts were created. IESG didn't scale and needed to delegate some authority to a group of people that probably knew more about the protocols. I think we're agreeing that the IESG continues to have ultimate responsibility and can override experts if they are not working. That cannot be changed without touching 2026.
• Susan Hares: We've found in some of our registries that we needed to add information. We go through the working group, IESG, handed off to IANA. What do we do with the role of the expert who is handling the registry? Is that grandfathered in? Does it need to be restated?

• Klensin: If there are changes to the registry via the WG or IESG, this is irrelevant. The case of concern here is when the expert and/or IANA redefines fields, is it just between the expert and IANA, or the expert with full authority because they are experts, or does it need a public process?
• Susan Hares: Amanda does a good job of checking with the WG as well as the designated expert. It's been successful.
• Klensin: I have counterexamples
• Susan Hares: What's changing here?
• Klensin: If WG exists, it goes there. If the WG is gone, it becomes an IESG problem. A second option is to specify, on a per registry basis. Define how much authority expert and/or IANA has without going back to WG.

Interim meeting and next steps

• Ted Hardie: Because this is a short meeting, we might want an interim virtual meeting before Madrid.

• No objections to a virtual interim from the room.
• Klensin: Suggests 2 virtual interims
• Bob Hinden: All these questions need to be put to the list

• Send blocking dates to Ted and Murray
• Klensin asked we address the status of the additional documents
• Polling:

• "Do you support adoption of draft-iana-ianabis-rfc8126bis?"

• 25 yes, 2 no opinion

• "Do you support adoption of draft-iana-ianabis-rfc7120bis?"

• 20 yes, 7 no opinion

AOB

• Roman: Thanks for all work so far, particularly to Ted and Murray for stepping up
• Mike Jones: Do a lot of work in other organizations, ID foundation, W3C etc. Almost everything people have said assumes the change controller is the IESG. Sometimes it's another SDO, ensuring procedures work in those cases too.

• Murray: Good point, should we engage liaisons e.g. from W3C?
• That would be appropriate
• Harald Alverstrand: And ISO.

Meeting adjourned.