INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2024-06-13 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Jenny Bui (AMS) / IETF Secretariat Deb Cooley / Security Area Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat Sandy Ginoza (AMS) / RFC Editor Liaison Jim Guichard (Futurewei Technologies) / Routing Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Web and Internet Transport Area Tommy Pauly (Apple) / IAB Chair Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area David Schinazi (Google) / IAB Liaison Orie Steele (Transmute) / Applications and Real-Time Area Sabrina Tanamal (ICANN) / IANA Liaison Gunter Van de Velde (Nokia) / Routing Area Éric Vyncke (Cisco) / Internet Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Mahesh Jethanandani (Arrcus) / Operations and Management Area Warren Kumari (Google) / Operations and Management Area John Scudder (Juniper) / Routing Area OBSERVERS --------------------------------- Dave Thaler David Vernet Greg Wood 1.2 Bash the agenda Liz: Does anyone have anything new to add to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Liz: Does anyone have an objection to the minutes of the May 30 teleconference being approved? I'm not hearing any objections, so those are approved and we'll post those in the public archive. Does anyone have an objection to the narrative minutes of the May 30 teleconference being approved? I'm not hearing any objections, so those are approved and we'll post those in the public archive. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Orie Steele to find designated experts for RFC 9553 (JSContact registries)[IANA #1364749] Liz: We have a management item at the end of the agenda to approve some experts here, so this one is provisionally done. * OPEN ACTION ITEMS o Roman Danyliw and Warren Kumari to 1) draft a revision of RFC 4858, 2) draft a revised IESG Statement on Document Shepherds (original statement October 2010), and 3) update the WG Chairs wiki to point to the new IESG Statement. Liz: Last time you mentioned wanting to work on this at the retreat, is that still the case? We'll mark this in progress. o Paul Wouters to open up an issue with the Tools Team asking for IANA to be notified about document state changes. o Paul Wouters to write a proposal for handling IANA review mailing lists. Paul: Both of these are in progress. o All IESG to review Non-WG List Review spreadsheet and note which lists may be ready for closure and any needed AD Actions. Éric V: There are still a lot of lists which are unassigned to any ADs for review. What do we do there? Francesca: That no one has self-assigned, let's say. I've gone through the list and I picked the ones I thought I could do something about. From my side I'm done. Éric V: I'm the same as you. Roman: I can take a crack at making some assignments. Francesca: I'm okay with getting more assigned to me, I just didn't think they belonged in WIT. Maybe we can note in the spreadsheet those of us who have done a round and think they are done. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-mpls-spring-inter-domain-oam-17 - IETF stream Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Segment Routing Networks (Proposed Standard) Token: Jim Guichard Liz: We have a couple of Discusses here; do we need to discuss these now? Jim: I don't think so. I haven't seen any responses to these yet and the authors are a little slow. I think this will definitely require a revised I-D, so unless Gunter or John have anything I'm happy to move on. Gunter: No, I haven't heard anything from the authors. Liz: Okay, so this one is staying in IESG Evaluation::Revised I-D Needed. o draft-ietf-tsvwg-sctp-zero-checksum-10 - IETF stream Zero Checksum for the Stream Control Transmission Protocol (Proposed Standard) Token: Zaheduzzaman Sarker Liz: We have a couple of Discusses here; do we want to discuss these now? Deb: The author has reached out to me and we have an agreement on a way forward, so as soon as he posts his new version I'll clear my Discuss. Zahed: Thanks for that Deb, it was pretty quick to resolve that one. When I read the discussion I thought there might be a misunderstanding but I see there was a resolution. Thanks for the review. We have one more from Paul; you wanted something about what if DTLS fails? Paul: I'm sure they'll come up with a sentence or two. Just to make sure it doesn't bid-down attack. Zahed: That's a good point you raised and I think that will be very easy to solve. Let's wait for Michael. I think I have the idea and we'll need a revised I-D. Liz: Okay, so this one is staying in IESG Evaluation::Revised I-D Needed. o draft-ietf-teas-actn-vn-yang-28 - IETF stream A YANG Data Model for Virtual Network (VN) Operations (Proposed Standard) Token: Jim Guichard Liz: We don't have any Discusses in the tracker, so unless there's an objection now, this one is approved. Jim: Can you put this in Revised I-D Needed? Mahesh has an outstanding comment I want to make sure is addressed. I spoke to Dhruv this morning and that needs to happen before we move it forward. Deb: Is there, or was there, a plan to review the template of security considerations for Yang module documents? Paul: I think Rob wanted to start something, but then I guess he ran out of time. Éric V: Indeed. Jim: I never heard anything concrete on that. Deb: The template isn't very….when I read it I thought what is this? Paul: Talk to Rob Wilton, the previous AD. He wanted to start some effort to update that boilerplate. Deb: Maybe to make it actually look like security considerations? Paul: Yes. Deb: I'm happy to help, but I don't think I should be initiating. Roman: He's someone who has a ton of history to try to push on that template. I know he had some ideas but I'm not sure where they landed. For the record, I think the Yang authors collectively have benefited from having some template to follow and it's helped move documents along. Deb: Sure, and once we understand that their security considerations aren't going to look like security considerations, we can move along. I'm happy to reach out to Rob if you think I should. Roman: I think it's a good idea. I can't remember exactly what his ideas were. Deb: I'll put it on my list. Liz: Okay, so for this document I've got Approved, Announcement to be Sent:: Revised I-D Needed. Francesca: Before we move on, I had a comment about references. I was suggesting some references should be normative instead of informative. They are informational documents so they would be downref-ed, and they were not in the Last Call. So I think the IESG should approve that. If this change is done, which I'm not sure if it's going to be done. Dhruv has replied to my comment and said, if I understand correctly, that there is precedent for having these as informative references but they're happy to follow the IESG's direction. I just want to make sure that if this change gets done that we approve this even though the downrefs were not in the Last Call. Éric V: So you hope to make the change to normative? Francesca: Yes. In my opinion these references should have been normative, and if the authors and WG agree, then they have not been Last Called as downrefs and I hope the IESG can approve it today so there's no delay and no process issue. Éric V: So we are approving a potential change in the draft? Francesca: Exactly. Éric V: Do you remember which section? Francesca: These are used in the terminology. Éric V: Section 1.1, yeah. I'm reviewing it. Francesca: Especially 8453. Éric V: I think you're right. THey don't provide any definitions of those terms. Francesca: Exactly. As I said in my comment, either you extract these terms and record them in this document, and that's fine if it's kept as informative. Éric V: I would say good catch of yours. Roman: Yes, good catch. Francesca: I didn't want to block the document because it's terminology. Liz: We can make a note that if RFCs 7926, 8309, and 8453 are moved to normative references, then the IESG approves them as downrefs. Francesca: 2 of the 3 are informational; I don't remember which of the three is not. Is there any objection to approving those as downrefs? Éric V: Or easier to just add the definition in the text. Roman: If Dhruv has already said that in principle they would agree to move them to normative, I think we should just conditionally approve it the way you just said, instead of trying to suggest further text changes. Francesca: I'm fine either way. And I don't hear any objections. Jim: Is Dhruv aware of what they need to do now? I'm a little confused myself, but if they know what they need to do, then I'm fine. I'll wait to see that happen. Francesca: They said they were happy to follow the IESG direction on this. For me it's very simple, move these references to normative. Jim: All 3 of those RFCs, or just 8453? Francesca: I'd move all three of them, but if you have to pick, then especially 8453. Given that the IESG has no objection to approving these downrefs, it's simple. Deb: Isn't it just simpler to ask Dhruv to move all three to normative? Jim: That's what I'll do. Francesca: Okay, then we are all agreed. Sorry for taking up so much time. Roman: No, this is good. As an aside, for the new ADs, if you have an informational document you're citing from a PS normatively, you'd call that out in Last Call. If something happened, we're changing the nature of the reference and upgrading it from informative to normative, we now have the PS invoking an informational that should have been in the Last Call. The IESG has a procedure to say that's okay without having to re-Last Call the document. That's why Francesca is being so deliberate on that process. Deb: Thanks, I didn't understand. Francesca: It also happens sometimes that the downrefs are not in the Last Call; it has happened a couple of times, and some AD notices and we discuss it just to make sure that everybody knows. Orie: Thanks for the reminder on that. When I was reading the IPN document I had a similar question about the relationship between the new PS and the informational document, so when you get to your review for that maybe consider all of this. Erik K: I think that's a slightly separate case, because the previous documents came out of DTNRG, which only produced informational documents. Jim: One clarification; if Dhruv moves those RFCs to normative, I don't need to run a Last Call again, do I? Francesca: Right. You don't need to run a Last Call because we have just now approved them as downrefs. Otherwise, yes you would have had to run another Last Call. Jim: Okay. Thank you. Liz: Thanks everyone, and thanks Francesca for making our lives easier because I'm sure we would have had a question about that later. o draft-ietf-bpf-isa-03 - IETF stream BPF Instruction Set Architecture (ISA) (Proposed Standard) Token: Erik Kline Liz: We have a Discuss; do we want to discuss this now? Roman: I want to discuss it. Murray, I don't know whether talking about a shepherd's writeup is a Discussable thing; shepherd writeups are optional. Murray: The issue is not the writeup; it's to highlight that the shepherd writeup also got this wrong. 8126 for a specification required registry says there is a designated expert and this document needs to provide advice for that expert, and that's missing. Not only is that missing, the shepherd writeup also incorrectly claimed that this blah blah blah. Erik K: I missed that in the shepherd writeup, that's my fault. I just fixed the writeup. But I thought there was text about what to advise. Murray: I searched for words like "expert" and thought maybe it was in another section. I think this was just an oversight, it should be easy to fix. Erik K: Dave Thaler is on the call; Dave, do you want to jump in? I thought I had read some text to this effect. Dave Thaler: Thanks Erik. David Vernet is also on the call, who's the WG chair. This document is documenting existing practice, not specifying anything new. There are already experts in place, they're just not designated experts on behalf of the IESG at this point. The intent is that the recommended DEs are the existing experts that have been reviewing these in the Linux repository all along. If the IESG picks them, then they don't need specific guidance. However, I do take the point that the document should contain what they do right now, so in perpetuity that information that the DEs look for is in the document. It's really easy to put that in, and just say here's what the DEs right now look for. It's not new practice, just documenting existing practice. I can add a paragraph or a couple of sentences about that. Murray: Yes please, because one of the problems I've been battling with the last couple of years is that we've done a poor job of longevity planning; who takes this over when that current set of DEs is gone? On top of that, I don't have any of the context you're talking about. I'm looking at 7.1 right now and the fact that this is essentially codifying an existing registry somewhere that has DEs is also missing from this. Dave: That's in the WG charter. Murray: Okay. I think you've already offered me what I think would fix this. Erik K: That makes sense. Thank you. I think the rest of the comments look like things that Dave just needs to noodle on and reply to. Dave: The rest are pretty easy editorial things. Happy to take those suggestions; thanks, all. Erik K: Thanks everyone for reviewing. Liz: This document is staying in IESG Evaluation, and it sounds like we'll need a Revised I-D. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-rift-applicability-15 - IETF stream RIFT Applicability (Informational) Token: Jim Guichard Liz: We have the Consensus as Unknown, so we'll set that to Yes for you. There are no Discusses in the tracker, so unless there's an objection now, this one is approved. Jim: Revised I-D Needed, please. Eric has an outstanding comment and I want to make sure that's addressed. Liz: This one is Approved::Revised I-D Needed. o draft-ietf-teas-enhanced-vpn-19 - IETF stream A Framework for Network Resource Partition (NRP) based Enhanced Virtual Private Networks (Informational) Token: Jim Guichard Liz: We have the Consensus as Unknown, so we'll set that to Yes for you. There are no Discusses in the tracker, so unless there's an objection now, this one is approved. Paul: No objection, but I did want to point out the item about IETF network slices that we had a large discussion about a year ago, that there was confusion about the term network slicing and rather than come up with another term, they compromised on "IETF network slicing" and this document says 'whenever we say network slices we mean IETF network slices' so it kind of defeats the whole purpose of what we tried to do last year. I don't think there's a solution to this but I wanted to bring it up. I hope we don't see more of these aliases. Liz: This one is approved; Jim, is this ready to go? Jim: Let's put it in AD Followup. I think the comments were addressed but I just want to make sure. Liz: Okay, this one is Approved::AD Followup and you can let us know when it's ready. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items NONE 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review NONE 4.1.2 Proposed for approval o Secure Patterns for Internet CrEdentials (spice) Liz: This is in the SEC area, and Paul is the AD. There are no blocking comments, so I think this is ready to be approved. Are there any objections? Paul: Excellent. This was a long, slow path and thanks again to Roman who did 85% of the work on this. Liz: Paul, is this ready to go as-is, or do you want to do anything else to the charter? Paul: Do it! Liz: Great, so this is approved and ready to go and we'll send those announcements. o SRv6 Operations (srv6ops) Liz: This is in the OPS area with Jim as AD. We do have one blocking comment; do we want to discuss this now? Jim: Yes please. Roman, I think the last email I saw from you suggested you were going to remove the block, but obviously you haven't. I'm not sure if there's anything left here. Roman: I believe there was a PR against the charter text that Dhruv had proposed. Jim: I need to do that, I guess. They've got it on Github. Roman: I'm a clear after merge kind of person. Jim: Okay; I'll get that done today. Liz: Okay, so we'll leave this where it is for now and then once that block is cleared you can let us know when it's ready. Jim: I'll update it and ping Roman once I've done it. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval o A Semantic Definition Format for Data and Interactions of Things (asdf) Liz: This is a recharter in the ART area, and Francesca is AD. This has a block as well; do we need to discuss this now? Francesca: I don't think we need to. I saw traffic happening in the mailing list. We just need to do some updates and respond to the comments. Thank you everyone for the reviews. Liz: So we'll leave this one where it is and Francesca, you can keep working on it. Paul: While we are talking about charters, I noticed that in the charter for EMU we previously approved, there's an RFC number typo. Is there a way I can fix that without rechartering? Cindy: For a very obvious typo, I don't remember if we can make the change or if we need to get the tools team to make the change. But there is precedent for just fixing a typo; you can send it to us. 5. IAB news we can use Roman: We may want to revisit this during the retreat agenda, but the IAB is thinking about having a workshop around network management and we should decide how much or how little we want to coordinate with that. David: I don't have any further news to report. Erik K: Can I ask what network management means? Roman: I'd have to find the source document. I think it's rethinking the future of network management? I can pull out the collateral in prep for a future conversation. Cindy says it's the "Next Era of Network Management Operations;" I don't know if that helps. 6. Management issues 6.1 IETF 120 BOFs - Final Decisions (All) BOF final decisions were discussed and will be minuted separately. 6.2 [IANA #1365923] Management Item: Acceptance of media type registration requests from the World Meteorological Organization (WMO) Liz: Has anyone taken a look at this request to approve this registration and the addition of this organization to the list of standards-related organizations that have registered media types in the Standards Tree list? Roman: I looked at it and it looks like a very official thing. Murray: I'm of two minds about this. One is sure, why not? The other is, if they don't plan to register much else we don't have to bother. The interesting part is they were also saying they want to register some URI schemes, and I was unclear on whether putting them in the media types list affects the URI schemes. If that doesn't matter, then it shouldn't affect our decision. Sabrina: As far as we know, the URI scheme expert has used this list in the past. I think it would be useful to have them listed there. Murray: Okay, that's good enough for me. Erik K: I've had some interactions with this using ECM-WF data. I'm surprised they're only doing crib and buffer. Anyway, it seemed good to me. Liz: It sounds like we are saying yes to both processing this registration and adding them to the list? Roman: That's what I heard. Liz: Okay, then we'll send that official note to IANA. 6.3 Designated experts for RFC 9553 (JSContact registries) [IANA #1364749] (Orie Steele) Orie has designated Michael Douglass, Mario Loffredo, and Robert Stepanek as the designated experts for these registries. Any objections to these three? Okay, then they are approved and we'll get that official note to IANA. 6.4 Telechat schedule between IETF 120-121 (Liz) Liz: We have two options, each with seven formal telechats. Option A has two back-to-back [formals] in September, so that we could have an informal on Rosh Hashanah; Option B has a formal on Rosh Hashanah and two back-to-back formals later in October right before IETF 121. I didn't hear back on email from anyone who's celebrating Rosh Hashanah that would cause us to move the agenda conflict resolution; it would be great to know if anyone will be unavailable that day. Roman: Would it be helpful to have the double back to back in October to help clear stuff in prep for November? Éric V: It's a little early to say. I have a couple of drafts coming up but they should come in September. Usually two back to back before the meeting is quite useful. Deb: What's the draft cutoff date? You don't want to do a telechat after that, right? Then they couldn't update. Roman: They could with AD permission. Liz: The draft cutoff date is October 21, so that would be before the last formal in either case. Deb: In that case it would be useful to have one on the 17th before that cutoff. Liz: It sounds like we're leaning more towards Option B and we don't have anyone who will have a conflict on Rosh Hashanah? Francesca: Yes, option B. Erik K: There might be authors who have a conflict even if nobody on the IESG does. Roman: They don't have to show up to the meeting. Deb: They wouldn't be able to observe. Roman: If there was a document author that was observing Rosh Hashanah and wanted to join, could they not work with the responsible AD to schedule it on a different telechat? We'll have two more [after that]. The question at the top was if there's no one we know of in the liaison pool or ADs or other essential people who are observing Rosh Hashanah, because that's a dealbreaker if there is. [long silence] I'm not hearing that someone is celebrating from the folks that would participate here, so I think that gives us flexibility if we need to include authors. Liz: I heard a few comments that the back to back formals in October are better, and I didn't hear anyone who preferred Option A, so I think we are good to go with Option B. We will go ahead and put the dates from Option B in the calendar and later if it turns out that we will have to move something around Rosh Hashanah, we have a few months to work that out. 6.5 [IANA #1364810] renewing early allocations for draft-ietf-netmod-syslog-model Liz: This is one of Mahesh's documents and he isn't here today. Does anyone else know anything about this early allocation? It looks like this doesn't expire for a little bit, so maybe we should keep this on the agenda for next week's telechat and hear from Mahesh. Roman: Yes, let's wait for Mahesh. 6.6 Last call expiry date Liz: Robert pointed out the other day that he needs a yes or no on whether it's okay to change the time for a Last Call expiration to that time anywhere on earth vs. US Pacific time. Does anyone have any objections or questions? Roman: I didn't know exactly what this was asking. The last call expiry date now changes to the first time midnight happens anywhere on earth? Or the last time? Francesca: Basically this was Robert telling us that the last call expiry date should change the time to anywhere on Earth (AoE) rather than US Pacific, and this would match with other things in the Datatracker that use AoE time. There had been a bug where someone had a document that the last call expired but it appeared as not done because it showed US Pacific. Robert is going to do this update so that the time is coherent all over the Datatracker. I just wanted to make sure the IESG is aware this is happening because there is implicit IESG approval with this change. Roman: I'm still a little confused but I'm going to try to paraphrase. I don't think this is a big deal. There are places in the code that calculate how the last call happens and we're off by a few hours. So certain computations use Pacific and certain computations use AoE and we're going to make them all match. Francesca: Yes. Roman: That sounds fine. I don't know what it means to say AoE. David: All that means is that it's midnight in the easternmost time zone, in the middle of the Pacific. UTC+12. Francesca: The point is that if something says it expires June 11, we would wait until at it's June 12 everywhere on the planet before taking the expiry action. Éric V: I don't understand why we don't use UTC. But I don't mind either way. Francesca: Robert mentioned a community discussion about deadlines so I think there has been a conversation about this but it wasn't implemented in the Datatracker. So just that we know he is making this update. it's just about consistency in the Datatracker, basically. Liz: I'm hearing some confusion about time zones but no actual objections, so I think we can say this is approved. 6.7 IESG Retreat Agenda (Roman) The IESG went through the retreat agenda and discussed order of events, stuckees for each topic, and remote vs in-person head counts. 6.8 Executive Session: IETF 125 (Roman) The IESG ran out of time to discuss this topic. 6.9 Executive Session: PR action This topic was discussed in executive session. 7. Any Other Business (WG News, New Proposals, etc.)