INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2023-10-26 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jenny Bui (AMS) / IETF Secretariat Roman Danyliw (CERT/SEI) / Security Area Dhruv Dhody (Huawei) / IAB Liaison Martin Duke (Google) / Transport Area Lars Eggert (NetApp) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe 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) / Applications and Real-Time Area Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area OBSERVERS --------------------------------- Greg Wood 1.2 Bash the agenda Liz: Does anyone want to add anything new to today's agenda? Andrew: I sent email earlier asking if we could add an executive session at the end. If possible. Liz: Yes, we got that. Any other changes to the agenda? Ok great. 1.3 Approval of the minutes of past telechats Liz: We don't have any minutes to approve since we usually give 2 weeks, and we just had another formal last week so nothing in minutes. And we can just move straight to the list of remaining action items. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Rob Wilton to find designated experts for RFC 9445 (RADIUS Extensions for DHCP-Configured Services) [IANA #1279159] Rob: I thought I sent an email to approve that. Liz: I don't think we have that. Rob: I'll have a chat, can we add as a management item? I'll put it in the chat. o Roman Danyliw to find designated experts for draft-yee-ssh-iana- requirements-03 (Key Exchange Method Names) [IANA #1281831]. Roman: I did not have a chance to button this up despite what I had promise last time. Same with the ACME one. Although, I continue to think I have done that. Liz: Rob I just looked down and saw that we actually do that it as a management item on the agenda. We'll cover it at the end. o Roman Danyliw to find designated experts for RFC 9447, ACME Authority Token Challenge Types" [IANA #1281679]. Roman: I have to button those up. * OPEN ACTION ITEMS o Warren Kumari to follow up on a bis document for RFC 8126 regarding designated experts. Liz: Warren is not with us so we'll leave in progress for him. o Roman Danyliw to open a Datatracker issue suggesting a feature to better signal individual contributions Roman: This is done. We found consensus on the text. I talked to all of the stream managers this week and they all said thumbs up on the text that we had produced. Everyone wanted to chat a little bit, but realized the consensus that it takes to make those words and there is a feature in Github requesting to action that. Mark as done, please. Liz: Great, we'll mark this as done. Lars: I asked by Robert because what we showed them is what should go on the metadata page for the document in the Datatracker. The question from Robert is if we also want something on the htmlized page which has the metadata thing on the right hand side. If you click on the htmlized thing on the Datatracker, it will take you there. I think we do, but it also needs to be shorter. So we might need to do it second spin on something we can put there. It can a short thing that can pop up or something that has something longer, i.e. what we already agreed on. But maybe we do that sort offline Slack. Roman: Ok, sounds like a plan. o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John Scudder, and Jim Guichard to draft text regarding document authorship/editorship with regards to the number of authors listed. Andrew: That text I found in mail from Warren that ended up in the spam, so I fixed that now. Lars, I saw your proposal, it's pretty far from 7322. The question is, how far do we need to follow 7322 given that it's an informational IAB document? Lars: That's a good question. Andrew: Your proposal also works, when I wrote the original proposal I tried to stick as close to 7322 as possible. Lars: I'm not married to my proposal, I can't even remember what it is just illustrate how much i'm not married to it. I'm also wondering if this is something for the RSWG because policy for the serious, at least for the RFCs it would be. How many authors before you can argue it makes no sense to have more authors on Internet Drafts than RFCs. John: I love the idea of punting it to someone else. Andrew: I also like the idea of punting, John. My only issue is that I rather not see this take a year to get resolved because it's a question that's coming up more and more frequently. John: We can probably do both, right? We could try to wrap up our own deliberations but also say dear RSWG, would you please come up with something longer term policy on this? Andrew: What I would propose based on the lack of congruence between Lars' proposal and what I originally wrote is that unless there is serious issues, we go with what I propose pending edits from anyone else who wants to add etc. We do and put in there that this is interim while we are asking RSWG to do something about it. Eric: Isn't this forcing us to go flip flop in 6 months or so? If the proposal is difference between yours and RSWG? Andrew: It possible is, but who knows how long the RSWG is going to take to do anything with it. As I said, rather not be sitting with this a year from now. Eric: It's not particularly right so we don't need a short term answer in my opinion. Andrew: Any other thoughts? Lars? Thoughts? Lars: Nope. Sandy: Lars, I wonder if you think this is policy, if it, and there is, something existing in the style guide, if it should be something that RSAB looks at for an interim solution. Lars: The RSAB would only interpret current policy, it couldn't change anything about the current policy. I think the problem is lack of clarity to some degree. Sandy: Right, I see. Lars: I think that clarity needs to really come from the RSAB, otherwise, I think the community will say that RSAB is overstating overstepping its mandate and that should be discuss in the RSWG. But I have no problem with the RSWG telling the RSAB to do this. Sandy: Ok. Understood. Andrews: Lars, do we just straight to RSWG or do we use this as an interim? Lars: If we agree, we can just punt it over. I don't any reason to wait. We can basically send an email to the RSWG mailing list and say the IESG theoretically, has the mandate for ownership on Internet Drafts because they're all input to the standards process. It makes no sense that it'll be different for what's allowed on Internet Drafts than on RFCs, and that part is up to the RSWG. We can explain that there's an issue with the current policy as defined in the RFC and ask them to please clarify that. We can adopt whatever they come up with also for the Internet Drafts, and if we don't like it then we don't adopt it and we go in a circle. Andrew: I'll send an email to RSWG and specify that there is some lack of clarity that we like some clarity, and if they could provide some guidance. I'll state in the email that we were working off 7322 but there were some ambiguities and so if they could please give us a proposal. Anyone got any issues with that? In which case, can we change that action item to "Andrew to send email to RSWG"? Liz: Sure, we can update this for you. o Lars Eggert to facilitate a community discussion on priorities for IESG processes. Lars: I think to mark as done because I tried and was told by the people of that had the Netwon BoF that they did one time in GEN area and Mark Nottingham won the ballot, follow-up is happening in GEN area. So I think having scheduled GEN area takes care of this management item. So done. Liz: Ok, we'll mark this as done. o Lars Eggert 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. Lars: In progress. o Erik Kline to follow up with authors of draft-ietf-6man-rfc6874bis to schedule a conversation about the document. Erik: That conversation might happen in Prague so i'm okay leaving this management item until after Prague. Otherwise, there's an email thread sort of ongoing that seems to be a lot more information than previous discussions. If Murray is okay, i'm ok removing this as a management item but could also leave it on until the November 30th just to check back in one more time. Murray: I think that's fine. I think we're on top to the extent as we can be. I don't know if it needs an identification as a management item more than any other document that we've been working. Eric: If there's some intersection with other SDOs, I think that's why it's a management item. Erik: Post Prague is fine too, we can revisit it one more time. Murray: Yeah, that's fine. Liz: Ok, we'll just leave this as where it is for now. o Francesca Palombini to draft an update to the wiki page "Getting a Document on the Agenda." Francesca: In progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-alto-oam-yang-15 - IETF stream YANG Data Models for the Application-Layer Traffic Optimization (ALTO) Protocol (Proposed Standard) Token: Martin Duke Liz: We have a couple of discusses, we do need to discuss this today? Martin: Briefly. Thanks for comments everybody; they were good. As usual, i'm reading these in the last 15 minutes because they happen overnight. Roman, your discuss is great. The one thing I would say is doing it over plain http is part of 8895 which is a YANG Model for, so maybe the residual risk of running over http is out of scope for this document. Roman: Ok. I can buy that argument. Just to replay it, this is a YANG model for previously published document, which specified in a certain class of behavior. So if we specified it then we should be able YANGized it? Martin: Yeah. Roman: I have a similar discuss in the other YANG document where I continue to understand for new services we need to have http. Martin: In this day of age, i'm not convinced about that. Let's up this in revised I-D needed. The author has been pretty responsive. Hopefully this could be resolved pretty quickly. Roman: One of the reasons i'm pushing on the TLS part representing in YANG is my read of what 7285 is it actually made statements that you could use off TLS. If it says that is the preferred mechanism, we should provide that support. Martin: Yeah. Liz, revised I-D needed, please. Liz: Ok, great. We'll leave this where it is with the substate of revised ID needed. o draft-ietf-alto-new-transport-17 - IETF stream The ALTO Transport Information Publication Service (Proposed Standard) Token: Martin Duke Liz: We also almost all the colors here with a few discusses, we do need to discuss this now? Martin: Good comments. This will definitely go to revised I-D needed. Is Zahed on? Zahed: I am, yes. Martin: I didn't get your question about concurrent nonblocking update transmission. HP2 is also that, it's true that there's not packet loss. The idea is that resources are available at different times and they're using HP1 model where one is blocked by the other. Zahed: I understand the concurrent and all they are talking about, but it does not obviously in the context of this document because it talks about HTP3. It basically doesn't have HTTP and TCP deadline block for HTP2. HTP3 solves that one, and HTP2 has headline blocking on TCP level and HTP1 has some other level. I feel like the authors also mentioned in concurrent means multiple connections, which is not allowed in HTP2 or HTP3, so to say. I'm not exactly sure I understand in this context what concurrence means. I expect to describe it. Martin: Ok. We can add some text, I guess. I don't have any objections to that, I think just about everybody discuss this document when you count supports. Eric: If we can get a reply for the INT DIR, it would be nice as well from the authors. Martin: You wrote that? Eric: The INT DIRs reviews was negative and not a single reply for one week. It would be rude. Martin: Yeah, i'll make sure all this stuff it followed up on. Eric: Thank you. Martin: Please move this to revised I-D needed. Liz: We'll leave this in IESG evaluation with I-D needed. o draft-ietf-httpbis-alias-proxy-status-05 - IETF stream HTTP Proxy-Status Parameter for Next-Hop Aliases (Proposed Standard) Token: Francesca Palombini Liz: I don't have any discusses here unless there's an objection, it looks like this one is approved. Francesca: I believe the authors are preparing an update so if you could add the revised I-D needed tag to go. Thank you for the reviews, everybody. Liz: Ok. I'll put this in approved announcement to be send, revised I-D needed. o draft-ietf-cbor-time-tag-11 - IETF stream Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period (Proposed Standard) Token: Francesca Palombini Liz: We have a couple of discusses, we do need to discuss these today? Francesca: I think the authors have replied to Murray's discuss point. Murray: Yeah, Carsten got back to me and he needs to get back and post a revision. He told me what the answer is, it just needs to be in the document. So when we get a new version this will be all good to go. Francesca: Ok, great. Revised I-D needed here too. Liz: We'll leave this in IESG evaluation with revised I-D needed. o draft-ietf-cdni-delegation-acme-03 - IETF stream CDNI delegation using Automated Certificate Management Environment (Proposed Standard) Token: Francesca Palombini Liz: We have no discusses on this one unless there's an objection, it looks like this is approved. Francesca: Thank you for the review. I would like AD follow-up on this because I haven't followed the conversation, I don't know if there's an update to be made. Liz: Ok, perfect. We'll put this in approved announcement to be sent AD follow-up. Francesca, you can let us know when that is ready. 2.1.2 Returning items o draft-ietf-core-sid-22 - IETF stream YANG Schema Item iDentifier (YANG SID) (Proposed Standard) Token: Francesca Palombini Liz: We have a couple of discusses, do we need to discuss these today? Francesca: I don't so, but Rob? Rob: Sorry, I haven't had a chance to check the latest text. I get the feeling that sort of Carsten and I getting to consensus of agreement so I think everything is OK. Even though it isn't already resolved, it will be shortly. I suspect. Francesca: I think, Lars, your discuss is somewhat related to what Rob was discussing with Carsten. Lars: Sorry for the being late as I just dropped this like an hour ago because I didn't have enough time to review some stuff so I just went through the ballots and this one needed one more that's why I read it. My main concern, and maybe this is something we can talk to Sabrina about which is whether IANA is actually prepared to store all these zip files because i'm not aware of any other registries where IANA was tasked with maintaining files associated with registry entries. Maybe I don't remember, and maybe they're doing this for somebody else. It seems kind of unusual and it seems kind of a heavy lift for IANA so I wanted to make sure they're really OK with this. Rob: I did discuss this with Sabrina and she's been copied into the conversation i've been having with Carsten, so she knows what has been planned here. I think they're OK with it. Another example, is arguably the YANG files cause I think there's references to the files held in IANA as well. They are also in the RFCs but I think that'd be a place that people might go to get them. There's also other places you can get the YANG files as well. Roman: One thing fascinating for me to cite the YANG file, why does the YANG file stay into the RFC but the SID file does not? Rob: I think for me, the SID file could more likely change over time maybe gets corrected without necessarily needing a RFC to update it. I think it could potentially change. Where YANG file could currently be a RFC. I think the real answer to this is, I don't think the YANG file should be held in the RFC either. I think they should be held somewhere else. (crosstalk) Lars: This is the old living document issues, and I don't think asking IANA to be repository for this is super great. Eric: I also wonder if you have 1 YANG which is stable and having multiple SID for the same revision, it's inconsistency. Rob: It wouldn't be the same revisions. You could have a SID file for a later revision. Eric: You could have YANG models with revisions in a RFC? Rob: Not today, but the two in my mind, putting aside the process aspect of this. I logically think the two is slightly separate. 1 is the YANG model gets published at one point in time and SID files, I don't know what other reasons they might evolve separately, but I don't think the file itself has to necessarily be one at the same time. You would fix something and you SID generation file or something like that fixed mistake, I can imagine a new generation to SID files being generated and still relevant to the same YANG file. Eric: The issue which is one part of my comment is that specific SID ID is unusable even if they change the model and I think it's frightening because they can change the semantics with an identifier. Rob: because the SID is tied to the path not semantics. Eric: It's link to an identifier and to the YANG model specific revision, and the same identifier revision could have a different type. Rob: The binding to SIDS to paths is not to a particular revision, it uses that path forever. If you have an interface name, it will always have a given SID even if you change the type off semantics in a future revision, it still keep the same SID. Eric: But then the SID doesn't bear the revision? How can the receiving part decode this interface in this syntax and interface in depth syntax. It's really scary. Rob: That's not what the problem the SID is solving. It's just giving a numerical identifier as equivalent to the name as a short version of doing the name. Eric: It includes the revision of the YANG model, that's what scares me. Rob: The revision in the SID file from what I remember, is just a reference. It's just saying this is the version I built the latest SID file from. It's just a reference rather than saying this SID file is from this particular revision of the YANG model. You should be able to use an updated newer version of that SID file against an old version of the YANG model which should be fine, expect if things get removed or deleted over time. It's not guaranteed but there's no false binding. Eric: I can only repeat, i'm scared of the lack of integrity of the full system, but okay. Rob: Maybe the solution here, is to get Carsten to come to an informal and explain how it works. Francesca: I can try, if we don't resolve this This draft has been with me for a very long time and then it was with Eric and now it's back with me. I think it has improved a lot. Thanks for all the comments. I would like to get it resolved and shipped, so if I suggest we continue discussion with mail. I think Lars, I can give an attempt at responding to your discuss, but Carsten will probably also do that. This is very similar to the points that Rob has brought up as well. If we don't solve it after IETF 118, I can definitely bring it to an informal and have Carsten discuss it. Eric: But can we relate it somehow to experimental? Lars: That doesn't really change anything for me. I'm basically discussing whether IANA should be a file hosting or not. Francesca: There is a precedent for it that we got an OK from IANA. Lars: What's the precedent? Francesca: I think it's YANG? Sabrina: I think Roman had a similar question recently. There is precedent on how the IANA table registries are currently handled where the expert generates the xml for us, but they're not included in the RFC itself. In additional how we're currently maintaining the YANG modules. Roman: I think my question was around a difference precedent than what I think Lars was saying. Lars was talking about file hosting. My precedent was, I was concerned that SID files are defined in the I-D, but then removed in the RFC. And that seemed confusing to me, because YANG files are published in the RFC and then published as a file. I think the precedent was codes for the international code points is what you told me, Sabrina? Sabrina: That's correct. Lars: That's a good point too, Roman. With YANG model, the model that is in the RFC is the canonical one and if there's ever data corruption in IANA, the RFC, but here, there's an archival copy would be maintained by IANA, and there's really no way to later validate whether what IANA has on their website is what was in the RFC. We have a draft available which would still have the SID file in it, but it feels brittle and is also feels operationally heavy weight potentially. Rob: One other issue putting the SID files in the drafts, is that they want to publish SID files publishing SID files to the existing 100 YANG models that the item was published. I'm getting 100 RFC updates for that seems like a heavyweight process to achieve that. (crosstalk) Andrew: How are you concerned about the load? Sorry Lars. Lars: How would you get community reviews on whether the SID file is correct? Rob: I think you have designated experts, I don't think you need community reviews for SID files. It's basically generated by a script, and there are some reasons where you want tweak them, if you are evolving it and you have got a model with specifically constrained device. Lars: Why is part of the ID? If they're basically just a script that you run over the YANG model? Why do you need to also exclude them in the ID when you write that? Rob: So i've said two suggestions. You can embed them in the ID, if you want to manually control them, for some of the YANG models. Like BGP might be an example. It may not have such a target for constrained devices. And hence, you may not have the hassle of maintaining the SID files during the evolution of the ID and only create it at the end. Andrew: My concern with what you just said about a 100 RFCs that needs to be updated. Is that it increases the workload for IANA for one thing, and i'm not sure about this at all. Rob: It's not updating 100 RFCs, we do that if we say we have to embed them into the RFCs, but otherwise sending IANA 100 references to 100 links. I can't imagine the load on IANA to upload 100 links to files is necessary. Andrew: I do have to agree with Lars here that i' m a little bit worried about, the fact, we have something that we refer back to that is kind of immutable that will be lost in this process. Francesca: Ok. Point taken I think we can continue with offline. I will let Carsten to reply, and if we don't get solution then maybe we can talk about it in person at 118 and try to resolve it. Try to convince this is the right thing to do. Lars: We can add this to the IESG agenda to 118, and we can figure out whether we want to invite Carsten because IANA is going to be at 118 as well so we have them there. Francesca: Ok. When do you mean, exactly? Lars: We're collecting already agenda items for the for the Sunday meetings, and for the breakfast meetings if you put it on there then when Mirja and I triage the list that various people people have come up with, i'll stick it into one slot somewhere. Francesca: Could I ask the Secretariat to add it? Or do I need to send an email? Lars: You just put it in the wiki. Francesca: Ok, got it. On the wiki. Liz: Ok, for this document, i'm guessing we might need a revised ID? Francesca: Yes. 2.2 Individual submissions 2.2.1 New items o draft-freed-smtp-limits-07 - IETF stream The LIMITS SMTP Service Extension (Proposed Standard) Token: Murray Kucherawy Liz: We don't have any discusses in the Datatracker unless there's an objection, it looks like this is approved. Paul: I mean, obviously, it can be approved. I just find it a little weird that the replied to our comments to at least Roman and my comments was like I don't want to change the text because of the previous deceased author. Which I think is not a very good argument to use if the IESG has issues with the document that needs to be fixed. Right? It's by the original author cannot do that. Then it has to be by whoever is the current author of the document. I will address this issue this time because all these issues are pretty minor and especially mine are like more questions of why aren't we doing this and I got answers of why we're not doing it. So that's fine. I found the reasoning not a good precedent, and I would not like to see that as a precedent for the future discussion. Murray: I understand. We can approve this with AD follow-up and I do want to ask him about that for all the reasons you gave. Approve it and AD follow up, and i'll talk to him about that. Liz: Ok, great. We'll put in the approved AD follow-up, and you can let us know. 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 NONE 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 NONE 4.2.2 Proposed for approval NONE 5. IAB news we can use Liz: Roman, do you have any IAB news? Roman: I'm quickly pivoting. I did not catch anything that I haven't already previously reported on, which is in flight progress on statements. The most important one that touches IETF is the RATS working group or select members of the working group we're going to have a chance to go talk about the attestation statement with the with the IAB. Otherwise, a number of the other kind of charter things are in flight. We have the 3 working groups at the meetings, and the IAB is going to cover them like they usually do and they've done the assignment there. Dhruv: Roman, can I add something? Roman: Absolutely, Dhruv, I'm sure I missed a few things. Dhruv: One thing is the IAB is not going to continue with the identity program, at least see the progress and then conclude whether we close down mailing list that we have on the IAB as well. Based on the discussed that happened. We thought the BoFs or anything happening, and maybe the program is not going to lead to anything new that the IETF isn't already working on. We also approved the IETF WC3 which was discussed with IESG earlier, and we got feedback and the IAB approved, we will be sending out the notice. 6. Management issues 6.1 [IANA #1279159] Designated experts for RFC 9445 (RADIUS Extensions for DHCP-Configured Services) (Rob Wilton) Liz: Rob has identified Alan and Mohammed as the designated experts for this registry, does anyone have any objections to naming these two as the designated experts? Ok, hearing no objections. This is approved, and we will send the official note to IANA. This will also close Rob's action item. 6.2 In-person IEEE/IETF leadership meeting at IETF-120 (Eric Vyncke) Eric: It's in Vancouver. The IEEE meeting will be held.. Erik: Madrid, right? Eric: I think it's in Madrid. It's not 120, right? It should be 121. Where they are meeting right before, we're thinking of meeting together either Saturday or Sunday with IEEE leadership and IETF leadership would be nice. Before they were trying to colocate the meeting, not the same time, but the same city at least for 3-4 years, but of course the pandemic breaks the cycle. I want to get the approval of the IESG so we can try to colocate, and accept having a meeting Saturday or Sunday with IEEE. I don't think there's any objections to it? For me, it seems like a no brainer. Paul: Sorry, when are we meeting in Madrid? Erik: July 2025, I think. (crosstalk) Cindy: It's IETF 123; there was confusion because when Jon Rosdahl was talking about this, he was saying 2024, but it's actually 2025. Eric: It's in Madrid then. I think asking them actually is kind of sometimes lagging us regarding setting the agenda and the location. So, they can follow us and try to get a meeting with IEEE the week before the week after. So we have an opportunity to meet over the weekend. This is, of course, pretty important for Erik and myself in the INT area. But I think it's also important for Ops, for instance, and other people and security, of course, to see what's happening there. It's a mini social, to meet people rather than being on a call. Lars: So I think it's fine. I don't expect anybody to still be on the IESG by then. Let's schedule with the understanding that we're putting some future IESG members on the hook. I'm guessing IAB is involved in this, so they know about it. Dhruv: That what I was going to ask. We would need IAB folks, basically the people who are involved with the one issues. Eric: I put IEE and IETF here because IETF, of course, includes IAB. Paul: So this has nothing to do with something at IETF 120? Eric: No, forget about the 120, it's 123. Liz: Anymore discuss needed on this? Eric: I don't think so, I will reply to the list and say yeah, we're looking forward to those meetings. 6.3 IESG Meetings at 118 (Secretariat) Liz: I just did this on here yesterday, because I was looking at the wiki for topics, and it was looking pretty light. So I just did this on here as kind of a reminder to put topics on, which now several people have done. So, I don't know if you all want to spend a few minutes now, talking about the agenda, or where to put things but it looks at this point there's nothing on the Monday agenda, so I don't know you want to talk about whether or not to have a Monday meeting or how many other topics might be coming on the wiki. Lars: I would wait for this a little bit and ask people to, like, think what topics should be there because I've said it a couple times, but I don't think very many people have put stuff there. Francesca: I just added 3 topics. Lars: You can add topics to the joint time with the IAB and Mirja and I will figure out what goes where. Francesca: Can I just mentioned the topics I've added so we see if they make sense at all to to discuss. One is the Core SID, I didn't think we that could discuss the draft, but if we can, why not. Second the timeline for the WIT creation, we talked about that in the IESG mailing list. People have given their opinion, but I thin it'll be good for people to discuss it, and if Robert could be there for the Datatracker part, it would be good. Zahed: Francesca, thank you for putting it out because I was just about to write that because we need to discuss that and other stuff. Francesca: Murray had one more working group that we haven't announced yet, which might be good if we moved to WIT. I realized that I have one working group, UTAH, which is a security related that maybe would be good if it went to SEC, but at the same time, SEC is very busy. It could go to SEC and I could still be the responsible AD so it wouldn't add more work to the SEC ADs. Roman: As the first volley, i'm happy to source. Paul: Weren't we doing it anyway? We took over some of your documents, right? Francesca: Yes, you definitely took over some of my documents while I was gone. Paul: So no extra load then? Francesca: Because I already gave you some extra load. Roman: We don't have to change chairs, most importantly, so we're good. Francesca: I don't think we need to change chairs either way. There's a couple of working groups that we missed when we sent out the announcement and it'll be good to figure those out. Martin: We should also talk about dispatch, the minimum questions is what is the future of dispatch? That is the ART dispatch with the whole thing. That's interesting conversation with Mark Nottingham and others about there's a weird overlap between dispatch and SEC dispatch and should we merge into a super dispatch? And maybe GEN dispatch is separate still. How would we schedule that? I had some wild ideas about that by doing, like, Sunday night or Monday morning or Friday night, or maybe replace some of the plenary with it or something because obviously it conflicts with everything. But I think it'd be a great topic for for, uh, Sunday. Francesca: I actually added it. actually had added a experiment merging dispatch session at the 119. it was definitely like that discussion that you're talking about. But we can start with, like, I don't know if we want to discuss it more generally. Or do we want to, like, my idea was to have a proposal so that we can have a decision at the end of that discussion. Roman: I'd love to discuss that, and I would also like to chum the waters that if we are combining ART and SEC, I want routing at the table as well because I, I'm observing splitting between ART and SEC and routing in SEC. John: We were just texting about that in the back channel. Yeah if we're going to do this, then do it big. Francesca: We just need one dispatch, and we just need one one chair from every area in that dispatch. (Crosstalk) Liz: basically, this management and was just a point here to remind everyone to come to this wiki ad topics. So, if you can think of any more, go ahead and add them. 7. Any Other Business (WG News, New Proposals, etc.) Eric: Regarding IETF 118, there was the play plenary meeting, I think the time is wrong on the wiki page. If you look at their reservation. Liz: The plenary is a half hour earlier than it was at the last meeting. Eric: I just want to point it to you. Liz: I'm not sure who's in charge of that, I did not put that on there. Whoever is bringing the refreshments can change the time. Cindy: Speaking of refreshments and meetings, this is just a reminder that while we're in Prague the Sunday, Monday, and Wednesday meeting for IESG there will coffee and beverages, but there will not be an actual breakfast because breakfast is provided in the room rate at the Hilton. Paul: In each individual room? Liz: The money you paid includes the breakfast at the hotel restaurant. You can just eat your breakfast there. Lars: I guess it won't be super busy at the times we're meeting, but let's see on the first day. Otherwise it might be, I don't know if we can, like, ask them to reserve a couple of tables or something because I think people will want to eat quickly. And then run to the meeting, but I can't remember I don't think it was a problem in Prague. What's the breakfast wasn't in the lobby there? Somewhere? Liz: Restaurant right in the lobby there. I remember it's fairly decent size and there will be coffee and I think maybe a couple of pastries in the meeting room. So if you skip, you probably won't starve. Lars: I want to remind you guys to give NOMCOM feedback in Prague. I like to do it in person, but you can do it any way you want. You can put it in the Datatracker, but if you do want to do it in person, maybe send them an email to get some time from them. 6.4 Executive Session (Andrew Alston) An executive session was held.