Narrative Minutes interim-2023-iesg-18 2023-08-24 14:00
narrative-minutes-interim-2023-iesg-18-202308241400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2023-08-24 14:00 | |
Title | Narrative Minutes interim-2023-iesg-18 2023-08-24 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2023-iesg-18-202308241400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2023-08-24 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jenny Bui (AMS) / IETF Secretariat Jay Daley / IETF Executive Director 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 Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Roman Danyliw (CERT/SEI) / Security Area Francesca Palombini (Ericsson) / Applications and Real-Time Area Paul Wouters (Aiven) / Security Area OBSERVERS --------------------------------- Oooonduke Lee-Berkeley Shaw 1.2 Bash the agenda Amy: Anything new to add or any other changes? Rob: I don't know if you saw my email about adding designated experts for my first action item. Amy: I did not, thank you. We will add that. Lars: The support documents thing, we revised it and looked at it in the informal and I was wondering if we could ship it. Let's put that as a management item later. Zahed: We pushed one document discussion on DTN. Amy: Yes, that's on the agenda today. Éric V: About the Friday in Prague, finishing at 16:30 or 17:00; did we make a decision there? Amy: There was email about this recently; I think the option ending at 17:00 was better. Éric V: Let's put that on the agenda and minute the decision, then. Amy: Okay, three new management items. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes from August 10 being approved? Éric V: I just sent you an email a few minutes ago with a minor change to the narrative minutes. Amy: I'm hearing no objection to the official minutes and we have one small change to the narrative minutes, and we'll make that change before posting. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Rob Wilton to find designated experts for RFC 9390 (Diameter Group Signaling) [IANA #1275381]. Amy: This is now on the agenda as a new management item. o Roman Danyliw to find designated experts for RFC 9393 on Concise Software Identification Tags [IANA #1275658]. Amy: Roman couldn't be here today. o Paul Wouters to find designated experts for RFC 9420 on Messaging Layer Security (MLS) [IANA #1276814] Amy: Paul sent names for designated experts, so we will get to that in management items. o Murray Kucherawy to find designated experts for RFC 9457 on Problem Details for HTTP APIs [IANA #1277796] Murray: I put out a call and nobody answered, so this is still in progress. If this remains dead for too long I'm not sure what to do. * OPEN ACTION ITEMS o Warren Kumari to follow up on a bis document for RFC 8126 regarding designated experts. Amy: This seems like it morphed into one of the other action items for you and Lars. Is this separate? Warren: It is separate. This is a document Barry says he's working on because he was the original author of 8126. I reached out a few days ago and asked if I could help push it along and haven't heard back yet. This is in progress. o Roman Danyliw to open a Datatracker issue suggesting a feature to better signal individual contributions Amy: Roman couldn't be here today. o Lars Eggert to write an update to the Support Documents in IETF Working Groups statement. Amy: This is on the agenda now as a new management item so we can mark this as done. 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. Warren: I should mention we have six people on a thing saying we should not have more than five people on documents. Andrew: I'm planning on sending out something by the end of the week. John did send out some stuff. My current view is we need to reiterate the current text in the documents. o Lars Eggert to facilitate a community discussion on priorities for IESG processes. Lars: That's in progress. I forwarded what Adrian and Rich sent for a BOF proposal. I'm a little worried there's an assumption that ADs are fine with recording all kinds of data about how we do our jobs. I want to understand what they think we should do. I find time tracking to be quite a bit of overhead. Maybe it's something that can be automated in some way. At least the direction of the BOF proposal seems to be something that can be useful. Zahed: What's the history of this? Lars: We had a presentation about this in GENDISPATCH. There seems to be a belief that there aren't enough candidates for Nomcom because there's a perception that it's too much work or that it is too much work. So there's a proposal to gather some data. There isn't much of a proposal other than that. Zahed: So the current intention of collecting the data is to facilitate that discussion. Lars: The BOF is about what specific data they can gather from us and how it should be analyzed so that afterwards the community has some sort of insight into what the job of AD is like. The background is that Rich seems to believe one reason there aren't enough candidates is because the job is too much work. I was going to propose a different experiment which is to ask everyone who was nominated but didn't accept. The two can be done in parallel. Warren: I don't know how having a bunch of toil wouldn't make the job harder and more work. Lars: That's also my concern. I tried doing it and it's overhead. That's basically what's going on with facilitating this thing. We can discuss it more later. o Lars Eggert to draft a response to the appeal on the current guidance on interim meetings. Lars: We have an executive session at the end to discuss the response to John's. I confirmed with Ted that his appeal has been addressed. I would claim this as done. o IESG to decide how to use the experimental Friday afternoon sessions at IETF 118. Amy: We've been talking about the schedule and you can also discuss how to allocate sessions, like which ones will be relegated to Friday; will they be overflow sessions or regular sessions? That's what this item is about. 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: This is in progress. o Mirja Kühlewind to draft a proposal to the tools team regarding removing the requirement of needing an author email for deceased authors. Mirja: I didn't draft a proposal, I shared it with Robert and made a different proposal. Apparently Robert looked a little deeper into it; it needs tool changes but it's still not clear to me how much change is needed. I can follow up with Robert again or we can wait for him to come back to us. Amy: Did you want to keep the action item in progress? Mirja: Maybe we can just give this to the Tools liaison and they can follow up. Who's the tools liaison? Amy: The liaisons are Éric V and Warren. Warren: I'm still a bit unclear as to how we think it's supposed to work. There are many places where it would need to change. Mirja: There is a long term plan to rework this dependency on email lists and have things more closely connected to Datatracker accounts, but that's a bigger project that's already going to happen. The interim solution was just to take the account and set all the email addresses to inactive and make sure no email would be sent out based on our internal processing. Éric V: The email address is mostly used as a key in the database. If we remove the key we'll have some constraint there. Mirja: In this interim proposal, the key will not be removed. The email address is still needed when you submit the draft but you don't need it in the draft. We want to make sure none of the emails the Datatracker produces are sent to this email address. Warren: Oh, okay. Now I understand much more. Mirja: The initial idea was that if you set all email addresses of this account to inactive, it won't send any mail, but apparently that wasn't enough. So there's some amount of work to be done but I'm not sure what it is. Amy: So we'll move this action item from Mirja to Warren and change it to follow up. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-lake-edhoc-20 - IETF stream Ephemeral Diffie-Hellman Over COSE (EDHOC) (Proposed Standard) Token: Paul Wouters Amy: Paul couldn't be with us today. I have a couple of Discusses; do we need to discuss those today? Or Lars, as the Discuss-holder present, do you have a feeling if this will require a revised I-D? Lars: It's going to require a Revised I-D but my Discuss can be resolved with what they put in email. I'm not sure about Roman's. But definitely a Revised I-D. o draft-ietf-jsonpath-base-19 - IETF stream JSONPath: Query expressions for JSON (Proposed Standard) Token: Murray Kucherawy Amy: I have a Discuss in the tracker; do we need to discuss that today? Murray: I don't think so. I'm just seeing it for the first time because I was on vacation. I can follow up with the authors. Put this in AD Followup. Amy: Okay, thanks. o draft-ietf-regext-rdap-reverse-search-24 - IETF stream Registration Data Access Protocol (RDAP) Reverse Search (Proposed Standard) Token: Murray Kucherawy Amy: I have a couple of Discusses; do we need to discuss those today? Murray: The only one I want to chat about is the one where Lars is asking if it's within charter. I believe it is because the upper part of the charter talks about standards and does not enumerate which ones they'll work on. I agree it's kind of open ended but that's what the charter seems to allow. Lars: My reading was that the bullets on the bottom restricted what's in the top, but if that's not the case, I will clear. Murray: That's not how I've been interpreting it. I think I will go back to the WG and say that Lars had a point and it is rather open ended. To be fair to them, though, they have been very diligent about updating milestones which I approve as they go through. Warren: It is very open ended but I don't know where else this sort of work could happen. I didn't ballot on this because I wasn't quite sure how. A lot of the questions raised, especially from the opsdir review, is that it's very unclear how this and ICANN policy stuff interact. A lot of the questions around privacy and security were related to how to figure out if someone is authorized or not. All of that is still gated on ICANN figuring out what they're doing with the updated selective availability to something something available. It feels as though some of this is walking into ICANN policy territory but ICANN needs this so I don't know what to do. The opsdir review specifically asked a bunch of those things. Murray: I don't think it's unreasonable to ask those questions and the WG should be prepared to deal with them. It has come up before that there's a lot of stuff that's kind of ICANN magic in these places. One person has said why are we doing standards work that only applies to a tiny audience, that is the registrars and registries. You'd be within your rights to bring up some of these questions, whether as comments or a Discuss, and see what the WG says. Warren: I think it's perfectly fine for them to do this. Hopefully the WG is coordinating with ICANN because we don't want the IETF to accidentally create ICANN process. Murray: I invite you to ask that question. Mirja: Do we need any kind of formal communication with ICANN? Murray: I don't think that's necessary, unless the answer to Warren's question surprises us. Amy: This will go into Revised I-D Needed to address those Discusses. 2.1.2 Returning items o draft-ietf-shmoo-remote-fee-08 - IETF stream Open Participation Principle regarding Remote Registration Fee (Best Current Practice) Token: Lars Eggert Amy: I have no Discusses for this document, so unless there's an objection now, it looks like this one is approved. Lars: I think there's a new revision coming. Mirja: It's mostly small nits, but a new revision is good. Lars: Revised I-D Needed, then. I'll close SHMOO once this is done. 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 NONE 3.1.2 Returning items o draft-ietf-teas-ietf-network-slices-23 - IETF stream A Framework for IETF Network Slices (Informational) Token: John Scudder Amy: I have a couple of Discusses; do we need to discuss those today? John: Yes please. I don't want to talk about Roman's, which is technical stuff and I think the authors will take care of it. I do want to talk about Paul's which is a discuss-DISCUSS. It's just not a point that we can or should hold a document up on but I think the discussion has surfaced a number of useful things. A bunch of people feel icky about using the letters "IETF" in the title and would be happier if the WG came up with something else. The answers that came back from the WG were yeah, we felt icky about it too but we haven't come up with anything else. On that basis, my feeling is that Paul should probably clear his Discuss and I should work with the authors to see if we can come up with something better. There are two other things. One is that the authors have already indicated they'd be happy to change the title in some way that makes it even clearer that the document isn't trying to poach any other SDO's toys; one proposal being a framework for network slices in networks built from IETF technologies. That partially mitigates the concerns I've heard and equally changing the abstract to say something like general principles of network slicing in an IETF context. That's potentially helpful. It leaves the question of if we can use the adjective "IETF" in describing their network slices and I think the answer is probably yes. Final point, Erik raised with me this morning, are we really sure we've checked in with 3GPP and made sure they won't throw a wobbly? I'll take a token to make sure that's been done before we advance the document. Again, I don't think we should continue holding a Discuss on that basis. Zahed: On the 3GPP thing, I think we have enough authors and other people involved and they haven't complained so I don't think 3GPP will say something different. If you want to send an LS or some coordination I think that's fine, but I don't think that will be a problem. My other comment is that we should just say the network slices are based on IETF technology and write that in the abstract and maybe we can just put that in the terminology section. John: At one point I specifically put that suggestion to Adrian to just clearly define what you're talking about in the definition and say network slice. His answer was essentially that they're not doing it because reasons. The bit that sticks in my head is that the proposal was made, the authors and WG thought about it, and decided not to do it. Martin: Why are we taking a term that was made by someone else and just adding IETF to it? Why not just use a different word other than slice? Allocation, assignment…..any synonym of piece. John: I have two answers to that. One is I don't know, and the other is that this is a classic bikeshed conversation. We don't like the color they painted their bike shed but they have a pretty clear preference and ran it through a long WG process. Martin: I'd certainly not Discuss it if they decided to name it Fred, but there's a specific brand management and authority grabbing issue here. This IETF has cared a lot about that perception. I think it's a little different from a standard bikeshed. If they named it something completely arbitrary and random I'd say it's not our business. John: I thought Reza's reply to the email thread a day or two ago spoke to that reasonably well. He laid out some other options that were considered. They thought about calling it transport, but another group of people in the IETF already use that word for something else. Martin: If someone in the ART area decided to have some concept they called congestion control that was completely different from what TCP does, that seems an unnecessary collision. But I don't care enough to keep talking about this. Lars: I want to agree with Martin. If this thing was called 'an IETF framework for network slices', and cited a document to talk about the IETF architecture, and maybe even call it in another document an IETF network slice to distinguish it from your own. But using that term inside the document is weird. That said, I didn't Discuss because I can hold my nose and pass it and it's already very late in the game to make that change. Mirja: I don't think it's a bikeshed and it's not for a WG to decide if they can define something for the whole IETF. The weird thing is that there is something like a 5G network, but there's no IETF network. The only IETF network we have is the wifi at meetings. By defining this term 'IETF network,' you're defining something that doesn't exist and that's a branding problem. John: I think you're misconstruing what the adjective "IETF" is modifying. I think it's modifying "network slice," not "network." Mirja: It's a slice on a certain network so it's also defining the network. This has a much bigger impact than something a WG should decide. John: I still think it's a bikeshed, personally. I've heard from several people now that it's just this one WG, but it went through IETF Last Call and people had the opportunity to speak up. I got a comment that IETF Last Call is meaningless. Whether we think that or not in our private brains, that's our process. These documents have IETF consensus, not just WG consensus. If we think that's not working, we need to change our process. Mirja: Then you don't need IESG review anymore because as soon as it's through Last Call, there are no comments or anything the IESG can do if something is wrong. It's the authority of the IESG to flag if something is harmful to the whole organization. John: I take your point. The question is, how much to insist on that. Zahed: I didn't read this as IETF network slice. If I removed the prefix "IETF" every time it was mentioned, it didn't change the framework. You can just remove the IETF part. You can say this is our concept of how we see things in the IETF but anyone can take this and show the requirements to the network and the network will use whatever technology. This is about IETF technology but in the rest of the document it says you can tell the network operator what kind of slice you want and they are allowed to do whatever. I didn't want to go into that in my ballot but we can talk about that if you want. That is part of the job of the IESG and I support Mirja. John: If that's what I said, I didn't mean to say that. What I did mean to say was that there actually is an IETF consensus, whatever that means, that that term was okay. I would stick by that. If you look at the Discuss criteria, they're essentially all technical. You can't have an IETF consensus that pushes a document through for something that will cause congestion collapse of the Internet; it's the IESG's job to stop that. There's a proposal here that maybe it's also the IESG's job to defend the IETF brand. That's kind of inventing a new role and I don't know if that's appropriate. Zahed: I don't think this is classical bikeshedding. We can't even decide if it's a bikeshed or not, if it's a branding thing. It's important for the IESG to understand what we're doing here. It's not clear to me right now. Warren: I was one of the people who was really freaked out about them trying to oversell network slicing. I do think it's within the IESG's remit to help protect the brand and make sure people aren't claiming more consensus than there is. However, the AD reached out to the authors and WG, who showed they had considered a less market-y way of saying things, they made a sincere effort to find a way to rephrase it, and they couldn't. My concern has been withdrawn. I think they tried hard and legitimately so this is okay. It's not saying the IETF thinks network slicing is the best thing ever, it's a way to differentiate their use of the term from others. I raised a concern. I think people have tried to address it, and I'm happy they've come up with a reasonable set of possibilities. John: Thanks Warren. That jibes with my own impression of how the process has gone. Rob: I've already commented on this on email and I already said I wouldn't Discuss this. I somewhat agree with you, John, in the sense that I don't think this is Discussable. I do have some concerns about using "IETF" mainly that it opens the door to other people using "IETF" in front of protocols. I don't think it actually looks that good. Having said that, they talked about changing the title which would be great. IWithin the document it feels clunky that they refer to IETF network slicing. I think they should use something else or they define IETF network slicing and then abbreviate it to INS or something like that. If other documents refer to it as IETF network slicing I think that's fine. I wont' block on this but I wish we could do something better here. John: One thing we could do is if anyone thinks this situation could be improved by sticking an IESG statement on the front of the document. It would be interesting to see what paragraph you would draft for that document and that at least creates a framework for the authors to see what you want or to say go ahead and put the statement on. If anyone wants to volunteer to draft that. Éric V: This kind of statement would say that we, the steering group, are unable to change the text because the WG refused. It would really appear like a conflict. Mirja: I have a different proposal. It seems like there is no good term because the WG thought hard. Why do we need a term at all? I understand that it's useful to have this notion while you have a WG discussion, so it's easy to distinguish what you're talking about, but in the document you can easily say this is an IETF framework for network slicing in the title, adda sentence or two in the introduction that says this document only talks about slices that are related to IETF technology and it doesn't refer to, say, 5G, and we only use network slicing in this document. John: I did try that exact tack with the authors and they didn't bite. I think Zahed also mentioned that when reviewing the document he said what if I just remove the IETF and it doesn't work as well. Was that right? Zahed: My thinking was if I remove the "IETF" from the description and framework, it still works. It doesn't need the terminology there. It's still a terminology that everybody uses. If this is the case, the IETF has WGs trying to determine their own version of network slices, let's do it. I'm trying to figure out what else is going on. It says this is only for IETF technology but it also says you can use this framework to get anything you want, so 5G slices are fine. John: Your point is that you can use this to instantiate the transport portion of a 5G network slice. But part of their point is we're not trying to claim the entire 5G network slice, which involves layers we're not involved with. But the 5G network slice requires a transport portion and we think you can instantiate that using an IETF network slice. Zahed: That's my understanding. John: I see lots of Slack messages and I will look at them after the meeting. I don't know if we should continue talking about this. Paul's not here. I'm kind of ending up where I began, which is that I would really like PAul to remove his Discuss, I'd like the freedom to go back and negotiate with the authors and WG, knowing that we may end up with something like the modified title I suggested, and I'll take one more swing at getting them to take the IETF adjective out. It seems like in the end, if they want to publish it that way, we've now used enough of everyone's time and the Internet is not going to collapse if we let them do that. Éric V: But we may have an issue with 3GPP. John: I did also commit to….Zahed is right that we have a lot of 3GPP people who have already been in the room so we probably won't have an issue, but I do agree that it's important to double and triple check when we're dealing with other SDOs. I think with that, we can move on. Amy: Thank you for the discussion. It sounds like this will stay in IESG Evaluation; do you want Revised I-D or AD Followup? John: Let's do AD Followup. 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 o conflict-review-nottingham-avoiding-internet-centralization-00 IETF conflict review for draft-nottingham-avoiding-internet-centralization draft-nottingham-avoiding-internet-centralization-12 Centralization, Decentralization, and Internet Standards (ISE: Informational) Token: Erik Kline Amy: I have no Discusses, so it looks like this document can go back to the ISE. This is ready to go and we'll put this into Approved, Announcement to be Sent. 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 Lars: We had a call yesterday and a lot of it was spent on the draft-knodel-terminology. There's some discussion whether the ISE wants to or should publish it. There's also this identity program starting. And another program E-Impact, which is being finalized. Mirja: The E-impact program will be announced very soon. It's not clear yet if we'll have an identity program but we'll keep discussing it for four weeks. And we officially have an Outreach Coordinator, Dhruv. That was announced this morning. 6. Management issues 6.1 DTN Registry Statement (Erik Kline and Zahed Sarker) Zahed: As background, DTN is trying to update a registry. Previously I told the IESG there might be a discussion with DTN and the IESG about this. Right now they are proposing some number to be within the range where they want to have the new registry functional. They want to put a suspension on allowing any number of registration requests to IANA right now. Erik K: They're basically taking a 64 bit space and splitting it up into a high portion and a low portion. The document there describes how they intend to do that and why they think it is safe. Basically during some sidebar chats in San Francisco they thought maybe we should make sure nobody tries to do a land grab. In order to get up to the 2 billion range, they're currently at 286,000, so there would have to be 10,000 more allocations. I wouldn't put it beyond someone to try something so in discussion with the chairs they thought maybe they should just request that if you happen to allocate 10,000 more of these things and end up in the 2 billion range, maybe you should pause or deny allocations in that range. It's going to take an awful lot for this registry to get to that state, but I never put it past the Internet. Warren: Challenge accepted! Erik K: Exactly. That's basically what this is about. Zahed: I think the ask is if the IESG is fine with this. I promised them I'd also bring a concern that maybe we're doing a process violation. Is it okay to tell IANA to do this suspension without having a document? My personal opinion is fine, we're not telling IANA to change anything, we're just asking them to suspend a certain range of this registry while the WG decides what to do. But it's a concern to think about. Warren: Couldn't we say that the IESG requests that IANA lets us know if it's getting close to that, and then we could quickly publish a document? Erik K: This email process was recommended by talking to IANA folks in San Francisco. They said if the IESG sends an email, they can do it. Warren: They're not the ones who would get appealed if someone got bent out of shape. I don't think it's an issue, just mentioning it. Zahed: I think your idea makes sense and we could write something like that, if they get up to that number and the DTN WG hasn't produced a document with what to do, they can come to us. And this is temporary; when things are more clear in the WG we can revert the decision and take off the suspension. Erik K: We could change this to ask that IANA temporarily decline registration requests and something if the update document times out. Éric V: Do you expect some people to complain about it, besides the process? Erik K: There has been a thread on DTN about it and one concern was we are requesting IANA to do something without having an IETF consensus document yet. Éric V: That's the process. But a technical argument we don't have any, right? Erik K: No. Zahed: Only one person raised this and was not sure. Warren: Let's just send the email. The worst that happens is that someone appeals it and then we just say, we thought this was reasonable and seemed to fit within our remit, we won't do it again. Looks good to me. Lars: I agree, let's do this. Zahed: Cool. Then I think we can minute that we approved this. Erik K: I can make the edits and ping you when it's updated. Zahed: What's the process, that we send this to IANA? Lars: What's the timeline for this document to be completed? Can we prioritize this? Zahed: We're prioritizing this. Most of the work in DTN is revolving around this discussion. I told them to publish the updated draft and run this through the WG. Lars: When do you think this document will be approved so we can unfreeze the registry? Zahed: I think the WGLC will be done within weeks. We're not talking years here. Lars: Thanks. Amy: Sabrina, do you need an official note from the IESG or is an email coming from Erik and Zahed good enough? Sabrina: I think we just need the email. Amy: Great, thank you. 6.2 Ephemeral Diffie-Hellman Over COSE (EDHOC) Designated Experts (Paul Wouters) Amy: Paul has identified John Mattsson, Göran Selander, and Mališa Vučinić as designated experts for this registry. Any objection to approving them? I'm hearing no objection, so we'll send the official note to IANA. 6.3 [IANA #1276814] RFC 9420 MLS Designed Experts (Paul Wouters) Amy: Paul has identified Sean Turner, Raphael Robert, and Richard Barnes as designated experts for these registries. Any objection to approving them? I'm hearing no objection, so we'll send the official note to IANA. 6.4 [IANA #1276364] Designated Experts draft-ietf-emu-aka-pfs (Paul Wouters) Amy: Paul has identified Jari Arkko and Alan deKok as designated experts for these registries. Any objection to approving them? I'm hearing no objection, so we'll send the official note to IANA. 6.6 Designated experts for RFC 9390 (Diameter Group Signaling) [IANA #1275381] (Rob Wilton) Amy: Rob has identified Lionel Morand and Jouni Korhonen as designated experts for this registry. Any objection to approving them? Hearing no objection, so we'll send the official note to IANA. 6.7 Support Documents (Lars Eggert) Lars: If people agree, I'll remove the old text. I rewrote the whole thing. Last time we discussed this, people weren't clear what the original text was, so I reverted it, but you can't see a useful diff. This is supposed to roll back some of the strong suggestions in the current statements that says WGs shouldn't be doing these. Some people on the current IESG seem to believe there can be a use for them, so we wanted to allow WGs to publish these if they want to or if their charter requires them to. Looking at the comments I think we're in the wordsmithing phase. [some live wordsmithing of the text] Lars: Okay, thank you for the group editing. I will send a message to Greg to update this. 6.8 Friday at 118 (Secretariat) Liz: I think almost everybody who weighed in said they preferred Option 1, which is the 5 pm ending, so unless anyone has an objection now I think that's what we should use. And if something changes and we wind up ending a little early, I don't think people will complain. It doesn't seem like anyone has any more thoughts, so we can go ahead and do it. Thanks. Mirja: What does 'doing it' actually mean? Are we announcing this widely? Liz: I'm not sure. I think it's helpful to at least know the end time, since I know people will be asking. We don't normally announce the details of the schedule ahead of time since we don't normally have the details of the schedule this early, but I don't think there's any harm in saying sessions are projected to end at 5 pm. Mirja: We've gotten a couple of questions so we should definitely tell those people. I think it would be important to maybe send an announcement email and also make this visible on all the webpages. Amy: The registration opening email already says that sessions will extend later than usual, so there is text out there. I don't know if you want to make a specific message just for this, if the IESG would like to really point this out to the community, or if you just want to send it to the WG chairs. Mirja: I missed it in that email. Amy: That's a good point, people may not read it, so it might be useful to send a specific message that sessions are projected to end at 17:00. Mirja: Maybe it's unnecessary but I'd rather do it than not do it. Éric V: Let's err on the safe side and send it again, very clearly, all meetings will end at 5 pm. Mirja: We should also put it somewhere on the 118 page, I'm not sure. Liz: We'll take this back to the team and we'll figure out all the different places we can put it on the website so it's clear. For this announcement email, would you like that to come from the Secretariat or someone on the IESG? Lars: Secretariat is fine. You can just say that the IESG decided. Liz: Great, thanks. 7. Any Other Business (WG News, New Proposals, etc.) Dhruv: What's the thinking on the IAB/IESG joint wrapup meeting? Lars: The IESG has discussed doing it during lunch on Friday, before all sessions have happened. ISOC has a thing on Friday evening that the IAB is invited to. Martin: So to clarify, the IESG is done at 5 on Friday? Mirja: I think we should confirm with the IAB. The only two proposals on the table are the lunch break or between 5 and 7 pm. Lars: That overlaps with the ISOC thing for you guys, right? Mirja: We can decide when we want to start. It's not the normal ISOC thing, it's a working dinner with ISOC and the IAB. Lars: Okay. I'd still suggest doing it at lunch. Mirja: Let's take it on the next IAB call and provide some feedback to you guys. Lars: Can we just do it by email? Dhruv: I can include it with my IAB news, no problem. 6.5 Executive Session: Appeal Response (Lars Eggert)