Narrative Minutes interim-2022-iesg-10 2022-05-05 14:00
narrative-minutes-interim-2022-iesg-10-202205051400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2022-05-05 14:00 | |
Title | Narrative Minutes interim-2022-iesg-10 2022-05-05 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2022-iesg-10-202205051400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2022-05-05 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 Roman Danyliw (CERT/SEI) / Security Area 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 Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Applications and Real-Time Area Zaheduzzaman (Zahed) Sarker (Ericsson) / 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 Paul Wouters (Aiven) / Security Area Qin Wu (Huawei) / IAB Liaison REGRETS --------------------------------- Jay Daley / IETF Executive Director Alvaro Retana (Futurewei Technologies) / Routing Area OBSERVERS --------------------------------- Lee-Berkeley Shaw Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything to add to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Is there any objection to approving the minutes from the April 21 teleconference? I'm hearing no objection. I also saw final narrative minutes from April 21; any objection to those being approved? I'm hearing no objection to that either. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Murray Kucherawy to find designated experts for RFC 9208, "IMAP QUOTA Extension" [IANA #1229081]. Murray: I have that; do we want this at the end or do you want to do it now? Amy: At the end; if you can put the names of who you found in the Slack channel we can pick them up from there. We'll mark this as provisionally done and we'll add a management item to approve. o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn) [IANA #1229681]. Roman: In progress. o Francesca Palombini to find designated experts for RFC 9176 (Constrained RESTful Environments (CoRE) Resource) [IANA #1229995] Amy: This is a new item for Francesca. Francesca: Thank you; noted. o Security ADs to find designated experts for RFC 9116 (A File Format to Aid in Security Vulnerability Disclosure) [IANA #1230049]. Amy: Is there a specific security AD who wants to pick this up? Roman: Paul and I will talk collectively, so action caught. Unless Paul, you have an idea right now. Paul: I do not. Amy: Great, then we'll mark this in progress and you can let us know. o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in July 2022. Amy: This is on hold. o Murray Kucherawy to look into updating the guidance in BCP 13 on when to add organizations to the "Standards-related organizations that have registered Media Types in the Standards Tree" list. Murray: Where that seems like it's going to go is a note on the IESG wiki rather than a new draft. Changing a BCP seems like a heavy handed answer to what we were talking about. Expect a proposal from me shortly; it's still open, but that's where it's going. o Lars Eggert and Francesca Palombini to draft an announcement about the public archive of AUTH48 conversations. Amy: I think this is on as a management item to discuss today, is that right? Lars: That's right. I'd mark this done since it's drafted. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-idr-bgp-ls-sbfd-extensions-10 - IETF stream BGP Link-State Extensions for Seamless BFD (Proposed Standard) Token: Alvaro Retana Amy: I have no Discusses in the tracker for this document, so unless there's an objection now, it looks like this one is approved. Éric V: I may suggest to put this as Revised ID Needed just in case, because Alvaro is not here. Amy: Since it was just revised, I think AD Followup would be a better choice, unless you think version 10 that was just released is not sufficient. Éric V: That's fine for me, go for it. Amy: Great, then we will put this as AD Followup and Alvaro can release it whenever he wants. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items 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 o conflict-review-liu-lsr-p2poverlan-00 IETF conflict review for draft-liu-lsr-p2poverlan draft-liu-lsr-p2poverlan-07 Interface Stack Table Definition and Example for Point-to-Point (P2P) Interface over LAN (ISE: Informational) Token: Warren Kumari Amy: Warren did the review for this document and I have a Discuss; Rob, it seemed like you just wanted to discuss this, is that right? Rob: Yes. I've sent more detailed comments to the authors; I just wanted more discussion here with the IESG about whether they think it's okay to publish this. My specific concerns are the way they are modeling this is not how I would recommend modeling this in Yang and I'm not sure it's how I would expect an IETF consensus to model this. The attribute they are modeling is one that's standardized so I think it's probably okay, potentially with a disclaimer, but I wanted to flag that and see if anyone had any concerns. I've discussed it with Eliot and will discuss it with the authors as well. I've sent them further comments about the approach they're taking. John: That makes sense to me. What's the outcome you're hoping to achieve? Getting them to revise their document in a way that's more suitable, or getting us to put a disclaimer on the top of it? Rob: I send comments anyway suggesting some technical issues they will probably want to comment to address. I don't know if some of those will potentially then stop them using this approach at all. It may be that the ISE then says we shouldn't publish because there are technical problems. Assuming that it's technically viable, then I think just a disclaimer saying effectively this is one way this can be configured, but it's not the recommended way, or an expectation that other operators or other vendors would necessarily follow this approach. So that's my concern, is that it's like a back door way of adding some extra manageability API and i'm just not sure that's helpful. Does that answer your question, John? John: Yes. I've always been unclear about whether we just have to pick from that menu of boilerplate disclaimers or whether we can actually provide other ones. Warren: We had somewhat of a discussion on that with a previous ISE. What we'd largely come to consensus on is that we're supposed to choose from those answers with maybe very tiny changes. If you have other thoughts, you can put them in as additional thoughts that are not part of the conflict review. Like dear rFC editor, please remove this before publishing type things. What I don't know is what the process is if there's a Discuss on a conflict review. The Discuss isn't really about the conflict review, it's more about the document. Lars: A Discuss on a conflict review is with the proposed answer. You basically say I don't agree this is good to go forward, I think this should be do not publish. You could have a Discuss that says I don't agree and I think we Do Not Publish this because of the content of the document. But if it's not at that level, I think it needs to go to the ISE and say I have some serious concerns but I don't want to argue for Do not Publish, but maybe the authors want to look at this. Do you think this is a DNP? Rob: I don't, I think that's too strong. I wanted to flag that I had concerns; if the IETF was doing work in this area I don't think they'd come up with this solution. I think they'd do a different mapping of the manageability model to describe the same thing. And I have questions about how their solution will work from other aspects, which I've raised with them. So that has been sent to them and the IESG has been CCed. I'm not sure if this is a Do Not Publish. When I chatted with him today, Eliot was of the opinion that because the IETF is not actively standardizing this attribute, it's like potential future work. He would say he thinks it should be published anyway assuming that it's technically sound. That was my opinion. I don't know if that will change but that seems reasonable to me. I think it's just a matter of having a disclaimer that makes it very clear this isn't part of the IETF's Yang manageability interface and how these things are managed. It's one way it could be done and some vendors are using it. Zahed: My understanding from when Adrian was here before he left, he said that this Discuss is about the conflict review and if you have comments about the content you can put it in the comment section. So this would be No Objection with lots of comments and I think you've already done that. Rob: Yes, effectively, assuming nobody else says Do Not Publish, we should change the outcome that this is related to IETF work in LSR, so that's a minor change. I'm not saying we should Do Not Publish, I just wanted to have the discussion. Warren: Two quick questions. One, Alvaro had said this does feel like it might be related to X. He's probably right. What I don't know is, does that mean that we have to propose new conflict review text saying this is related but the IESG is okay with it? Or do we just go with what we've got? I don't think there's much in the way of important archival stuff in the conflict reviews, whether there's no conflict or it's kind of related but you can publish anyway. If the IESG does want an IESG note attached, instead of DNP, what's the process for that? And a third point, we should probably change the button that says send notice to Adrian to Eliot. Amy: It does go to Eliot, there's just a Datatracker thing that has Adrians' name attached and there's already a bug report for that. Warren: Can we stick with the current text or do we think we need to change it, and if so do we need to do another ballot? John: Or should we make the text be right? What's the point of having text if we don't try to get it right? I don't think we have to spend a lot of time losing hair over it, but if we agree this one isn't quite right, let's make it right. Warren: Sure, but do we have to re-ballot? Amy: No, you just change the text of the conflict review. Éric V: To which text? I'm a bit confused now. John: I assume it would be changed to, is related to LSR but no objection. Warren: Yes. Éric V: But I think Rob's goes further than this, right? Warren: That's a separate issue. Rob: The fix for mine is that hopefully Eliot and the authors will agree to have some text in the document that makes it clear about the scope. I would have thought they'd be willing to put that in so that's my assumption. I don't know if we need a formal IESG note attached to it; that feels heavy-handed. Éric V: But it's important, right? Rob: I think so. On the flip side, this is just an IF type and anyone is sort of allowed to allocate these by the INF process; there are guidelines for how to do that and there are no guidelines that say you can't do this if IETF disagrees. It feels like it would be wrong to block this and say you can't do it, because there's no good grounding other than if the IETF was to try and do this I think they would come up with a better answer. It may also be that I misunderstand exactly what they're trying to model in their document and it's just clear enough that from a configuration side nothing's changing. That's fine, they just need to clarify that in the document. John: It sounds to me like you should just do exactly what you said, take it to the authors and Eliot and they'll do the right thing, and then we're done. If they don't we can probably have another conversation about it. Rob: Eliot is happy with that. Warren: I just updated the text to reflect Alvaro's concern. Rob: So I'll clear my Discuss on this and we'll just take it to the authors from there. Warren: Awesome, thank you. Amy: So the text has been updated and Rob will clear, so this conflict review is now cleared to go back to the ISE with the note that's in the tracker. o conflict-review-irtf-nwcrg-coding-and-congestion-00 IETF conflict review for draft-irtf-nwcrg-coding-and-congestion draft-irtf-nwcrg-coding-and-congestion-12 Coding and congestion control in transport (IRTF: Informational) Token: Zaheduzzaman Sarker Amy: There are no Discusses in the tracker so unless there's an objection, this conflict review is ready to go back to the IRSG. Éric V: I don't recall having reviewed this one; when was it submitted? I guess I didn't. My bad, sorry. Lars: It came a bit late, but it was on the agenda for a while. Zahed: That was my mistake, not to change the area review to IESG review which is why it didn't create a ballot. I did the review a while ago but I didn't change the state. Éric V: That's fine, I just wanted to check if I'm the outlier. 3.4.2 Returning items NONE 3.4.3 For action o conflict-review-rprice-ups-management-protocol-00 IETF conflict review for draft-rprice-ups-management-protocol draft-rprice-ups-management-protocol-13 Uninterruptible Power Supply (UPS) Management Protocol -- Commands and Responses (ISE: Informational) Token: Lars Eggert Amy: Is there any idea of who might be the appropriate person for this review? Lars: This looks like an ART thing to me. Warren: It has the word Management in it… Lars: If you want to fight over it I'm all for it. Rob: I don't mind either way. I had a quick look and I don't think there are any issues. Francesca: I'm currently doing another conflict review so I'd rather not take on another. Rob: Send it my way then. Amy: Thank you, Rob. We'll put you in for that. Lars: Before we move on, there's another one that I think came in yesterday, that I was wondering if it's INT or OPS and Erik said he thinks it's OPS, so I think it's Warren's if you want it? It's draft-dashevskyi-dnsrr-antipatterns-00. Warren: I don't see it anywhere, can you drop a link to the document? Lars: It went to the IESG list, I can forward it to you. Warren: I will take a look and see why it's not in DNSOP. 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 Common Control and Measurement Plane (ccamp) Amy: I have no blocking comments on this recharter; does this need to go for external review? John: Other opinions? Unless other people think we should skip it, my inclination would be to go ahead and do it. It's a small textual change that we went back and forth on. They didn't seem to be very proprietary about it so we took it on, but the fact that the consensus was not that this obviously belongs in CCAMP makes me wonder if other people want to have their opinions heard. Amy: That sounds like a good reason for external review to me. Roman: If there's nothing pressing it's always better to go to the community just to give visibility for it. John: I don't see anybody saying we shouldn't do an external review, so let's just go ahead and send it. Can you hold off on the announcement until we have a chance to produce an 08-02? There were a bunch of non-blocking comments we can take on. Amy: Okay, this will be Approved, Pending edits, and you can let us know when it's ready. o Remote ATtestation ProcedureS (rats) Amy: I have no blocking comments to sending this for external review and I believe Roman did say he wanted this to go for external review, so unless there's an objection it looks like that external review is approved. Roman: I appreciate everyone's feedback. To respond to the things that came in: Francesca, we can add a couple more WGs. It never hurts to talk about who we're going to coordinate with. John, I think you've been talking with the chair, and I think I commented previously we can tune that language and clear it up. On the carriage return line feed, I continue to think that this is that markdown rendering issue. I seem to have it every time I do a charter. If someone knows what I should be doing differently to make it render better, I'm all ears. Éric V: Put an empty line between those items. Roman: That does not render correctly for me either. Warren: Put two empty lines between those? I know I made it work by randomly adding a bunch of extra blank lines. Or, just don't bother to make it render properly. John: All the other lines have a comma, or an asterisk, and that one has something else on the tail of the preceding line. It's so arbitrary. Roman: I'll spin a -01, -02, -03 to figure it out. Eric, I think we got your comment already. I'll make a few minor tweaks and I appreciate the feedback. Lars: There's also the sandbox that you can use to play around with this so you don't need to send email out for a gazillion reviews because of markdown. Roman: That's a good idea, I forgot we can do that. Warren: Somewhere I actually wrote an email or a note to myself or something from when Rob and I found this last time. We did figure out what the issue was. But I think it's easier just not trying to format them. Amy: Okay, so this is Approved -- Roman, do you want it to be Pending Edits so you can get it to look the way you want before we send it out? Roman: Yes please. It's not just the formatting, there are a few word changes I wanted to make too. I'll do that this afternoon. Lars: Before we move on, I wanted to ask the ADs whether any of these recharterings are also a good opportunity to also cycle some chairs. I think at least one of those groups has had those chairs for a long time. I'm just going to put it in your heads, we don't have to discuss it now, but think about it. Thank you. 4.2.2 Proposed for approval NONE 5. IAB news we can use Warren: I wanted to point at the email that the IAB and IESG seek feedback on candidates for the RSE Series WG chairs. That was sent to the announcement list so I just wanted to remind people to have a look at that. The proposed IAB workshop on in network support for troubleshooting and security which is ISTS, which Lars forwarded to the IESG yesterday or the day before with a Google document in it. That was something being discussed and worth having an extra set of eyes on it. Those are the main things, not specifically news but reminders for feedback. Mirja: If I can add one more thing, we also looked at the BOF proposals and there were IAB members who were interested in supporting the proponents, so they will reach out and CC the ADs accordingly and see if any help is needed. Warren: Thank you, yes. 6. Management issues 6.1 Approval of Designated Experts for rfc6833bis (Alvaro Retana) Amy: Alvaro has identified Albert Cabellos and Dino Farinacci as experts for this document and all six registries it talks about; is there any objection to approving these two as the experts? Okay, hearing no objection so they are approved and we will send the official note to IANA. 6.2 [IANA #1229995] Designated experts for RFC 9176 (Constrained RESTful Environments (CoRE) Resource) (IANA) Amy: This is to assign the action item we assigned to Francesca at the top of the call. 6.3 Appoint an IETF RFC stream representative to the RSAB (Lars Eggert) Lars: The IAB did this in Vienna and we sort of missed it when we did our appointees. We talked about it but we didn't actually decide. I think it should be the IESG chair, especially in the beginning, and I haven't seen anyone disagree with that. It's also Mirja from the IAB and all the other heads of the approval bodies so I would like us to appoint myself, if that's possible, and then we have the RSAG complete and we can start the new model. Warren: If it helps, I nominate Lars, so you don't do it yourself. Éric V: I agree. Amy: Is there anything we need to do process-wise? Lars: We probably want to send out a message to the community with the names and I think they're all in the Trello ticket. The one name we don't have yet is the RCSE which is being hired; but the RSAG can already start without that position being filled. Mirja: Do you think this is super urgent? My plan was to get a meeting during the next IETF meeting so some of us can meet in person. Lars: I was just going to send a message to the community saying here are the people who were picked for the RSAG. Mirja: That's probably also not super urgent. Cindy is targeting to set up the mailing list and a Datatracker group and then plan for our first meeting; in between there we can announce it. Lars: The mailing list is ready as I understand it. Mirja: Yes but we need to subscribe people. Lars: Then let's send an announcement at some point when you think we're ready. Mirja: Let's add this to the to-do list, Cindy. 6.4 [IANA #1230049] Designated experts for RFC 9116 (A File Format to Aid in Security Vulnerability Disclosure) Amy: Roman and Paul took this on at the top of the call. Éric V: May I suggest getting some ART people involved there as well, because it's not just about security? Just a suggestion. Paul: Thanks, that's noted. We'll talk to them about it. 6.5 RSWG Chair Appointment Process (Mirja Kuehlewind) Amy: I know the IAB discussed this yesterday and they have their people for the interview team. Mirja: We discussed this yesterday and there are two questions. One is if we want to form a common interview team, and I think there was strong support for that because otherwise that means we have to ask all the candidates to do the interview twice and we need double the Secretariat support for notetaking and such. So there was strong support for that. We picked 3 IAB members to join that team, so having another potential three people from the IESG would complete the team. The second question we may want to discuss is how we actually select the people, because I made the point yesterday that I don't think we should make an independent selection. It's not like we are appointing two people independently who work on their own; this team has to work together, so there might be dependencies and we should pick them as a couple. That was my proposal. I think there were less strong opinions about this in the IAB but there was no objection to taking this approach. Any comments or thoughts? Lars: I changed my mind yesterday a little bit. I initially thought we should do two separate selections because that's what the RFC says. However it doesn't say that we can't coordinate between the bodies and share information when we independently make a selection. It does make sense to me that we are picking a team here and not individuals. I think we should jointly decide who we pick. The IAB picks for a two year term and the IESG picks for a one year term and then in alternating years we renew or replace, but in the beginning here I think we are picking a team. Mirja: In the end of course we have to decide which person will be the IAB person and which person will be the IESG person because of the terms, but that should be easy. Rob: I agree with what you're suggesting, Mirja, based on the feedback I've received anonymously that you need to consider this as two people not one. Having some sort of coordination at least on who we are appointing between the two bodies makes sense. Zahed: I didn't read the background about why we have these two processes and why the rFC wants us to do it separately. Any background information on that? We can definitely pick up the team jointly but what is the reason? Mirja: It's not that the RFC wants us to do it separately, it just doesn't say anything about it. The IAB picks one candidate and the IESG picks another candidate and there was some discussion that we don't want to put any kind of process for how to pick it into the RFC and leave it to the bodies. The idea was to have shared responsibilities among both groups Zahed: Okay. If it's about having shared responsibilities across both groups, I think we're doing exactly that. What you said makes sense to me, Lars. Lars: It was Mirja's idea first, I just agreed with it. Roman: I want to make sure I understand the bottom line. What we're saying is that we are going to form a joint search committee, or joint review committee, that is the IESG + IAB and collectively two choices are going to be made out of that? Lars: I think the proposal is that first we're going to pick an interview team, there are 3 IAB members already and I guess we're looking for 3 more. Ideally all six of those will interview all the candidates but because of time zones it might be a subset. We'll get written notes out of those interviews that are sent to the entire IESG and entire IAB. Based on the interview results and community feedback that's already coming in, the IESG and IAB together are picking two. The one that's slated as the IESG person serves a one year term initially and the IAB person serves a two year term. Mirja: Ideally we'd get a recommendation for one pair out of the interview team, but we also probably need a venue for discussion where we can all discuss together. Then at the end we would do some kind of vote on accepting these two people. Roman: So there's a joint review committee between the three IESG and three IAB and together they'll choose 2 candidates to bring back to the IESG and IAB to support collectively, rather than the IESG having its own review committee to see if we want this particular individual. We're basically collapsing the search by pooling the IESG's thinking with the IAB. Correct? Lars: There's no IAB lead, it's level ground between the IESG and IAB. There would be a joint interview team and they would make a selection for a pair. Then we can all decide whether we want to go with that or if we need to have everybody review everything from scratch. But I hope we can delegate it to the sub-team. Mirja: how we design the voting at the end is something we can still discuss. I hope we can reach a good consensus. If we get to a situation where everybody on the IAB agrees with the two people suggested and everybody on the IESG says no, we will have to have more discussion; we shouldn't just take a majority of votes. But I hope the process will be smooth and we can all just agree at the end. IF that's not the case we can figure out how to design the voting in a useful way. Roman: I'm fine if the takeaway position here is that we have two subteams that are working together and are going to provide a joint set of recommendations but there is an opportunity for either body to eject form whatever is that recommendation if that is the choice those bodies independently want to make. To be clear, I think that's what was said but I just wanted to confirm. I don't know whether we're talking past each other or if we agree. Mirja: I think you're right. We don't have to finalize the process yet and if someone feels uncomfortable we can always change it. My hope is that we can all find agreement on two candidates together at the end and if we can't find agreement then we will have to find a different process. Lars: So I guess we are looking for three names from the IESG to do the interviews and make a pre-selection for us that we can confirm. Mirja: We assumed we'd do what we usually do with interviews, which is that we form a team and Cindy supports us to find meeting slots with the candidates where most of the team members are available, so she will do a doodle for that. If anybody can't make any of the calls that's usually not a problem because she will take minutes and we'll have a summary at the end, and then we also usually prepare a set of questions for the interview beforehand. Wes already agreed to start a google document for that and everyone on the team can contribute questions to that. Then at the interviews we usually go through those questions in a round robin manner so everyone is involved, but the team itself can figure out how they want to handle it. Then at the end you also need somebody from the team to send a summary and channel the recommendations to the rest of the IAB and IESG. Éric V: And this is to be done in May or June? Mirja: We probably won't be able to get any of the interviews done before the retreat so the assumption is that the two weeks after the retreat will be the period for the interviews, depending on the candidates' availability, and then hopefully we can come to a conclusion soon after that. Roman: I'm happy to be one of the three from IESg. Éric V: Me too. Zahed: I can also be interested. Amy: Great, that's three, thank you. The Secretariat will be in touch and let you know what's next. 6.6 Finalization of retreat agenda (Lars Eggert) The IESG went through the retreat agenda to finalize some topics and timing, which is now reflected on the IESG wiki. 6.7 AUTH48 archival announcement (Lars Eggert) Lars: there is a google document that has seen a few edits and I would like to send this out after running it past Robert one last time. I think we're doing exactly what the tools team said was easy to do for them but I want to double check. Francesca: I didn't put in any comments but thank you for drafting that. The only thing I think we might want to hint at is to say that this is what the tools team said is the easiest/most doable. Which is the conclusion we got to, but it would answer a lot of the feedback that we got if we just say that we're going to do this after talking to the tools team. Lars: That makes sense. I'll try and stick a half sentence in somewhere unless someone beats me to it before I look at it tomorrow. So basically we're going forward with this and we'll send out an announcement based on the current proposal module. That will probably happen early next week. Since I just mentioned Robert, by the way, he's now an LLC employee as of May 2. Nothing changes otherwise. 6.9 Designated experts for RFC 9208, "IMAP Quota Extension" [IANA #1229081] (Murray Kucherawy) Murray has identified Alexey Melnikov and Ken Murchison as designated experts for this. Any objection to naming them? Hearing no objection, so they are approved and we will send an official note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Andrew: Briefly, I wanted thoughts on this -- I was thinking it would be useful on the AD dashboard to show outstanding auth-48 things so things don't disappear into mails. I wondered if anyone else had any thoughts? Otherwise I can drop an email to tools-discuss and see what's possible. Warren: I believe everybody else has views on this and everybody else has said it would be awesome. I think it's already on the list. There's some sort of issue with the fact that in order for it to be on the dashboard you need a way to get it out of the RFC editor queue and something something that's complex. But yes, that would be great and everybody wants it as far as I know. Francesca: Also Robert and the RFC Editor have told us that the tools team is working on a new website/tool for keeping track of auth-48 conversations. At that point it might be easier to integrate that sort of information with the Datatracker. We've discussed this and that was the result but you're welcome to bring this feedback to Robert again. There is a work in progress about related things, though. Andrew: Thank you, that predates me. Sandy: As an FYI, a while ago there was discussion that it would be useful to note which documents are awaiting AD approval; like the RFC editor has asked for something. On the RPC side there has been a little tooling work to put the information in place for the datatracker to pick it up. We've talked to Robert about it, it's just not the top priority right now. The way it would work as I understand it is that it would be a flag like "Waiting for approval" or "AD input needed" and you could then go look at the thread for whichever RFC is flagged. Andrew: Like I said, as long as there's something beyond emails. Roman: I think what you're describing is a great idea and I wholeheartedly endorse it. If anything I would want something more ambitious, like taking all the things that are at the RFC Editor and putting it on my dashboard, so the other big bogey for me is errata and making sure they are verified. Andrew: I 100% support that as well. Sandy: I'll take a note of that for future tooling. 6.8 Executive Session: Discussion on DNSOPS message-fragments (Lars Eggert)