INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2025-04-17 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Mike Bishop (Akamai) / Web and Internet Transport Area Matthew Bocci (Nokia) / IAB Liaison Mohamed Boucadair (Orange) / Operations and Management Area Deb Cooley (DHS CISA) / Security Area Roman Danyliw (CERT/SEI) / IETF Chair, General Area Gorry Fairhurst (Univ. of Aberdeen) / Web and Internet Transport Area Liz Flynn (AMS) / IETF Secretariat Jim Guichard (Futurewei Technologies) / Routing Area Mahesh Jethanandani (Arrcus) / Operations and Management Area Erik Kline (Aalyria Technologies) / Internet Area Cindy Morgan (AMS) / IETF Secretariat Andy Newton (ICANN) / Applications and Real-Time Area Tommy Pauly (Apple) / IAB Chair Orie Steele (mesur.io) / 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 --------------------------------- Jay Daley / IETF Executive Director Jean Mahoney (AMS) / RFC Editor Liaison Ketan Talaulikar (Cisco) / Routing Area OBSERVERS --------------------------------- Sandy Ginoza Bob Hinden Suresh Krishnan Warren Kumari Nathan Sherrard Greg Wood 1.2 Bash the agenda Liz: Does anyone have anything new to add to today's agenda? Roman: I think we wanted to talk about the interim meetings topic; can we add an item for that? Liz: Absolutely. 1.3 Approval of the minutes of past telechats Liz: Does anyone have an objection to the minutes of the April 3 teleconference being approved? Okay, I'm not hearing any objections, so those are approved, and we will post those in the datatracker. Does anyone have an objection to the narrative minutes of the April 3 teleconference being approved? I'm not hearing any objection there either, so those are also approved, and we will also post those in the datatracker. 1.4 List of remaining action items from last telechat o Erik Kline to find designated experts for RFC-ietf-ntp-update-registries (Updating the NTP Registries)[IANA #1412130]. Erik K: In progress; the registry requires three so that there can be two out of three for consensus. I think I have two people. I need one more. o Paul Wouters to find designated experts for RFC 9678 (Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)) [IANA #1414422]. Paul: In progress; I'm still waiting on one confirmation. o Mike Bishop to find designated experts for RFC 9725 (WebRTC-HTTP Ingestion Protocol (WHIP)) [IANA #1415864]. Mike: In progress. o Orie Steele to find designated experts to replace Graham Klyne in the Uniform Resource Identifier (URI) Schemes and Permanent Message Header Field Names, Provisional Message Header Field Names registries [IANA #1357864]. Liz: We have a management item at the end of the agenda to approve some names, so this one is provisionally done. * OPEN ACTION ITEMS o Roman Danyliw to work on adding a checkbox to the meeting registration system asking people to identify they are willing to serve as WG chair. o Roman Danyliw to take a look at Datatracker documentation of document states and update as needed. Roman: These are both in progress. And to close on an action item [not listed here], I sent the list we updated last week to the LLC on what you wanted to be updated about. Thank you all for the input. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-netconf-netconf-client-server-38 - IETF stream NETCONF Client and Server Models (Proposed Standard) Token: Mahesh Jethanandani Liz: There are no Discusses in the tracker. So unless there's an objection now, this one is approved. I'm not hearing any objections, so this is approved. Mahesh, what would you like to do with this one? Mahesh: Could you put it in AD review? Liz: Okay, great. So this one will be Approved, Announcement to be Sent::AD Followup, and you can let us know when it's ready to go. o draft-ietf-netconf-restconf-client-server-42 - IETF stream RESTCONF Client and Server Models (Proposed Standard) Token: Mahesh Jethanandani Liz: We do have a Discuss. Do we want to discuss this now? Eric V: Maybe, because I'm not sure whether my Discuss is really strong, because I don't know Yang enough, but Yang Catalog is an error compiling the module, and I think this should go either back into the Yang Catalog or back into the document. Mahesh: Eric, I can check if it can, but I believe he does validate the model before publishing that. But if that's the only concern, I can certainly put that as an action item for myself. Eric V: Just tell me what you think about it, because I balloted this one or two hours ago, mostly when you were sleeping. So bearing this error in the Yang catalog and the max which is not defined, as I noted in the Discuss point. No problem, right? Mahesh: Okay, I'll check that to update the tool set so [audio broke up] Roman: This is a good conversation to have. I want to ask the general version of this question, which is, if the Yang catalog is throwing errors and we see a datatracker page for a document on the ballot and it says error, is the tooling good enough to directly imply we have an issue and we should create a gate, even before it gets to the telechat if it has an error? Where is the state of the play in the tooling? Mahesh: It can sometimes run errors not because of the Yang module that is in the draft, but a module that it's dependent on. So that's what I was saying. I probably need to check where the error is coming from. Roman: I see. So in the general case, there's too much local, like Yang specific, on a particular document to know, and so we shouldn't necessarily infer that there's an issue just because an error got thrown. That's good. Okay, just checking. Thank you for that clarification. Liz: Okay, so this one will stay in IESG evaluation, and for substate, which would you like Mahesh; AD Followup, or revised I-D needed? Mahesh: Could you put it in AD Followup? Liz: Okay, great. So this one is in IESG evaluation::AD followup. o draft-ietf-suit-trust-domains-10 - IETF stream SUIT Manifest Extensions for Multiple Trust Domains (Proposed Standard) Token: Deb Cooley Liz: We have a couple of Discusses in the tracker. Do we want to discuss this document now? Deb: No, not today. Thank you. Liz: Okay, so this one's staying in IESG Evaluation. Would you like revised I-D needed or AD Followup? Deb: Revised I-D needed. Thank you. o draft-ietf-anima-brski-prm-20 - IETF stream BRSKI with Pledge in Responder Mode (BRSKI-PRM) (Proposed Standard) Token: Mahesh Jethanandani Liz: We do have a couple of Discusses in the Datatracker. Do we want to discuss this now? Mike: I believe that conversation is ongoing between the two working groups, so I think we just need to let that settle. Gorry: I agree. I'm keen to try and get rid of my TLS Discuss question, because I'm not a TLS expert. Is somebody else going to hold this? Whether it should mention TLS 1.2 or 1.3 and how it does it? Mike: I think that's the conversation that's happening right now. Gorry: That's fine. I just feel that I could clear if they address the second point, which I think they will do very soon, then I could just clear my Discuss and leave it to other people. Paul: I missed this document, but if it's mentioning TLS, then it should definitely comply with the UTA type documents that say when and how to use TLS version 1.2 or 1.3. Mike: The situation here is that this is an extension to an existing protocol. The existing protocol strongly recommends TLS 1.3 but makes 1.2 the mandatory baseline. And now we're flipping the guidance. And the question is, what does that mean for this extension? Do they only follow that guidance on the new component they've added? Are they both applicable? And therefore you must support 1.2 and 1.3 because they're not updating the original document. Which is the issue? If they were updating, was it 8995 then I would say, Yeah. As part of your updates, you have to flip to comply with the new guidance, but they're not. Paul: Does the extension use the same TLS connection, the main argument, or separate some of them? Mike: The base protocol has the pledge talking directly to the registrar. And this is to support a case where there's not network connectivity continuously between the two, so there's an agent that talks to the pledges, then talks to the registrar over a separate connection or at a later time, and then goes back to the pledges with the result. Paul: I would say that it would be kind of weird to have conflicting recommendations for these two things, and I would be more tempted to say, just refer to TLS recommendations to the main document, and then at some point, update the main document. Mike: They're having conversations with UTA right now, so I expect that's where they'll land. They can mandate it for the new component they've added, but at this point, as long as that conversation happens, I'm content with whatever they decide. I'm going to clear the Discuss regardless so long as they actually do it. Gorry: Yeah, that helps me. Thanks. Mahesh: Liz, you can also put this in AD Followup. Liz: Okay, great. So this one is staying in IESG evaluation::AD Followup. o draft-ietf-6man-zone-ui-08 - IETF stream Entering IPv6 Zone Identifiers in User Interfaces (Proposed Standard) Token: Erik Kline Liz: We have a Discuss;, do we want to discuss this now? Erik K: I still haven't finished. I'm getting caught up from being away for several weeks, but I did see Roman that Brian had replied to you. Roman: If he has, I have not read it. Erik K: Happy to take it over email. Roman: Okay, Liz: So this one is staying in IESG evaluation, and was AD Followup? Erik K: Yes, please. Roman: Bob's on the call, do you want to say something or you want to summarize? Bob Hinden: I just saw this this morning when I got up, so I haven't really read it very closely, but I thought Brian's response was generally pretty good. Roman: Okay, I'll take a look. Thanks. o draft-ietf-6man-addr-assign-02 - IETF stream Clarification of IPv6 Address Assignment Policy (Best Current Practice) Token: Erik Kline Liz: We have a few Discusses. Do we want to discuss this one now? Erik K: We could, I think, if people want to. I think the main concern, again, I'm still not completely caught up, is the coordination with IANA during Last Call. There was some stuff with IANA; I'm not really sure why everybody's upset about stuff, but yeah, people want to talk about this. Mike: I think one of the high level pieces is that they have an appendix that draws attention to an issue, but doesn't actually direct IANA to do anything about it. Erik K: Yeah, there was a thread about that during the Last Call, which is on the last call list, which is how it got marked as IANA OK. I provided my own personal opinion on that thread. One of the difficulties is that there isn't exactly parity between the IPv4 and IPv6 registries. The IPv6 registries are kind of split. Sabrina: Erik, just so you know, we are proposing that the appendix be removed, and we'll contact them about renaming sometime next week. I think our preference would be to remove 'registry' from the name, which is the direction that we've taken with other registries. But we'll reach out next week to the authors with suggestions. Erik K: That sounds great to me. Does that satisfy everyone who was concerned about that particular point? Eric V: I don't know if you've seen Brian's response to my own Discuss; he proposed text but hasn't uploaded the revised I-D yet, so I'm holding my Discuss until the new version. It's basically clear, though. Erik K: Sounds good. The IANA pieces can be handled on their own through separate correspondence, right? Roman: They could; sometimes we hold Discusses if they're breaking things that IANA needs. Sabrina will tell us definitively. Sabrina: I think we can handle this separately to make it consistent. Mike: Once the appendix is removed? Sabrina: Yes, that's what we're proposing to the authors. Roman: But ADs can hold if they want, that's within their right. Erik K: Sounds like there's an update required as well. I think this is Revised I-D Needed. Liz: Great; so this stays in IESG Evaluation::Revised I-D Needed. Erik K: Thank you. Great. o draft-ietf-uta-require-tls13-12 - IETF stream New Protocols Using TLS Must Require TLS 1.3 (Best Current Practice) Token: Paul Wouters Liz: There are no Discusses, so unless there's an objection now, this one is approved. Paul: Put this in AD Follow up, please. Liz: Okay, great. So this one will be Approved, Announcement to be sent::AD Followup, and Paul, you can let us know when it's ready. o draft-ietf-sipcore-callinfo-rcd-18 - IETF stream SIP Call-Info Parameters for Rich Call Data (Proposed Standard) Token: Andy Newton Liz: There are no Discusses, so unless there's an objection now, this one is approved. Andy: Can we put this in AD Followup? Liz: We sure can. This one will be Approved, Announcement to be sent::AD Followup, and just a warning for you Andy; this document does have a downref, so we are going to need to ask you if you want RFC 7903 to be added to the downref registry. Andy: Thank you. Okay. o draft-ietf-lsr-multi-tlv-16 - IETF stream Multi-Part TLVs in IS-IS (Proposed Standard) Token: Gunter Van de Velde Liz: We have a Discuss; do we want to discuss this now? Gunter: I think Ketan is not here, but there has been a good discussion between him and the authors of the draft. Things are progressing, and let's see where it brings us during the next week. Liz: Okay, great. So what substate would you like? Gunter: I think for the moment AD Followup, because they haven't given a new draft yet. Liz: Okay, great. So this one is staying in IESG Evaluation with AD Followup. 2.1.2 Returning items o draft-ietf-emailcore-rfc5321bis-42 - IETF stream Simple Mail Transfer Protocol (Internet Standard) Token: Andy Newton Liz: This is the new re-ballot for this document which we discussed last time, but there are no Discusses in the tracker, and there are enough positions. Unless there's an objection now, this one is approved. [pause] Okay, this is approved. Andy: Can we put this in AD Followup? And I would like to thank the rest of the IESG for going through a second ballot on this document. That was much appreciated. Liz: This one is Approved, Announcement to be sent:: AD Followup. Andy, again, this one has two downrefs; so once it gets to the final approval, we will ask you if you want 3463 and 3848 to be added to the downref registry. Andy: All right, thank you. I appreciate it. 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-6man-eh-limits-19 - IETF stream Limits on Sending and Processing IPv6 Extension Headers (Informational) Token: Erik Kline Liz: We have quite a few Discusses. Do we want to discuss this now? Erik K: I haven't caught up on stuff. I don't know if Tom was replying, but we could discuss here, if people want to. It might be that this ends up back at the working group. I don't quite know yet. Eric V: I would support your decision to send this back to the WG. Gorry: Tom did give me a little feedback in an email last night but he wasn't exactly proposing new text. I'll need to parse the whole thing again and send him another email. It's very much ongoing; I don't see an immediate resolution being offered. Erik K: From Revised I-D Needed I could take it back to the WG anytime, right? Roman: Correct. Eric V: Do you think it can be fixed? Erik K: That sounds like a question for the WG. Eric V: Fair enough. Gorry: This is a very extensive list of things you could pin down from stuff at one edge to the other edge to the middle…that's a complex soup. I don't know how you debug it. It'll be interesting to see what you could do to simplify that. Erik K: I'm sympathetic with the goal, which is trying to establish some conceptual interrupt from a baseline, at least within an administrative domain, or incorporating administrative domains so that you could buy a baseline of networking equipment that would have some support and not no support. So I am sensitive to throwing it all out, because it's not perfect could just mean that we basically never get anything. It probably belongs with the working group to decide how to address this volume of things. I need some more time to catch up on this, and also maybe some rounds of discussion with Tom could produce something. If nobody else has anything else, we could probably just put this into Revised I-D Needed, please. Roman: I would say, from my perspective, the narrow thing that I talked about. If there was an applicability statement scoping where this would be used, that would help. Erik K: Understood. That makes sense. I'll bear that in mind. Liz: Okay, great, so this one is staying in IESG Evaluation with a substate of Revised I-D Needed. o draft-ietf-6man-vpn-dest-opt-05 - IETF stream The IPv6 VPN Service Destination Option (Experimental) Token: Erik Kline Liz: We have a few Discusses. Do we want to discuss this now? Erik K: I suppose, if some people do. At least Ketan has Discussed but he's not on the call. Paul: I wouldn't mind briefly discussing it. I honestly don't understand the document. That might be some of my lack of knowledge of the layer that this is happening. But for instance, the dimensioning of authentication header, which is only about integrity and other encryption, combining that with talking about VPNs, which is about encryption, and how does it relate to IP based VPNs and other solutions is unclear to me. It seems it's setting an option to indicate this is a VPN and leaves everything else out of scope. I'm not sure what the goal of this is. Erik K: Maybe routing people can correct me; I've seen the P in VPN does not necessarily mean privacy or encryption. It just means traffic separation not natively routed with the traffic that carries it. Jim: Easiest way to think of it is they're essentially using an MPLS label; it has nothing really to do with encryption at all. There are encrypted VPNs and non-encrypted VPNs, and this one is just adding another option to the market. I didn't ballot on this; I was going to abstain but it didn't need another ballot so personally I don't see the point, but technically I couldn't see anything wrong with it from a routing perspective. Erik K: In this context, a VPN is not necessarily about security, you can swap/replace it with the term tunnel. Paul: It makes it somewhat clearer that they're talking about authentication headers. Still a little confusing that they're using spies, but I'll get some more comments from the authors to understand this. So sorry for any delays. Erik K: There are many other delays. I'm a little bit, I understand some of these arguments, I'm just not terribly sympathetic to the marginal cost of adding an experimental RFC is so high that it must be blocked. That doesn't seem like a sustainable position. Gunter: From my end, it's like Jim mentioned; from a technical perspective I don't see anything which won't work and I'm not proposing to block the document. What I do want to see better is how this solution lies within the other set of solutions out there. Just adding more context around the use space for this particular technology going forward. If you look at my Discuss that's what it boils down to, adding more context where this is used and what are the other comparable solutions in the market. Erik K: How comprehensive of a survey of the universe of tunneling solutions do you want? Gunter: It's not a pissing contest. This document was created back in 2018, and seems to assume that all VPNs are running MPLS, which is not the case anymore, and now we have v6 and those things are doing something similar than what this solution is doing. I think maybe that should be, you know, placed upon a unit. If you read the document now, it says whatever is out there is based upon MPLS, and that is not really true. Erik K: That's not how I read it. I read it as the MPLS heritage was explaining the way it came from and not necessarily implying anything. Eric V: Like you Erik, I don't mind too much if this thing is published. To Gunter, a VPN ID is 20 bits if i'm not mistaken. …. It could be made more generic, for instance. I don't mind the 20 bits but it could have been 32. Jim: From my perspective the thing I was most concerned about was the way I read the document, it implied the only way to use VPNs was to use MPLS, which is obviously not true. There's a raft of different ways of doing it that have nothing to do with MPLS. But technically it works, so I wasn't prepared to make a big deal of it. Erik K: I hadn't read it with that mindset. I had understood it as the MPLSiness of it as being motivational. I'll have a look at that and give some time for Ron to jump in as well. I haven't caught up as to whether or not Ron's been replying. Unless there are other questions, I suppose this is Revised I-D Needed. Liz: Great, this one is staying in IESG Evaluation::Revised I-D Needed. 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 NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Operations and Management Area Working Group (opsawg) Liz: We don't have any blocking comments here. So any final objections? Is this ready for external review? Mahesh: Roman did bring up the question of milestones that are missing in the charter. So maybe this is a larger discussion. I've heard from the chairs saying they're good for the initial working group, but for re-chartering a working group, they feel that these milestones really don't make sense in the sense that often they are outdated. Nobody really looks at them, and they're just exercising and updating the dates without really trying to make that as an ultimate goal. I have asked them for milestones, and maybe I'll get some. But I'm wondering if, as a practice, what do others feel about the need for having milestones? Roman: Procedurally, thank you for thinking through this issue. There is a community vibe around having milestones and different flavors of milestones. There's the dated kind, the undated kind, and an argument for not having any of them. There is a mailing list, protocon, around resolving that in some particular way. My concern here is that as written in 2026 we have to have them. If we could just document what we think we're rechartering for in the milestones, and then have the larger conversation about how they're maintained and what makes sense on that mail list. Mahesh: You're okay with milestones with no particular dates? Roman: There are different flavors of milestones you can choose in the Datatracker. There are sequenced milestones, this one first that one next, and I think there are undated ones as well. Someone correct me. Deb: You have 22 adopted drafts in that WG. Surely you can come up with a couple of milestones. Mahesh: The question is larger than just coming up with some milestones; it's probably a larger discussion about when they make sense. Procedurally, for now I can put in some milestones; but I've been getting a lot of pushback from chairs saying they don't make sense. Deb: Any adopted draft should have a plan, right? Mahesh: It's not that there isn't a plan, it's the dates. As Roman suggested we could go without dates. But if we start to put dates, most of the time we blow past them and they're meaningless. Okay, so maybe for now, what I'll do is I'll ask the chairs for some milestones, and once I get them, I'll put them in. Liz: There's nothing blocking this from external review. Do you want us to wait until you have those milestones in? Mahesh: Yes. Liz: Okay, so then we will leave this where it is, and why don't you let us know when there are milestones in and it's ready to go? Mahesh: Thank you. o Update to IANA Considerations (ianabis) Liz: We do have a couple of blocking comments. Do we want to discuss this now? Roman: Yeah, for sure. I just wanted to kind of tease out what makes most sense with you, Mahesh and Med. I'm not tracking, and I'm not sure whether the working group is tracking, the trajectory of that netmod document. It seems like both of you indexed on part of that. So what is the aspiration? Mahesh: So the idea was mainly to consolidate all these IANA guidelines into a single document, if possible. And we have it currently in 8407bis, which is in my AD queue already. I expect it to come onto a telechat in a short period of time, so it'll get published soon enough. The question is, at that point, should the document continue to maintain that IANA guideline, or should it then maybe have the other document pick it up? Roman: So you want to make sure that the 8407bis document is published because it's already in your queue, you don't want to block that. So the idea is, get that to RFC, then the question is if that's an RFC, there is this IANABIS working group that already has a chartered set of things it's working on. You want to make sure that the charter gets expanded to then capture the relevant IANA procedural recommendations there in whatever is in the BCP that's captured in that working group, right? Mahesh: Yeah. That certainly would be the ultimate option for me, as far as I'm concerned. [audio broken up] here's the guidelines you need to follow. Mohamed: And I would say, just an example, that the point is whether in the end, is really to have some guidance for future updaters of RFC 8126 whether we need to provide some guidance on this or not. This is something that can be happening. I don't think we need to spend a lot of cycles on this. This happens because I'm editor of this document, and Mahesh is the sponsor, so we know about it. But what happens for other documents who are updating 8126? Just having some guidance somewhere, or at least a discussion on how we would proceed in the future. It is not something I think that's really a lot of work to have in IANABIS as well. Roman: I'm not sure whether this is exactly related, but the way I would frame it is IANABIS was not created to be a long lived, long running place where we're going to perpetually manage IANA stuff. What happened is we went into Gendispatch two times ago and there was a groundswell of very specific things folks wanted to work on. And IANA was working on 7020. This was, let's put those together, and let's narrowly scope this WG. I don't know what the long term answer is. From my perspective, I want a narrow focused IANABIS working group, because I think opening up the box is not helpful. If we have a tangible thing we want to fix we should surface that. But I also think we need to gut check with the working group that they want to work on it. I'm a little bit sensitive to pushing work into the working group from this review if there isn't community appetite to do that. Mohamed: That's fair, Roman. Roman: So practically, what do you think we need to change in the charter? Or do we need to keep talking about it? So like on [the netmod document] what do you think are the right set of words? Do you have an intuition? Either of you? Mahesh: I would say, maybe just to ask that when we do publish the IANA document, that it just adds a reference, at least to begin with. As far as I'm concerned, just a reference to 8407 section 4.30. Roman: Understood. Deb: Why 4.3? Mahesh: Because that's the section in 8407 that deals with IANA maintain module. Deb: Is that in the bis document? Mahesh: That's in the 8407bis netmod document, yes. Roman: The way I've internalized it is that other document has a bunch of guidance. Some of that guidance is IANA specific. We want that document to be published. We don't want to block it. Well, I don't want to presuppose how the review would go. But let's proceed presupposing it's an RFC. Whatever the IANABIS is working on is going to take a while, again, not presupposing exactly how that's going to go, but it's going to take longer than to get the other one to RFC. You're looking to see a reference in whatever is some future document published by IANABIS to make reference to include in some approach that calls out that netmod document, right? Mahesh: Yes. That's good. Roman: Fair enough. And then, Med, you were making a document engineering observation about really prescribing which BCP things are added to, if the working group decides to consolidate, right? You had a very specific intuition about if the documents go into the same BCP, like, 26 is cited more, throw it into 26, instead of potentially minting a new one just not to break reference. Mohamed: Yeah, exactly. I think it's simple to address this one. Roman: For sure. And Eric, you made a comment on procedurally how to exactly do that. I know we'll figure out how to do that. I've also never done it. Eric V: Oh yeah, sure. I was just curious. Roman: Yeah, it's some status change something, if someone knows on the call how you put things into BCPs? We can talk that through. Okay. I really appreciate all that feedback. I didn't intuitively understand some of these things, so thanks for the clarity. We'll get a rev on the charter that will cover this. Thanks. This stays blocked. Liz: Great; so this will stay where it is, and we will await further instructions from Roman on how to proceed. 4.2.2 Proposed for approval o IOT Operations (iotops) Liz: We have a block. Do we want to discuss this now? Roman: I want to discuss it because I think we can absolutely clear it. So just to be really clear, on that charter text, we took the old text which was about talking about things, but we jammed it under the section that talks about making documents. So really, what we're saying is we're going to talk and make documents about that topic, right? Mohamed: Right. Roman: Okay. My recommendation editorially is maybe clean it up so it's a little clearer, but I'll clear my block. Just checking. Mohamed: Okay, thank you. Liz: It sounds like we're maybe waiting for a couple of more things before this is going to be ready to approve. So for now, we'll just leave this where it is and Med, you can let us know when it's ready and can be announced. Mohamed: Okay, thank you. 5. IAB news we can use Deb: They had a business meeting yesterday. They are adopting workshop reports, the nemops report and the AI control report, just to get the documents adopted. There was some discussion from Mark Nottingham about age verification and the sorts of things that he wants to do with that, basically doing a bit of a survey to see what the state of affairs is currently. There's some discussion between advocacy and architectural concepts where ISOC is probably doing advocacy, and Mark wants to stick with architectural concepts in the IAB. They talked about BOF chartering and who was assigned to what, and then they also talked about appointments that were up in 2025. They also talked about WSIS+20 and the upcoming meetings. Most of that was Ryan Polk. Tommy: The other thing I would bring up is we were planning out the work that people are going to be doing before the upcoming retreat in June. There are a couple different focus areas that some people are going to be looking at, like geo IP topics. I think we discussed that with some of the IESG folks too. There may be things that we can bring to joint discussion. I think there's also some discussion we may want to bring up around just reviewing and refreshing the NomCom job descriptions probably in both IAB and IESG, and since the IAB has to approve the slates that are given to us, we just want to make sure that the IESG job descriptions are clear and make sure that NomCom has the right information to come up with a good slate. So as you are working on that, let us know. 6. Management issues 6.1 [IANA #1414693] renewing early allocation for RFC 8111 (IANA) Liz: We talked about last time, and Jim, you said you wanted a bit more time to look into this. Jim: Basically 8111 was an experimental RFC, and they've now got 8111bis that they're working on in the working group to move this to standards track. So I'm okay with the early allocation and I approved it through email. That's what was happening with that one. Paul: There are not any wire format changes in the bis document? Jim: No. LISP has done this quite a bit. A lot of their documents were experimental RFCs, and they've gone through a list of them to move them to standards track from experimental. And this is just one of that group, so there's no actual changes as such. It's just moving it from experimental to standards track. Eric V: Out of curiosity, does it mean that the experiment went fine? Jim: It does, yeah, according to them. Liz: So Jim is recommending approval of renewing this early allocation and I'm not hearing any objections. So this renewal is approved, and we will send that official note to IANA. 6.2 [IANA #1357864] Designated expert replacement for Graham Klyne (Orie Steele) Liz: Orie has named Mark Baker as the primary and Murray as the backup designated experts for these registries. Any objection to approving these folks? I'm not hearing any objections, so they are approved and we will get that official note sent to IANA and that action item closed. 6.3 [IANA #1417100] Approve media type application/texinfoF(IANA) Liz: Has anyone had a chance to look at this? Orie: I've been following the discussion regarding this. To summarize for folks who are maybe not familiar with the work: essentially, there's texinfo, and it's been widely used. We've searched open source repositories and found many instances of it. This registration sort of cleans up the fact that this thing has been floating around in the wild for some time. Paul: Is texinfo a typo, or is that textinfo? Orie: I'm not sure about the query string if you're referring to that. I think it's intentional in its current construction. Roman: Thanks for that background Orie. I looked at it. This feels consistent with the application of the grandfathering rule that comes from Appendix A, so I'm fine approving it. Eric V: It's application/texinfo, rather than text/texinfo. But I guess people have discussed it. Orie: You should review the list discussion for that, there's a good conversation there around the history Eric V: Thanks. I may not review it, though. I trust you. Liz: I'm not hearing any objections so it looks like this is approved, and we will get that official note sent to IANA, spelled as requested. Cindy: To clarify, the F is a typo. The tex versus text is not. Liz: The F must have been a copy paste error when it was put on the agenda. So sorry about that. 6.4 [IANA #1417154] RADIUS Types Specification Required registries without experts (IANA) Liz: It looks like there are two registries that do not have experts, but are related to some others, so IANA is suggesting adding Alan and Mohit as the experts for these two as well. Any objections to these experts? Mike: I assume that the experts have been asked? Paul: Yeah, they were part of the email exchange with IANA. Liz: Okay, I'm not hearing any objections, so they are approved and we will get that official note sent to IANA. 6.5 Interim Meetings Mike: Just to refresh people from last week, the AIPREF working group has a fairly aggressive schedule, and they've requested an interim meeting immediately before the next IETF. Paul: A virtual or a physical one? Mike: A physical [hybrid] one. They have a virtual one planned in a couple weeks, and they've already had a hybrid one. They want to have another hybrid one before IETF. Based on our feedback from last week, they sent out a survey to the working group asking for preferences on dates and locations. And there does seem to be a pretty strong preference in the working group to do it immediately before the IETF. So the schedule that had been proposed was Thursday, Friday, interim; hackathon over the weekend, WG session on Monday, and then the people who are not participating in other IETF stuff can go home on Monday night. So we concluded last week that we don't object particularly to the idea of giving them an exception, although certainly that can be reopened. But our IESG statement guidance on in person and online interim meetings, depending exactly how you read it, can be interpreted as saying that's a hard no, and there's no flexibility for ADs to approve exceptions. So we have kind of the parallel facts of, does the working group want to do this? And that's happened with the survey. But then also, if we were to do that, do we need to update the IESG statement? Gorry: I'm new here, but I'm not that keen on updating the IESG statement. It's just extending the IETF week if we had a couple of days before. And people have in the past complained to me when I was chairing things that they weren't able to fit this in their travel schedule. Therefore, some people met just prior to the IETF and decided something. Then they had the working group meeting in the IETF, and doing this concurrently they found awkward. I guess it really depends on whether the people at that meeting would attend, or other people would like to see that and participate, rather than just that small group of people who are meeting. You know, is it just that working group? I'm curious about this. It rings a sort of alarm bell. Roman: I came to the queue to talk about what was mentioned before. If we approve the exception, I don't feel like we can approve this without also changing the statement. I don't want to be in a position where we are violating the thing we said, or the structural balance of things. And then, to me, if we decide to make the statement, we should think about what approach we would take? Would we think about community stuff, or just blanket make that change? Eric V: Last week, I basically said I supported the interim, because the participants are not IETF people anyway, so they will be coming just for this, and they will not be blocked by preparing for the IETF week; except Mike and the chairs, of course. Now I am with Roman, it's a hard no in the IESG statement. And I'm with Gorry: I don't want to change the IESG statement. So basically, at first I was supportive, Mike, and I'm now not supportive thanks to the two others. Paul: I have similar feelings. For instance, the IPSEC people also meet in what's not a formal IETF meeting, sometimes a few days before IETF. So on Thursday, Friday, they will also be meeting for an IPSEC workshop, but it's clearly not an IETF meeting. I also find it a little weird that we could have a physical meeting the days before that happens during the document blackout, where we cannot have updates to documents, but we can have an entire working group meeting, and it feels a bit conflicting to me as well. So I understand and sympathize with them, but I think they should maybe just have a more informal meeting beforehand, and not a formal working group meeting. Mike: For the informal one, the statement does address that. It says it applies to all hybrid meetings to which a substantial part of the working group is invited in person, even if labeled as informal, which feels kind of circular, because we're saying you can't have a meeting like that, therefore you call it informal, but you still can't have a meeting like that. I think if we were going to revise it, the main thing that I would change, it already says that as a list of considerations, and that there's always trade offs, and the chairs manage the trade offs with AD approval and just pulling the guidelines further down as also being part of those trade offs, I think a reasonable way to approach it, if we can do it. I think I understand the concern about touching the statement. I think it would be unfortunate to tell people they need to fly to Europe twice a week apart, because of our vault. Roman: I just want to respond to the idea of IETF participants and non IETF participants. There's no such thing as a non IETF participant if you're showing up. So this idea that we're catering a meeting to non IETF participants is to me a non-starter argument, because there's no such thing. If you're coming to the IETF, you're now part of the community. Eric V: You're fully correct. I was oversimplifying the point; most of the people in this WG are not regular IETF participants. They only attend IETF just for this WG. Roman: There are a lot of working groups that are one shot working groups as well. So I'm just unpersuaded by that. Tommy: I had originally gotten in queue to mention something similar to Paul. I've seen that work for other groups; that has happened the week after the meeting. Some topics are related to the WG, some aren't, but it's a place that can still foster stuff. I'd lean toward recommending they hold this as a workshop for the willing and maybe that leads to stuff that happens in the week. I do think there is a benefit to having it be right before; I agree of course there are no non-IETF participants, but if there are people who would only be going for this and we said you have to hold the meeting a week or two before, they'd only show up for that and not the plenary IETF meeting. There could be a benefit of having those folks be able to be there on a Monday and interact with the rest of the community that will only be showing up to the IETF week version of the AIPREF meeting. That interaction seems to be important to foster and let's figure out a way to let things happen that work well for the policy that focuses on good technical outcomes and interactions between people. Deb: As I recall this interim meeting was supposed to be in London? Mike: We have a venue offer in London, a potential venue 45 minutes outside of Madrid. Given the distance from the IETF venue, we don't know that having it in Madrid is all that helpful. Deb: As opposed to flying or training from London? That's not 45 minutes. Mike: Right, but you still can't necessarily book one hotel for the whole time in either case. Part of the survey that went out was also if you prefer London or Madrid; participants seemed to be largely split between the two. Deb: There are many WGs that have proponents that only come for that one WG. We could list them and it's at least in double digits; this is not a new thing. The new part is they want to do hybrid interims as opposed to virtual. Many WGs do virtual interims every 2 weeks and make that work. I'm opposed to updating the statement. If it were Boy Scouts and we were going to laser tag, we'd have to say we were going as friends, not Boy Scouts, for example. Roman: From my perspective, I'm not against having some flexibility to allow that. I'm reticent to approve this happening without having the statement to back it because it violates our process. I think we should be in the position to allow under extraordinary circumstances to meet right before or after the plenary meeting; I'm not sure we are meeting the bar for extraordinary circumstances. Mike: The circumstances here are the WG is trying to complete this on a rather aggressive schedule because there's regulation happening in parallel and they're meeting frequently, both in person and virtually. Whether that meets the bar of sufficiently extraordinary, I'm not sure. Roman: If there was an aggressive deadline it might meet those circumstances. I'm just cautioning us that we're setting precedent here; the bar for extraordinary here is now the bar for everyone else. If we wanted to make a change to the statement, I put some words in the chat for how we could change it. Erik K: That change looks good to me. Mike indicated they're also going to meet during the IETF week so there is no issue about cannibalizing attendance. Mike: We did talk about the possibility of having multiple sessions throughout the week; I understand that we somewhat informally have a policy that multiple sessions are spread out through the whole week. Roman: I don't know whether that's true. Eric V: We were trying to put the second session on Friday, though. That's what we did multiple times. Roman: To me, if we have extraordinary circumstances and we can satisfy this during the meeting week, what are the constraints desired for the meeting week? Is it two sessions? Two sessions close to each other? Is it three sessions? Like, what? This is a different angle I hadn't heard. Erik K: That sounds like something we could resolve during the two scheduling calls, and they just need to put that in their session request. Mike: So that could be another answer, asking them to request lots of sessions? Deb: One two hour session with two two hour sessions is going to make them happy? That's not exactly the same as two days of informal meetings plus a session. You're not going to get two days. Mike: It might be a fallback position. Roman: Would it be helpful for you, Mike, to get an informal poll in Slack about whether we would support this right now with the little we know? Mike: Yeah, I think that would be useful feedback. Gorry: I was just trying to figure out whether these people actually needed a working group session. Do they need to make decisions on the document as a working group, or do they need to talk about things, develop text, and work on methods? To me, these are very different. If it's just talking, you need time, if it's making decisions, then that is the bit I had the problem with just prior to an IETF where other people might be traveling and we don't get visibility etc. So do they need time to prepare documents and work on them, or do they need to make decisions to do that? Mike: I feel like that's kind of an amorphous line, because they have the documents out there. We're working with documents already submitted. They discussed the documents at their first hybrid interim, there's a call for adoption ongoing right now, and there's going to be ongoing work on the documents. Now, when do you move from working on documents to making decisions about what's in the documents, and all decisions have to be on the mailing list anyway. What do we ever do at the plenary meetings? Roman: This feels like the really great line on us managing side meetings. Is this working group run, or is this an independent document team? And we can save that for the retreat. I don't know what to make of the poll the way it's looking. Maybe it's not updating. Three people responded and those three people responded yes, no one said no. And I think that means nine people didn't say something. Mike, can this be serviced by some creative scheduling constraints during the meeting week? Does that get us most of the way? Do you want to talk to the chairs about whether that's helpful? What helps you? Mike: I think I still consider that to be a fallback position. If the IESG says they cannot hold an interim meeting, then we talked about some amount of workshop time plus, plus meeting times during the week. I share your confusion about how to interpret this poll. Roman: We just got a bunch more responses. It looks like it's half and half right now, yes and no. Erik K: I was gonna comment about your update to the IESG statement. In general, I'm in favor of always having leeway. Categorical policies are seldom sustainable. Obviously they must not during the meeting, I think is fairly defensible. But giving ourselves the option to approve for exigent circumstances that's a power we should attain. Roman: That's my position. And in terms of the words, that's why I included a new set of words, which was to schedule during that time that would take the whole IESG, the same way we're doing it, to provide a little more bounds on this. Paul: I have a clarifying question. This is not really an interim meeting of like an hour, right? This is a whole day or something? Mike: Yeah What we did in Brussels was two full days and one half day. The proposal here is two full days Thursday and Friday. Paul: I think that rules we kind of set out for meetings in these weeks, they're sort of more aimed at a one hour meeting, and now you're preempting the IETF working group meeting. I don't think we really meant to exclude things like people getting together for two days and hacking on things. Maybe we should look into that angle a bit more to see that this is something different. This could be just a bunch of enthusiastic people getting together and working for a couple of days. Mike: Moderated by the chairs. Paul: Well, you could not do that. Roman: Again, what I'm seeing is the IESG is split on whether to approve that. And I think, based on my interpretation of how we run things, that means that this is not going to get approved. And what I heard was a bunch of suggestions, how can we squint at this? And that might be a redefinition of what is a meeting, which is what you just said Paul, to workshop, which I didn't fully understand, and a couple of other things. Paul: For instance, the IPsec workshop that happens the two days beforehand is a lot of people getting together, and there's no note well or anything, and we might work on things we just like. Obviously don't do things that aren't allowed, or that would be strictly IETF activity. So I think that that sort of solution could work fine for others too. Erik K: I wanted to ask a clarifying question on the poll. I interpreted that to have a parenthetical in this particular case for the specific thing, not in the general case. I don't know what Mike meant when he put the poll together, and I don't know if that colors people's responses, whether they think they're answering in the general case or answering in the specific case. Mike: I'm approaching it that if we had a leeway that said a vote of the IESG can approve under exceptional circumstances, would that vote pass? If it wouldn't, there's no particular urgency about giving ourselves that leeway. If it would, there's a procedural question of how we would open that up. Erik K: I don't know if that changes anyone's answers. Thank you. Roman: I'm short on ideas of how to recalibrate this; we're at an impasse. We're about half and half; half of the IESG appears to feel uncomfortable approving this with the constraints we have. Alternatives I heard were try to re-scope this as something slightly different, or redefine the categories of what's allowed based on different definitions of how the meeting would occur. Like how Paul said, we weren't talking about long running, multiple day meetings when we wrote that. Paul: I'm also wondering if it's an official IETF activity the Friday before the meeting, you would get conflicts with people who would want to go but who are on an airplane towards IETF and cannot attend, which is exactly why we don't do this. I think that leans toward it being not an official IETF activity if it's that close to the IETF. Roman: We've gotten very specific feedback about the exclusivity you create when you have a meeting cadence which does not allow people who would normally come to the session to follow along. Anything else to talk about on this? Andy: This may have been said already; are there meeting logistics they need like Meetecho? Is the plan to run it like a WG session? In the chat it was said this could be a hackathon, and Deb said they could just meet at the [IETF] hackathon. I'm curious if that would solve the problem? Mike: I don't think by itself. The plan was to run it like a WG session; discussion of issues and with adopted documents. We did have a lot of good discussion from the meeting last week; we were using Meetecho. What does the workshop look like if we schedule over Webex? There are ways around that, so we don't necessarily need to have the infrastructure, it just feels weird to say you need to get your own infrastructure. Andy: They are going to be doing IETF things then, like trying to approve documents for adoption? Mike: Or work on documents that have been adopted, yes. Andy: I feel like work on documents that have been accepted is different than calling for adoption. In my opinion if the chair is running the session and acting like it's a WG, it's a WG session. If it's just a bunch of people in a hallway working on documents, that's different. Does that make sense? Mike: Kind of? It wouldn't be a hallway, but if it's a bunch of folks in a room moderating a discussion, who's moderating? Andy: I don't know if that was a helpful set of questions, but if a chair is going to be making decisions or announcing things, there's no way around it; that's an IETF meeting. If there's not, then we have some wiggle room. That's my opinion. Mike: Formally, things the chair decides have to happen on a list, so nothing that happens in a room is [official]. Roman: The closest analog I can think of is side meetings, where we used to have a problem with some WGs convening side meetings for additional meeting time and the chairs run this side meeting about documents. We've previously said that's a no-go. I'm sensitive to time and we still have an exec session, so we still need to think about how to help the WG. Mike: Thank you for the input. Liz: We have some executive session topics; does anyone have any other business before we move into executive session? [Silence] 6.6 Executive Session: RSWG Chair Appointment Process This topic was discussed in an executive session with IESG, Secretariat, and the IAB Liaison. 6.7 Executive Session on BCP 83 This topic was discussed in an executive session with IESG, Secretariat, and the IAB Liaison. 7. Any Other Business (WG News, New Proposals, etc.) None