Skip to main content

Minutes interim-2024-ietfiana-01: Wed 01:30
minutes-interim-2024-ietfiana-01-202403200130-00

Meeting Minutes IETF-IANA (ietfiana) IAB ASG
Date and time 2024-03-20 01:30
Title Minutes interim-2024-ietfiana-01: Wed 01:30
State Active
Other versions plain text
Last updated 2024-05-23

minutes-interim-2024-ietfiana-01-202403200130-00
IETF-IANA group meeting minutes (IETF 119 – Brisbane)
20 March 2024

Attendees:
Rob Wilton
Russ Housley
Jiankang Yao
Dhruv Dhody
Paul Wouters
Cullen Jennings
Tommy Pauly
Mirja Kühlewind
Lars Eggert
Roman Danyliw
Amanda Baber
Sabrina Tanamal
Kim Davies

I. Introductions/Welcome
- Welcomed new members, Dhruv, Paul, and Tommy.

II. About us
S. Tanamal - About us slide:
https://datatracker.ietf.org/iabasg/ietfiana/about/. We review performance
metrics, send performance reports, bring up issues/ask for guidance, ask for
feedback on deliverables. Occasionally schedule remote meetings.

Coverage: Kim and Russ are co-leads. Amy is Director of Ops. Amanda and Sabrina
attend IETF meetings, IESG telechat and IAB Business meeting and process
IETF-related requests. David is our backup and assist with IETF-related
requests.

III. Review of action items
1. IANA Term Usage
K. Davies - IANA term usage (background) 2016 new contractual regime introduced
intellectual property agreement that stipulates how term can be used. This is
still on our radar and revisit this as part of our 5-year strategic plan.

                2. Expert Outreach Project
Expert notes - IANA will look at writing a blog post that describes issues with
the expert review procedure. IANA can collect stats related to late reviews. We
should contact the IESG if we’re having issues with experts (for example, if
nobody from a large group picks up the token). Noted that we’ve notified all
groups of experts about our default review-handling process (act on response
from first expert unless asked to do otherwise) and given them the opportunity
to request a different approach.

L. Eggert - Seems to be a recent surge in Expert Review than FCFS lately, which
create more overhead to manage these people, but IESG could push back on this.
WGs like to define experts. M. Kühlewind - Community doesn't have any insights.
If you have any interesting finding that would be good. C. Jennings - Would it
be worth as you're reviewing the data, sending back a list of registries to the
IESG that would benefit from a new expert? L. Eggert - Most of these registries
are from a particular area, and the area needs to decide. On a high level, let
us know if there's anything we do on the IETF side that makes things difficult
for IANA. A. Baber - There's about 1000 expert review registries. L. Eggert -
If there are registries that have not received registrations in a long time,
remove the expert, send the request to the IESG. IESG can decide how to
proceed, so you don't have to ping them continuously. R. Wilton - For group of
experts have them all perform a review. A. Baber - We've contacted all of the
group and they agree to a policy, first person to respond is their review
unless they ask for help. Our issue is where there are co-experts and after
multiple pings, the co-experts don't respond. T. Pauly - Lars, you mentioned
the trend, having more FCFS than Expert Review, which trends do we see with new
registries, more toward the restrictive or less restrictive? A. Baber - We see
very few FCFS registries. We're seeing Expert Reviews tagged on to another
policy. P. Wouters - There was a discussion in the past that we shouldn't allow
Standards Track and Expert Review, I think it's gone through the WG. R. Danyliw
- Gotten feedback the other way, we want to have in addition to RFC Required.
K. Davies - Is there a place where it's a bit more complex than FCFS, where our
staff might be sufficiently skilled to make an assessment? There's some level
of analysis but the stakes aren't high enough. L. Eggert - It's a good
suggestion. We recently done something similar on erratas where the RPC decides
where it's editorial. We can do something similar here, maybe another category.
FCFS+ maybe.

IV. IANA Services Activity/Performance
·         IETF 119 Plenary Report posted at
https://www.ietf.org/about/administration/reports [ietf.org]

V. Update on Operational Activities
- Customer feedback - one negative port review.
L. Eggert - The number of surveys sent seemed low. Do you not send to all?
K. Davies - We only sent one survey every 90 days. If they send multiple
requests, they won't get multiple surveys. It's also not for every process. Not
for PEN. S. Tanamal - We don't send surveys for drafts.

VI. Update on Supplemental Agreement Deliverables
1. 2024 SLA posted at
https://www.icann.org/en/system/files/files/ietf-iana-agreement-2024-13dec23-en.pdf
2. FY25 Operating Plan and Budget

