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