IETF 124 - Montreal - IANABIS
Monday November 3, 2025 14:30

Chairs: Murray Kucherawy (MK), Ted Hardie (TH)

PH = Paul Hoffman
BL = Barry Lieba
EL = Eliot Lear
PR = Pete Resnick
MSJ= Mike St.Johns
EV = Eric Vyncke
JK = John Klensin
AB = Amanda Barber

14:30 start and land acknowledgement

Administrivia (chairs) [5 min]

• chat relay
• minute-taker
• note well
• agenda bashing

14:35 Document status (Chairs) [5 mins]

• draft-baber-ianabis-rfc7120bis (in WGLC)
• draft-ietf-ianabis-rfc8126bis (WG document, WGLC after this
  meeting?)

14:36 Specification Required (Amanda) [20 mins]

• "various sub-issues" (Amanda to clarify)
• Verify consensus that I-Ds cannot be used for other than early
  allocations
• Exceptions:
  the registry-defining RFC approves this expressly
  an AD approves during Last Call for a sponsored registration
  Early Allocations (Amanda) [10 mins]

Q: should we provide text for SpecRequired, I-D allowed?
A: yes, sure.
MSJ: what would be the reference for an I-D? or a "family" (all I-D
versions)
A: It is currently a specific I-D version. This might be fixed.
TH: unsure whether family is version+later.
MSJ: 9/10 people are going to look at the last version. So a -10 that
allocates might be replaced with version -25, that changes how the code
point is used.
TH: current process is to list version.
TH proposed ACTION: "if the meaning changes, then the registry should
be updated"?
MSJ: hard enough to explain info vs std RFC, but even harder to explain
I-D versions.
AB: if they follow link in registry, then wouldn't that help?

MSJ: does Specification Required include IRTF?
AB: YES.
MSJ: does it have to be a WG adopted I-D?
TH: it's the WG that has to ask, so it would be odd to do this for a
non-adopted I-D, but it's allowed (ACTION)

BL: given Spec Required allows for random web site, which can change,
why are so worried about I-Ds?
PH: do WG chairs ask, or does this come through the AD? Considers >50%
chance that the IESG review create new I-Ds that change the behaviour
(after WGLC). ACTION.

EL/ISE: it's okay for the document to be out in the cold until the
document is passed over to RPC. (PLEASE CHECK)
EL: we are tail wagging the crypto dog, crypto (TLS) don't really want
to write an RFC for every algorithm, new mechanism. Maybe we shouldn't
change everything for just TLS.
EL suggests that WGs be discouraged from using I-D for mechanisms other
than early allocations.

Rahul Gupta: needs the history of registrations in the registries.
RS: we opened up to support I-Ds in order to enable better
interoperability, otherwise allocation of numbers is blocked by how busy
TLS-WG is. "Can't control for stupidity"

BL: maybe we need guidane for experts/WG to decide if it's stable RFC,
or if it's just for deconflicting.
ACTION Barry Lieba to write text explaining WG chairs need to consider
the purpose of the registry.

• How does IANA guarantee document permanance?

  • permission to store, but not republish...
    PH: proposes a separate document that deals with this, and will
    need much wider consensus. .. agrees that we might need to
    recharter to cover this.
    EL: IANA guaranteeing document permanance, vs IANA asks what is
    stable reference. Agrees with PH. Who is impacted if reference
    is lost.

• Verify consensus around how to handle early allocations for non-IETF
  sources, i.e., known SDOs

MK: concerned that the criteria needs to be more definite to avoid
favoritism.
PR: suggests that the IESG create their written criteria.
MSJ suggests that allocation be done (reserved), but not published until
that SDO publishes.
TH will vary by registry (so unbounded list, avoid collisions is
different than a limited size registry).
BL do not overcomplicated, it has worked well.
EV agrees, common sense.
BL are not called SDO but external entity that can approve.
JK admits to being guilty party for using SDO language. This is an
interaction. The Media-type Language is the right way. Being an SDO for
registry A might not make them valid SDO for another.

Advice to Designated Experts (Amanda) [10 mins]

• Verify consensus that the current text is what we want, especially
  going to "must" from "should"

Review new guidance for Expert Review mailing lists (Amanda) [10 mins]

• Review which things should be requirements, which things should be
  recommendations

ACTION: request should come to IANA first, not to expect list first.
RS get rid of mailing list because it difuses responsability.
TH some lists are really about consulting/review, and we need to
maintain that. (General murmur of agreement)
EL mentions some lists, and accountability (to an individual).

Kunle Olorundare: how should the documents be named (in the reference?)

EL will follow up on the FCFS-with-stable-document-reference. The "JEFF"
method.
JK is happy with basing further discussion upon what is written here.

Combinations of registration policies (Amanda) [10 mins]

• Proposed revised guidance based on feedback from Carsten, others

Updating RFCs that set registration procedures [10 mins]

Miscellaneous topics and changes since 8126 (Amanda) [30 mins]

• Examples
• Boilerplate
• Templates
• Module issues
• Updating registry notes
• References to externally managed registries (e.g., GitHub)
• Procedures for handling vanishing experts
• Which advice goes to the help page vs. what should go in 8126bis

15:30 Consensus Check on deprecated/obsolete.
BL would like deprecated/obsoleted defined.
PH disagrees, any definition is probably conflicted, so let people do
their thing and say nothing. BL is fine with that in the end.
AB we will continue to point to specific examples.
PH likes examples that disagree with eachother. Example DNS vs TLS.

AOB [10 mins]
- draft-klensin-iana-consid-hybrid?
closed at 15:59