VII. Topics for Discussion
1. Subsequent phases of RFC 9120 -
K. Davies - Disentangling .arpa from the root zone -- they're still
inseparable, but 9120 posited options. We've just done phase 1 (renaming).
Phase 2 would be having different servers serving .arpa. Gets into the realm of
the political. M. Kühlewind -  What's the political issue? K. Davies -Where the
name servers are, who gets to operate. Could be answered by IAB or passed to
IANA. Right now who gets root servers is highly political. Many sensitivities
to navigate. L. Eggert: I understand the attractiveness of this ending/in
progress -- I don't think the IETF has noticed that this is pending. K. Davies:
.arpa has been posited as a solution in the past, but we didn't want to because
of entanglement w/root servers. We want to remove that as a factor. Long-term
architectural ambition -- we're not aware of short-term problems. K. Davies:
arpa is a regular zone and we could do it relatively quickly -- navigating the
sensitivities might take some time.

2. Early review of documents
M. Kühlewind: Telling authors what to do is good.
R. Danyliw: Authors going to the desk is good.

3. Expert delays:
                See discussion above under Expert Outreach Project

4. SAC113:
K. Davies: .internal was selected, public comment ends this week, nothing in
the feedback suggests reconsidering. Open question: I wanted to memorialize in
I-D that suggests the status. C. Jennings: IAB would be fastest approval.

5. SOC2:
- One of our controls was that regular OS upgrades were applied within a
certain time period, and we didn't deliver -- we didn't have an appropriate
patching strategy that worked with Kubernetes -- we don't think this was an
issue or any intrusions. Communication issues after someone left. L. Eggert:
Public-facing? K. Davies: Yes. R. Housley: Root zone management. K. Davies: It
was remedied. No remaining issues we're aware of. We're working w/ICANN to make
sure their IT staff are properly invested in our security controls. T. Pauly:
Who can see the results? R. Housley: This team. K. Davies: SOC2 limited
distribution to key stakeholders - this room -- and key leadership in the ICANN
community and RIRs. Coincidentally, next year we'll start doing a SOC3, so this
is the last year it'll be a confidential report. We'll do both, but SOC3 is
less detailed and public. T. Pauly: How often do we change the external
auditor? K. Davies: We put it out every five years. We've done KPMG, RSM, and
now RSM again.

6. Registry workflow:
- Update on our multi-year effort. We use a ticketing system w/manual
processing. We do have a support system for PEN because of volume, but we want
more. At the risk of being reductive, we want something like a datatracker.
Ongoing for a while. Initially a lot of R&D of our data structures -- lots of
inconsistency. We worked on harmonizing as much as possible.

M. Kühlewind: What were some of the changes/differences?
K. Davies: We've made editorial changes across all of the XML set.
L. Eggert: Is that a desirable feature? Concern about the consistency between
the RFC and the registries. M. Kühlewind: like having notes in registries. A.
Baber: There were labels in the XML that weren't publicly visible. Like
Specification Required but the "R" is not capitalized L. Eggert: Are these
labels internal? One way to do this is to do a document; provide more concrete
guidance M. Kühlewind: Is there a list of changes? Something to learn from it
K. Davies: I'll provide list/examples C. Jennings: People want to get JSON from
you and use it in their code. K. Davies: People want a history dump, but we'd
rather have it interactively. P. Wouters: Does it also include the workflow of
how experts and ADs communicate? Dashboard -- what things are pending for IANA.
K. Davies: Long term vision is similar to the datatracker, where you can
interact with it. R. Wilton: History tracking on what's change in the registry?
K. Davies: We have 100% of history in version control. R. Danyliw: Let me know
about having a BoF at 120. K. Davies: Not sure whether we'll be ready, but we
want input on other things.

7. RFC 7120bis
- IESG wants more time to think about this, especially early registries.
A. Baber: There seems to be a lot of possible bureaucratic issues around early
registries, but we need the IESG to weigh in.

VIII. Upcoming meeting schedule
R. Wilton: Is it worth reserving a day of the week for the IETF-IANA?
S. Tanamal: Jay suggested combining with one of the leadership meetings.
L. Eggert: The positive thing is it's hard to schedule this because it's
running so well K. Davies: We need to use you as a sounding board sometimes,
and remote doesn't work very well. L. Eggert: Maybe providing the content in
advance -- here's what we're going to talk about, there might timeliness
constraints. R. Housley: If they're coming to do a BoF at 120, we might want to
meet. R. Danyliw: BoFs tend to be a particular kind of thing; does this meet
that? L. Eggert: Maybe do a WG chair training. K. Davies: It doesn't have to be
the next IETF meeting. Seems like the right subject matter to discuss with the
community at large.

SUMMARY OF ACTION ITEMS:
              IANA – Share list of changes and examples related to the Registry
              Workflow System